How to Run a Snapshot-Based Airdrop on Solana

Open-claim airdrops are a buffet for bot farms. Connect, fill, claim, dump. A snapshot-based airdrop flips this: at a moment you choose, you read eligible addresses off-chain, filter the duplicates, then push tokens directly to those wallets. There is no form for the recipient to sign. The tokens just appear one morning.

JTO did this. BONK's retroactive distribution worked the same way. W and JUP followed the same shape. The common thread: the distribution moment is fixed, eligibility is auditable on-chain, and the manipulation surface is small.

This walkthrough covers a snapshot-based airdrop on Solana end to end, using the Solana token snapshot tool and the Solana multi sender tool from j.tools.

What a snapshot actually does

Holders of a Solana token are stored on-chain as token accounts. Each one is a (mint, owner, balance) triple. A snapshot is the act of reading those accounts at a specific slot (or in practice, "right now") and producing a list. The data is already there; you are just freezing a frame of it.

Mechanically, the tool issues a getProgramAccounts RPC call filtered by mint, then groups balances by owner so the same person holding multiple ATAs for the same mint collapses to a single row.

Timing matters. If you announce a snapshot before taking it, people last-minute their balances and inflate the list. Take it quietly, then announce "snapshot was taken at slot X" after the fact.

1. Define your eligibility rule

Before you snapshot, decide who qualifies. Three common models:

• Pure holder: anyone holding more than X tokens. Simplest, most sybil-exposed.
• Activity-gated: holder plus at least one transaction in the last N days. Filters out idle wallets.
• Stake or LP eligibility: holder plus token is staked or paired in an LP. Highest-quality group, snapshot logic gets more involved.

The mental test: "would this wallet exist if I were not running an airdrop?" The yes set is your real community.

2. Take the snapshot

The j.tools snapshot tool takes a mint address and a top-holder count (100, 500, 1000, 5000, or 10000). Each row in the output: owner address, total balance, supply percentage, token-account count (useful as a sybil signal), and optionally SOL balance.

Typical run:

• Paste the mint address.
• Pick a top-holder count. 5000 covers most launches.
• If "include SOL balances" is on, you see at a glance whether each holder is a dead wallet or an active one.
• Tool exports the result as JSON or CSV.

Back up the raw output before you touch it. The same list gets reworked across several filtering passes; do not lose the original.

3. Filter the raw list

The snapshot is not your distribution list. Addresses to remove:

• CEX wallets (Binance hot wallets, Coinbase, OKX, Kraken). Airdropping to them sends tokens to the exchange, not to any of its users. Public lists exist; pull one and blocklist it.
• Smart contracts (LP pools, lending vaults, vesting contracts). These are program-owned; an airdrop to them locks tokens inside a contract.
• Your own team or treasury wallets. Do not airdrop to yourself.
• Dust holders. Set a threshold (e.g. balance under 0.001 token); sending to those wallets costs more in fees than the airdrop is worth.

Sybil filtering is its own subject. Three signals worth looking at first:

• Wallet age. Most wallets created within 7 days of your snapshot are airdrop farms. The Solana holder snapshot tool exposes account creation slot; filter on it.
• On-chain activity. Wallets with only token-transfer history and no interaction with any other program are usually bots.
• Transfer patterns. The same amount fanning out to many fresh wallets is the classic sybil cluster signal.

Perfect sybil filtering does not exist. The target is not "zero sybil"; it is "the economics of running a sybil cluster cost more than the reward". Overly aggressive filters cut real users.

4. Compute per-wallet amounts

Three common allocation models:

Model	How it works	Strength
Flat	Same amount to every eligible wallet.	Simplest. Fits a "fair distribution" narrative.
Tiered	Bracketed by holder size (e.g. 100-1k holders = X, 1k-10k = 2X, 10k+ = 5X).	Rewards larger holders while still including small ones.
Sqrt	Proportional to the square root of the holder's balance.	Softens whale dominance and gives small holders a relatively larger slice.

Before you divide the total allocation by eligible wallet count, sanity check it: is the per-wallet amount worth more than the gas to claim and trade it? If not, change the model or raise the eligibility threshold.

5. Send the airdrop

With the list ready, the Solana multi sender tool takes a CSV or JSON recipient list and splits the thousand-row distribution into batched transactions in one form. A single Solana transaction can fit roughly 20-30 transfers; the tool batches behind the scenes.

// Multi-sender input shape (j.tools Multi Sender)
{
  tokenMint: "Token...mint",
  tokenType: "SPL",
  recipients: [
    { address: "Recipient1...", amount: 1000 },
    { address: "Recipient2...", amount: 1000 },
    // ...thousands of rows
  ],
  senderPrivateKey: process.env.AIRDROP_SENDER_KEY,
  rpcEndpoint: process.env.RPC_URL,
}

If you are pushing from multiple source wallets, the many-to-many transfer tool handles the cross product. For very large lists where relaying across funded intermediates is cheaper than a single sender batch, the multi-to-multi relay tool takes that pattern.

Run a 20-recipient test airdrop on devnet before mainnet. CSV format errors, sender balance shortfalls, and RPC rate-limit issues all surface there. Catching them on mainnet means paying the fee twice.

6. Verify and announce

Once the batches finish, the tool returns a success / failure list. Set the failures aside (typical causes: RPC timeout, invalid address) and run a second pass on those. Whatever still fails, surface it in your airdrop report.

Announcement template:

• Snapshot slot or timestamp.
• Eligibility criteria, word for word.
• Filters applied and the count removed for each (how many wallets, why).
• Total distributed and the final eligible wallet count.
• A representative batch of distribution transactions (Solscan links).
• If you are opening a claim window for failed addresses, the deadline.

That level of clarity answers ninety percent of the "why did I not get any" follow-ups before they happen.

Common mistakes

• Announcing the snapshot in advance. Inflates the list and creates the sybils you then have to filter.
• Not blocklisting CEX wallets. Tokens land in the exchange's spot wallet rather than reaching any user.
• Stuffing too many transfers per transaction. Solana's transaction size limit (1232 bytes) caps the count; the tool batches automatically, but hand-rolling will hit this fast.
• Sender wallet runs out of fee SOL. Budget rough transfer count × per-tx fee, plus a buffer.
• No plan for unclaimed amounts. Hold the failures aside; after a claim window closes, pull tokens back to treasury or retire them with the Solana token burn tool.

For more launch and token mechanics writeups, the Solana guides category covers adjacent topics, and the Solana tagged posts page collects related deep-dives.

A snapshot airdrop, planned well, is a 4-5 hour job: one hour on eligibility, thirty minutes on the snapshot, one hour on filtering, one hour on math, one hour on distribution, plus some retry cleanup. A cheap trade for not living through the chaos of an open claim.