Bulk send SOL or SPL tokens to many wallets at once

How a Solana multisender batches transfers

A Solana transaction is capped at 1,232 bytes, so a bulk send is really a series of transactions that each carry as many transfers as fit. A plain SOL transfer is one System Program instruction and one new account key, and 20 recipients fit in a single transaction here. A token transfer needs two instructions per recipient — create the associated token account if it is missing, then transfer — plus two new account keys, which works out to 9 recipients per transaction. Sending to 1,000 wallets therefore takes 50 transactions for SOL or about 112 for an SPL token.

Signing a hundred transactions one by one would be painful, so the tool asks your wallet to sign them in groups of up to 12 with a single approval, then broadcasts and confirms that group before moving on. Wallets that cannot sign several transactions at once fall back to one approval per transaction. Every transaction is independent: if one fails or expires, the others still land, and the tool knows exactly which recipients were in the one that did not.

What it costs to airdrop SPL tokens on Solana

There are three separate costs. The network fee is 5,000 lamports (0.000005 SOL) per transaction, which is negligible. The SOLTidy fee is 0.0005 SOL per recipient. The big one for token airdrops is rent: a wallet that has never held your token has no token account for it, and creating one costs 0.00203928 SOL, paid by the sender. For 1,000 brand-new holders that is about 2.04 SOL in rent, 0.5 SOL in service fees and well under 0.001 SOL in network fees.

Because rent dominates, the estimate has to be exact. Before you sign, the multisender looks up every recipient's associated token account in chunks of 100 and counts the ones that do not exist yet, so the total shown is what you will actually pay. If your balance cannot cover the tokens plus the SOL for rent and fees, sending is blocked instead of failing halfway. Sending SOL has no rent cost, with one catch: a brand-new address must receive at least 0.00089088 SOL or the network rejects the transfer, and the tool flags those lines.

Preparing a recipient list or CSV for a batch transfer

Each line is one recipient: an address followed by an amount, separated by a comma, space or tab, exactly as a spreadsheet exports it. Amounts are in whole tokens, not raw units — 1.5 means 1.5 tokens — and may not have more decimal places than the mint supports. Lines with only an address use the equal amount field. A header row such as address,amount is ignored, and amounts are handled as exact integers internally so nothing is lost to floating-point rounding.

Duplicates are common when lists are merged from several sources. The tool shows which lines repeat and lets you either merge them into one transfer with the summed amount or keep them as separate transfers. Off-curve addresses deserve attention: they are program-derived addresses with no private key, such as vaults or pool accounts. SOL can be sent to them, but tokens sent to a PDA's token account are only recoverable if the owning program supports it, so for tokens they are skipped unless you explicitly allow them.

Failed transactions, retries and never paying twice

On a busy network some transactions will not confirm before their blockhash expires, roughly 60 to 90 seconds after signing. The multisender records the signature of every transaction and maps it to the recipients inside it. When the run ends, anything not confirmed is looked up on chain again, because a confirmation timeout does not always mean the transaction missed. Only then are recipients marked as succeeded, failed or unresolved.

Retry failed rebuilds transactions for the unpaid recipients only. Recipients whose transaction landed are never included again, and if a transaction is still unresolved the tool makes you wait until it has either landed or expired before it will resend, which removes the double-payment risk. The CSV report lists address, amount, status and signature for every line, so you have a record for your community or your accounting. Nothing about the list is stored on a server or in your browser after you leave.

Token-2022 airdrops and other edge cases

Token-2022 mints are supported with the same flow; the tool passes the mint's own program to every instruction and uses the checked transfer variant, which verifies mint and decimals on chain. If the mint has a transfer fee extension, recipients receive the amount minus that fee and the panel tells you so. Mints with a transfer hook need extra accounts that are specific to each hook program, so those are blocked rather than sent to fail. The first transaction is simulated before you are asked to sign, which catches mint-wide problems such as non-transferable tokens or a frozen source account; a single frozen recipient account only fails the one transaction it is in.