Solana Multi-Sender Guide: Airdrop, Batch, Snapshot
Solana multisender powers three distribution workflows: snapshot airdrop, manual batch payout, batch-collector cleanup. Walkthrough with j.tools tools.
Every Solana operator hits the same primitive eventually: send tokens to many wallets at once. Airdrop, team payout, affiliate distribution, partner share, KOL push, same operation underneath. The tool that performs it is a multi-sender.
This guide treats multi-sender as the protagonist. Snapshot and batch-collector are supporting tools that connect to it through one shared idea, a list of recipients with amounts. Three workflows, one primitive.
What a multi-sender actually does
The input is a recipient list. CSV or JSON, one row per wallet, address plus amount. The Solana multi sender tool accepts up to 1000 recipients per run and the data shape is exactly what you would write by hand:
// recipient list shape
[
{ address: "9xQ...", amount: 1500 },
{ address: "FbR...", amount: 250 },
{ address: "7Pz...", amount: 10 }
]
The handler iterates the list, signs each transfer with the sender keypair, submits through the configured RPC. It validates public keys, normalizes amounts, creates Associated Token Accounts where missing, records each transaction with its signature or failure reason. The output is a row-by-row report.
The mechanic is dull on purpose. The interesting part is what feeds the list.
Workflow A, snapshot-driven airdrop
The list comes from on-chain data. Pick a token, run the Solana token snapshot tool, get every wallet that holds it, filter, and feed the survivors into the multi-sender. The snapshot mechanic itself lives in the Solana holder snapshot guide; this section is about what happens after.
The filter step matters more than the snapshot. A raw holder list pulls in CEX hot wallets, pool accounts, lending markets, vaults, contracts that hold balances structurally. Send to those and tokens disappear into the exchange treasury or sit on a program account that cannot forward them. The fixes:
- Drop labeled CEX hot wallets (Binance, Coinbase, Kraken, OKX, Bybit, Bitget, MEXC).
- Drop pool owners (Raydium AMM, Meteora DLMM, Orca whirlpools) and known routers.
- Drop wallets with very low SOL and tiny token holdings. The combination is a sybil signal and an ATA-rent loss.
- Apply a minimum balance threshold. Sending 5 tokens to a 0.0001 percent holder usually costs more in fees than the airdrop is worth.
If the campaign needs tiers, do the tier math here, before the list reaches the multi-sender. The deeper walkthrough for eligibility, sybil filtering, and tiering lives in the snapshot-based airdrop guide.
Workflow B, manual batch payout
Now the list does not come from on-chain data. You wrote it. Team allocation: 12 wallets, named amounts. Affiliate payout: 60 wallets from the last billing cycle. Partner share: 4 wallets, dollar values converted at the day's price. KOL settlement: 30 wallets, contracted amounts.
Smaller count, wide amount variance, list lives in a spreadsheet, not on chain. No filter step because you curated the rows yourself. Feed it into the same Solana multi sender tool, run, archive the report for accounting.
Most teams use this workflow most often. Airdrops happen on launch. Payouts happen every month. The discipline is in the spreadsheet, signed off before the run.
Pre-check the sender's SOL balance against recipient count times a comfortable per-transfer fee, plus rent for any ATAs you might create. Running out of fee SOL halfway through a 400-row payout is the most common failure mode and the report shows exactly where it stopped.
Workflow C, recovery and cleanup
Sometimes you send the other direction. Many sources, one destination. The shape is the inverse of a multi-sender and has its own tool, the batch collector tool. Common cases:
- Dust cleanup. Small balances scattered across throwaway wallets used for testing or staggered buys.
- Treasury consolidation. Operations wallets that accumulated balances from fees, refunds, or routine activity.
- Unclaimed airdrop recovery. Tokens that went to wallets you control and were never picked up.
- Pre-migration sweep. Before a v2 launch or token swap, pull old-mint balances into one place for the bridge.
Batch-collector takes source wallets (with private keys), one destination, an optional per-wallet amount or a "collect everything" flag, and an optional SOL reserve so each source can pay its own closing fee. It iterates, signs, pushes, leaves enough lamports for the closing transfer to clear.
Which workflow when
From the outside the three look similar (a list, a tool, a result) but input source and frequency differ.
| Workflow | Source of recipient list | Typical scale | Frequency | When to pick it |
|---|---|---|---|---|
| Snapshot airdrop | Token holder snapshot, filtered | 500 to 10000 | Per launch or campaign | Reaching a community defined by on-chain holdings |
| Manual batch payout | Internal spreadsheet or billing system | 5 to 200 | Recurring (monthly, weekly) | Operational obligations: team, affiliates, partners |
| Recovery and cleanup | Wallets you control | 10 to 500 | Ad hoc, before migrations or quarter-end | Consolidating scattered balances back to treasury |
The j.tools setup, end to end
The three tools share a data model, so the workflows compose without translation steps.
- Feeder: if you need holders, run the Solana token snapshot tool. Export to JSON, apply filters, build the list.
- Fan-out: drop the list into the Solana multi sender tool. Token type, mint (for SPL), sender keypair, RPC endpoint. Run. Save the report.
- Fan-in: for the reverse direction, use the batch collector tool. Source wallets with private keys, one destination, collect-all flag to drain.
If you push from multiple source wallets (for example, splitting an airdrop across two operations wallets to ride below per-wallet caps), the many-to-many transfer tool covers that case directly.
Common mistakes
Most multi-sender problems show up in the report after the fact and trace back to one of four causes.
Sender runs out of fee SOL mid-batch. Each transfer costs lamports, ATA creation costs more. A 1000-row run with new ATAs needs real SOL for fees alone. The report shows good rows up to a point, then a wall of "insufficient funds" errors.
ATA existence not pre-checked. If half your recipients lack an ATA for the mint, you pay rent (around 0.00203 SOL per new ATA on SPL Token, slightly different on Token-2022) for each. Pre-check the snapshot's SOL-balance field; recipients with zero SOL and no ATA are the expensive ones.
Token-2022 with non-routing extensions. Some Token-2022 mints carry extensions (transfer hooks, confidential transfers, certain transfer fees) that need extra handling. A vanilla SPL transfer flow fails or behaves unexpectedly. Confirm the extension set first.
Multi-sender used as a substitute for KYC distribution. The tool moves tokens. It does not perform KYC, geographic exclusion, or sanctions screening. Do those checks upstream and feed only the cleared list. It sends faithfully to every address you give it, including the ones you should not have.
Rehearse on devnet first. Spin up a test mint, fund a sender with devnet SOL, run a five-row recipient list, read the report. A malformed CSV column caught on devnet is free; the same mistake on mainnet costs a few hundred dollars in wasted fees and a public failure.
The pattern that ties it together
Multi-sender is the primitive. The workflow you build around it is the differentiator. A clean snapshot, a filtered list, a rehearsed run, an archived report: the difference between airdrops people receive and a launch that quietly burns half its budget into dead wallets.
More walkthroughs live under our Solana guides category, and the broader stream of token mechanics posts sits at Solana tagged posts.
