How to Run a Snapshot-Based Airdrop on Solana

Open-claim airdrops are a buffet for bot farms. Connect, fill the form, claim, dump. A snapshot-based airdrop flips this around. At a moment you choose, you freeze a photo of who owns what on chain, filter out the duplicates, then push tokens directly to that fixed list. The recipient has no form to sign. The tokens just appear in their wallet one morning, no action required on their side.

JTO did it this way, BONK ran its retroactive distribution on the same logic, and W and JUP followed the same shape. The common thread is straightforward. The distribution moment is fixed ahead of time, eligibility is auditable on chain, and the surface for manipulation stays 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 means

A snapshot is a simple idea once you set the jargon aside. It is the act of freezing a photo of who owns what at one second in time, then mailing checks based on that photo. Whoever shows up in the photo gets a check. Anyone who arrives after the shutter clicks is not in the picture, so they do not get one.

Here is a concrete example. You launched a token thirty days ago. Today you take a snapshot, meaning you produce a list of everyone holding your token right now, with how much each person holds. Then you airdrop a bonus token to those holders, proportional to their balance. People who buy after the snapshot do not qualify, because they were not in the photo. That is why timing the snapshot quietly matters.

Mechanically, the tool does the work of reading holders from chain and grouping balances by wallet. If the same person holds tokens in several spots, the snapshot collapses those into one wallet entry. The data was always sitting on chain. You are just taking a one-time picture of it.

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

1. Define who qualifies, in plain words

Before you snapshot, decide who is in. Three common models:

• Pure holder: anyone holding more than a set amount of tokens. Simplest model, most exposed to fake-account farming.
• Activity-gated: a holder who has also made at least one transaction in the last several days. Filters out idle wallets that have been sitting still.
• Stake or LP eligibility: a holder who has also staked the token or paired it in a liquidity pool. Highest-quality group, snapshot logic gets more involved.

The mental test is simple. Ask yourself: "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 people). Each row in the output shows the wallet address, total balance, percentage of total supply, how many account entries the wallet has (a useful fake-account signal), and optionally the 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.
• The 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, so do not lose the original.

3. Filter the raw list

The snapshot is not your distribution list. Addresses to take out:

• Exchange wallets (Binance, Coinbase, OKX, Kraken hot wallets). Airdropping to them sends tokens to the exchange itself, not to any of its users. Public lists exist for these, so pull one and add it to your blocklist.
• Smart contracts (liquidity pools, lending vaults, vesting contracts). These belong to a program, so an airdrop sent there gets locked inside the contract.
• Your own team or treasury wallets. Do not airdrop to yourself.
• Dust holders. Set a threshold (for example a balance under 0.001 token). Sending to those wallets costs more in fees than the airdrop is worth.

Filtering fake accounts is its own subject. Three signals worth checking first:

• Wallet age. Most wallets created within a week of your snapshot are airdrop farms. The Solana holder snapshot tool exposes the wallet creation time, so filter on it.
• On-chain activity. Wallets with only token-transfer history and no interaction with any other app are usually bots.
• Transfer patterns. The same amount fanning out to many fresh wallets is the classic fake-account cluster signal.

Perfect fake-account filtering does not exist. The target is not "zero fakes". The target is "running a fake-account farm costs more than the reward". Overly aggressive filters cut real users too.

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 (for example 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 from one form. A single Solana transaction can fit roughly 20-30 transfers, and the tool batches the rest behind the scenes.

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 the test network before going live. CSV format errors, sender balance shortfalls, and connection rate-limit issues all surface there. Catching them after going live means paying the fee twice.

6. Verify and announce

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

Announcement template:

• Snapshot time 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 fake accounts you then have to filter.
• Not blocklisting exchange 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 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 times per-transaction 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 at the end. A cheap trade compared to living through the chaos of an open claim window.