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.

---

What is a Solana airdrop?

A Solana airdrop is a token distribution where a project sends tokens straight to a set of wallets, with no purchase and no claim form on the recipient side. The sender picks the addresses, decides how much each one gets, and pushes the transfers on chain. Because Solana settles in well under a second and charges fractions of a cent per signature, sending to thousands of wallets stays fast and cheap compared to most other chains. The snapshot method in this guide is one way to build that recipient list fairly, by reading real on-chain balances instead of trusting a sign-up form.

This is a distribution guide, not a "claim free airdrop" page

Two very different people search for "Solana airdrop." One is a holder hunting for free tokens to claim. The other runs a project and needs to send tokens to a community. This guide is for the second person. There is nothing here to claim, no wallet to connect for a reward, and no list of upcoming drops.

If a site asks you to connect your wallet and "claim" an airdrop, slow down. Real snapshot-based drops like the ones above land in your wallet on their own, with no signature required from you. A claim page that needs a transaction approval is a common drainer pattern.

If you are launching the token you plan to distribute, start at the source with the Solana token creator, then come back here to plan the snapshot and the send.

How much does a Solana airdrop cost?

The cost of an airdrop is mostly the cost of opening token accounts, not the tokens themselves. Three line items add up, and the first one surprises most teams running their first drop.

• Associated Token Account (ATA) rent. Every wallet that does not already hold your token needs an account created for it the first time it receives that token. On Solana that account is rent-exempt, which means the sender deposits a small fixed amount of SOL per account. For a drop to ten thousand fresh wallets, that rent is the largest part of your bill. Wallets that already hold the token skip this cost entirely.
• Network (transaction) fee. The base signature fee per transaction is tiny, a small fraction of a cent. Even batched across thousands of recipients this stays negligible next to the ATA rent.
• Tool fee. The j.tools distribution tools charge a small platform fee for a run. The exact amount is always shown on the tool page before you confirm, so check the current number on the multi sender tool rather than guessing.

A practical way to estimate: count how many recipients are brand-new to your token, multiply by the per-ATA rent, then add the network and tool fees on top. Skewing your eligibility rules toward existing holders, instead of opening fresh accounts everywhere, is the single biggest lever on total cost.

One more cost note that is easy to miss. If part of your supply goes undelivered, or you want to pull leftover tokens back out of dispersal wallets after the drop, sweeping them into one place with the multi collector tool keeps stray balances from sitting forgotten across dozens of addresses.