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

The failure modes in a bulk send are almost always list problems, not blockchain problems — bad data in, bad transaction out. Here's what actually causes duplicate and failed sends, and how to catch each one before signing.

Duplicate recipients

The most common cause of an accidental double-send is the same address appearing twice in a recipient list — once from an original export, once from a manual addition, or duplicated across two merged spreadsheets. Most tooling doesn't deduplicate a list automatically, because there are legitimate reasons an address might intentionally appear twice with different amounts (two separate allocations to the same wallet). The safe default: sort your list by address before uploading and manually scan for adjacent duplicates, or use a spreadsheet formula to flag them, before you ever get to the signing step.

Trailing whitespace and invisible characters

Copy-pasting addresses out of a spreadsheet, PDF, or chat message frequently carries invisible baggage — a trailing space, a non-breaking space instead of a regular one, a smart quote substituted for a straight one. A Solana address with a trailing space isn't a valid base58 public key, so it should get flagged as invalid rather than silently sent to the wrong place — but it's worth spot-checking a few rows for exactly this if a list was assembled by hand rather than exported cleanly.

Amounts with too many decimals

If a token has 6 decimals and a row specifies 1250.123456789, that's more precision than the token can represent — most tools either reject the row or silently truncate it, and silent truncation means a recipient gets a slightly different amount than intended without any error surfacing. Round every amount to the token's actual decimal count before uploading, rather than relying on the tool to catch it.

Sending to a token account address instead of a wallet address

A common and costly mistake: pasting a token account address (the derived account holding a specific token's balance) into a field expecting a wallet address (the owner). These look identical in format — both are base58 public keys — but they're different accounts entirely. Sending to the wrong one can mean tokens land in an account with no clear owner path back to the intended recipient. Double-check you're working from a list of wallet addresses, not token accounts, especially if the list came from raw on-chain data rather than a curated recipient export.

Re-running a partially completed batch

If a bulk send is interrupted midway — a closed tab, a network drop, a batch transaction that failed — re-running from scratch without checking what already landed risks double-sending to everyone in the batches that succeeded before the interruption. This is the single most preventable failure: use a tool that tracks completed batches and only resumes from where it actually left off, rather than restarting the whole list blind.

The check that catches almost everything else: preview before you sign

Whatever the specific failure mode, the same defense works: a clear per-row preview before any transaction is built, showing exactly which rows are flagged as invalid, which are duplicates, and what the parsed amount for each row actually is — not just a total. A bulk send where you can't see individual rows before committing is a bulk send you're trusting blind.

Multisender flags bad rows individually in the preview rather than failing the whole list, tracks completed batches so a re-run never double-sends, and shows the full recipient breakdown before you sign anything. Full details in the Multisender docs.