How to Avoid Duplicate or Failed Sends in a Bulk Token Distribution

When a bulk send goes wrong, the cause is nearly always the recipient list. The chain does what the transactions tell it to, so a bad row turns into a bad transfer. These are the mistakes we see most often, and how to catch each one before you sign.

Duplicate recipients

Most accidental double-sends come from the same address appearing twice in a list. It gets in from an original export plus a manual addition, or from two spreadsheets merged together. Plenty of tools don't remove duplicates for you, because sometimes a wallet is meant to appear twice with two separate allocations.

Before you upload, sort the list by address and look for neighbouring rows that match, or use a spreadsheet formula to flag repeats. Decide for each one whether it should be merged into one amount or removed.

Trailing spaces and invisible characters

Addresses copied out of a spreadsheet, PDF or chat often bring something extra with them: a trailing space, a non-breaking space, or a curly quote where a straight one should be. An address with a stray character isn't a valid base58 public key, so a good tool rejects it instead of sending somewhere else. If the list was put together by hand, spot-check a few rows anyway.

Amounts with too many decimals

If a token has 6 decimals and a row says 1250.123456789, the amount has more precision than the token can hold. Some tools reject the row. Others cut off the extra digits without telling you, and that recipient gets a slightly different amount than you planned. Round every amount to the token's decimal count before you upload.

A token account address where a wallet address should be

This one is easy to make and expensive. A token account address (the account that holds one token's balance) looks exactly like a wallet address (the owner). Both are base58 public keys. If you paste token account addresses into a field that expects wallets, the tokens can end up somewhere the intended recipient has no easy way to reach. Make sure your list holds wallet addresses, especially if it came from raw on-chain data and not from a recipient export.

Re-running a batch that half finished

A bulk send can stop partway: the tab closes, the connection drops, or one batch transaction fails. If you then run the whole list again without checking what already landed, everyone in the batches that succeeded gets paid twice. This is the easiest failure to prevent. Use a tool that records each completed batch and resumes from the first one that didn't confirm.

Look at every row before you sign

The same check covers most of the cases above. Before any transaction is built, you want a preview of each row: which rows are invalid, which addresses repeat, and the amount that was parsed for each one. A total on its own tells you very little. If you can't see the individual rows, you can't tell whether the list is right.

Multisender flags each invalid or duplicate row by line number, and the send stays blocked until you fix, merge or remove them. It records completed batches so a resumed run never pays anyone twice, and it shows the full recipient breakdown before you sign. The Multisender docs have the details.