How to airdrop tokens with multisend

Prepare the distribution before connecting a wallet

A multisend transfers your existing token balance to a list of recipients. It does not mint new tokens, verify eligibility or decide who should receive the airdrop. Start with an approved allocation and confirm that the sending wallet owns enough tokens on the selected network.

Build and review the CSV

Use one address and amount per row, such as address, 250 or address, 5%. The input supports an explicit token amount or a percentage of the chosen balance or supply. Keep recipient addresses and transaction records, but never put private keys or wallet recovery phrases in a distribution file.

• Use 0x addresses for the EVM network and exact, case-sensitive Solana addresses for SPL distributions. Do not mix networks in one list.
• Inspect repeated recipients and unintended allocations even if the parser accepts the rows. A valid address can still be the wrong person.
• Check percentage totals, rounding, the chosen balance/supply base and the resolved amount of every row. Percentages describe allocation amounts, not recipient eligibility.
• Review enough native currency for the batches. On Solana, new recipient token accounts can add account-creation costs beyond transaction fees.

Rehearse with a small list

Send to a few controlled addresses on a supported test network first. Check the received amounts in base units and displayed whole units. Use the same decimal assumptions and input format as the intended distribution, but remember that test assets do not become mainnet assets.

Send the batches

1. Open Multisend, select the intended token and import or paste the approved list.
2. Resolve every validation error and check the preview, total amount, percentage base and estimated batch count.
3. Confirm the review and approve the intended spend. EVM approval authorizes the multisender; it does not itself transfer the distribution.
4. Sign the prepared batches and retain the progress journal in the same browser. The app records each broadcast transaction and completed batch.
5. After completion, reconcile the saved transaction ids with the recipient list and confirm the expected final sender balance.

Recover an interruption without paying twice

If the wallet prompt closes or confirmation times out, keep the operation intact. Reloading restores the recipients, resolved amounts, frozen percentage base, completed batches and pending transaction. Resume first checks what happened to the outstanding transaction; an unknown result blocks sending rather than assuming failure.

Do not clear browser storage, change devices or paste the list into a new operation while a batch is unresolved. Check the original hash or signature on the correct explorer. A confirmed transfer should be counted, a confirmed revert may permit retry, and an unknown outcome needs reconciliation. Legacy pending records without the full journal require manual reconciliation rather than an automatic restart.

Keep a distribution record

Retain the approved input, resolved amounts, sending wallet, token address, network, transaction ids and any exceptions. Do not publish a recipient's private information just to prove a transfer. For a public allocation statement, link the relevant chain transactions and explain what was distributed.

Read token supply and tokenomics before allocating supply, and contract management if the token is paused or the wallet needs a valid management action first.