General
How to Distribute Tokens to 100,000+ Wallets on Solana with Streamflow
A study of two million airdrop addresses found that roughly 64% of recipients sold their tokens immediately at the token generation event, and between 50% and 70% of airdropped tokens were dumped on exchanges within the first 30 days, according to CoinLaw's 2026 token airdrop statistics.
That is the actual problem with distributing tokens to 100,000 wallets, and it has nothing to do with the sending.
Streamflow, which supports distribution to up to one million recipients and has processed over $290 million in total value locked across 40,000+ projects, treats large-scale distribution as a design problem rather than a transfer problem.
On Solana, the mechanical part is close to solved. The network handles 65,000+ transactions per second with sub-second finality and near-zero fees, so pushing tokens to six figures worth of wallets is not where teams fail. They fail on eligibility, on release structure, and on what happens in the 72 hours after the claim portal opens.
This article covers how to distribute tokens to 100,000+ wallets on Solana without handing your supply to sybils and instant sellers, and exactly how Streamflow executes each step.
Key Takeaways
Streamflow supports airdrops of up to one million recipients, with 100,000 wallets per CSV file.
Distributing tokens on Solana at scale is a design problem, not a logistics problem.
Vested and price-based airdrops on Streamflow reduce the immediate sell pressure that kills tokens.
Eligibility filtering, claim windows, and unclaimed token recovery protect supply before distribution begins.
Over 40,000 projects use Streamflow to distribute tokens on Solana with on-chain verification.
The Mistake: Treating a 100,000-Wallet Airdrop as a Logistics Problem
Most teams approach a large distribution by asking how to send the tokens. They build a script, or they split a spreadsheet into batches, or they ask an engineer to write a custom program two weeks before token generation event day.
The question is wrong, because the sending is the cheapest part of the operation on Solana.
The expensive parts are the ones that get decided casually:
Who qualifies, and how the list survives sybil clusters.
Whether tokens land unlocked, vested, or gated on price.
How long the claim window stays open and where unclaimed supply goes.
What a recipient can do with the token five minutes after claiming it.
Get those four wrong and a technically flawless distribution still produces a chart that never recovers.
The industry data backs this up: Linea eliminated roughly 800,000 sybil wallets before landing on 749,000 final claimants, and LayerZero removed 803,273 wallets through its own filter.
Distribution at scale is a filtering and structuring exercise that ends in a transfer, not the reverse.
What Actually Breaks at 100,000 Wallets
Three things break, and they break in a predictable order.
Eligibility breaks first: A snapshot of a popular Solana protocol will return a list where a meaningful share of addresses belong to a handful of operators running wallet farms. Distributing to that list means paying farmers with supply meant for users.
Release structure breaks second: An unlocked airdrop to 100,000 wallets is a synchronized sell order. The 64% same-day sell rate is not a coincidence, it is the mechanical consequence of giving liquid tokens to a large group with no reason to hold them.
Operations break third: Claim tracking, delivery status, unclaimed token recovery, and support load all become real work at six figures of recipients. Teams that scripted the transfer have no interface for any of it.
Consider the practical version. A team airdrops 5% of supply to 120,000 wallets on launch day, unlocked, with no eligibility filter beyond a snapshot. Within a week the price is down, the community blames the team, and the treasury has nothing left to fix it with. Every one of those outcomes was decided before the first transaction was signed.
The Framework: Five Decisions Before You Upload the CSV
1. Filter the list before it becomes a distribution
Eligibility is the highest-leverage decision in the entire campaign. A list of 300,000 addresses filtered down to 100,000 real participants is worth more than the raw list, even though it distributes to fewer people.
Streamflow supports audience segmentation and eligibility filtering as part of campaign setup, alongside a sybil checker and a multi-wallet airdrop checker as standalone utility tools. The workflow is snapshot, then eligibility, then claim window, then post-claim activation, in that order.
Segment by depth of activity, not presence in a snapshot.
Cluster-check funding sources before finalizing the list.
Cap allocations at the top end to blunt farm economics.
For deeper tactics on this step, Streamflow's guide to sybil-resistant airdrop strategies covers the filtering patterns that survive contact with real farming operations.
2. Choose the release shape, not just the amount
The size of the allocation gets debated for weeks. The shape of the release usually gets decided in an afternoon, which is backwards, because the shape determines whether the allocation survives.
Streamflow supports four distribution types through its airdrop launch platform:
Instant airdrops: tokens land immediately, best for small allocations to verified users.
Vested airdrops: tokens release on a schedule after claim, spreading sell pressure across months.
Price-based airdrops: releases unlock against price thresholds rather than time alone.
White-label airdrops: the same logic delivered through a fully branded portal.
A 100,000-wallet campaign rarely wants one shape for everyone. Vesting the large allocations while releasing the small ones instantly keeps the long tail happy and stops whales from exiting on day one.
3. Design the claim, not just the drop
Claim mechanics decide what percentage of your supply actually leaves the treasury. A claim window that closes returns unclaimed tokens; a window that never closes leaves the overhang on the chart forever.
Streamflow handles claim portals, claim window logic, claim status tracking, real-time delivery status, and unclaimed token recovery natively. At 100,000+ wallets these stop being features and start being the operation itself.
Set a hard claim window and communicate it early.
Route unclaimed supply back to treasury on close.
Track delivery status in real time rather than fielding it in Discord.
4. Lock and vest everything the airdrop doesn't touch
An airdrop is judged against the rest of the cap table. If 5% goes to the community while 25% sits unlocked in team wallets, recipients read the distribution correctly and act accordingly.
This is why token locks on Solana and automated token vesting belong in the same launch plan as the airdrop. Locked tokens cannot be transferred, traded, or accessed before the unlock conditions are met, and the proof is a public link anyone can verify on Solscan or Solana Explorer.
Setting a lock takes about 37 seconds in the app, which is less time than most teams spend arguing about whether to do it.
5. Give claimed tokens somewhere to go
Post-claim activation is the step almost everyone skips, and a recipient who claims a token and finds no use for it has exactly one action available. Streamflow's no-code staking pools let teams deploy a destination for freshly claimed tokens without engineering work, on any SPL token, with configurable APY, lock periods, and reward logic.
Launch the staking pool before the claim portal opens, not after.
Fund rewards to cover the claim window plus the following quarter.
Use governance staking where the token has a real voting function.
How Streamflow Executes a 100,000-Wallet Distribution
Streamflow was built for exactly this operation, which is why the framework above maps onto product steps rather than engineering tickets. Over 40,000 projects run token distribution on the platform, and the logic is enforced by audited on-chain contracts instead of by a script someone wrote the week before launch. The section below walks the campaign end to end.
The execution flow
The mechanics compress into four steps, each one configured in the interface rather than coded.
Upload recipients: Import the filtered list by CSV, with audience segmentation applied so different cohorts can receive different terms.
Define the distribution type: Instant, vested, price-based, or white-label, set per campaign.
Launch the claim portal: Configure the claim window, the eligibility gate, and the recovery path for unclaimed supply.
Users claim: Contracts execute automatically, with delivery status and claim tracking visible in real time.
The team's work ends at step three. Nothing after that depends on anyone being awake, which matters when 100,000 wallets are claiming across every timezone at once.
Capacity, CSV limits, and plan tiers
Capacity is the constraint most teams discover too late, so plan it before the launch calendar is set.
Up to 1,000,000 recipients per campaign.
100,000 recipients per CSV file, so a 100,000-wallet drop is a single clean import.
Standard plans cover roughly 30,000 recipients per airdrop.
Larger campaigns run on the enterprise tier.
A 120,000-wallet distribution therefore means two CSV imports on an enterprise footprint. Compare that to the alternative, which is a custom program, an audit cycle, and a rewrite when the eligibility list changes two days before launch.
Claim tool versus full launch platform
Streamflow offers two levels of distribution, and choosing the wrong one is the most common execution mistake at scale.
Claim tool: a lightweight, recipient-facing claim flow. Fine for a few thousand verified wallets.
Full launch platform: end-to-end coverage including eligibility, CSV upload, custom claim portal, vesting on claim, and analytics.
At 100,000+ wallets, the full launch platform is the only realistic option. Vesting on claim in particular only exists at this level, and it is the single feature that separates a distribution from a synchronized sell order.
No-code path versus SDK path
Two teams can run the same 100,000-wallet campaign through completely different surfaces.
The no-code path runs entirely through the interface: create the contracts, configure the parameters, deploy instantly. For reference on speed, locking tokens on Streamflow takes about 37 seconds, and airdrop configuration follows the same pattern of setup rather than development.
The developer path uses the Streamflow SDK to embed distribution directly into an existing dApp. Custom claim logic, vesting schedules, and reward systems can all be built on top of the same contracts the interface uses, which means a protocol can run the drop inside its own product without recipients ever visiting a third-party page.
Open the Streamflow app to configure the campaign, or build the same flow against the SDK.
Branded claim portals
For campaigns where the claim page is a marketing surface and not just a utility, Streamflow's white-label layer covers custom claim portals, custom token distribution portals, branded staking pages, and lock dashboards, with bespoke onboarding from the Streamflow team.
This matters more at scale than it looks on paper. A 100,000-wallet campaign is a phishing magnet, and every fake claim site that appears in the first 48 hours is competing with your real one.
A branded portal on your own domain, promoted only through official channels alongside the official eligibility checker, is the cheapest anti-phishing measure available.
Tracking the distribution after launch
Execution does not end at the claim. Streamflow's tokenomics dashboard gives a real-time view of token distribution across vesting contracts, token locks, and staking pools in one place, including release progress, cliff dates, and unlock events.
Public by default, so recipients verify rather than trust.
Consolidates every contract into a single view instead of a spreadsheet.
Doubles as the answer to "when do team tokens unlock," asked 400 times in Discord.
Every contract is verifiable independently on Solscan and Solana Explorer, and the contracts themselves are audited by FYEO and OPCODES. The distribution you designed is the distribution 100,000 recipients can confirm for themselves.
Case Study: How Bonk Distributed at Solana Scale
Bonk is the Solana meme coin that allocated 55% of its total supply to airdrops for early Solana users, one of the largest community-first distributions the network has seen. The interesting part is not the airdrop percentage, it is what Bonk did with the rest.
The team used Streamflow for core team vesting: 20% of total supply, across 22 early contributors, on a 3-year linear vesting schedule. That structure meant the community received the majority of supply while the team's allocation was locked into an immutable, publicly verifiable contract.
The outcome was trust that the airdrop alone could not have bought. A large distribution paired with a verifiable 3-year team lock is a fundamentally different signal than the same distribution with unlocked team wallets sitting next to it.
What This Means for Founders and Tokenomics Designers
If you are planning a distribution to 100,000+ wallets, the sequencing is the strategy. Decide eligibility, release shape, claim window, and post-claim destination before anyone touches a CSV, because each one is enforced by an immutable contract once deployed.
For founders thinking past the launch, the same infrastructure extends into treasury management, payouts, on-chain cap tables, and ownership issuance through Streamflow Business, the financial OS for Internet Capital Markets on Solana. The airdrop is the first financial operation most token teams run at scale. It is rarely the last.
Conclusion
Distributing tokens to 100,000+ wallets on Solana is not a throughput challenge, it is a design challenge, and the 64% same-day sell rate across two million airdrop addresses is the evidence.
Streamflow handles the mechanics at up to one million recipients per campaign while giving teams the eligibility filtering, vested and price-based release logic, claim windows, and staking destinations that decide whether the distribution builds a token economy or ends one.
Book a demo to see how Streamflow handles a 100,000-wallet airdrop end to end, from CSV import to vested claims.
Read Next:
FAQs:
1. How many wallets can Streamflow airdrop tokens to at once?
Streamflow can airdrop tokens to up to one million recipients per campaign. Recipients are imported at 100,000 wallets per CSV file, so a 100,000-wallet distribution is a single import. Standard plans cover roughly 30,000 recipients per airdrop, with an enterprise tier for larger campaigns.
2. What is the best way to distribute tokens to 100,000+ wallets on Solana?
The best way to distribute tokens to 100,000+ wallets on Solana is to filter eligibility first, choose a vested or price-based release rather than an instant one, run the drop through a claim portal with a defined claim window, and give claimed tokens a staking destination. Streamflow supports all four steps in a single platform, so the design is enforced by on-chain contracts rather than by process discipline.
3. Can Streamflow prevent sybil wallets from claiming an airdrop?
Streamflow provides eligibility filtering and audience segmentation inside the campaign setup, plus a standalone sybil checker and multi-wallet airdrop checker as utility tools. These reduce sybil exposure by letting teams cut clustered and low-quality addresses before the list becomes a distribution. Final eligibility criteria are always the team's decision.
4. What happens to tokens that recipients never claim?
Tokens that recipients never claim are returned to the project. Streamflow supports unclaimed token recovery at the close of the claim window, so supply that goes unclaimed goes back to the treasury rather than sitting as a permanent overhang.
5. Is a large Solana airdrop expensive to run on Streamflow?
A large Solana airdrop on Streamflow is cost-efficient because it runs on Solana, where fees are near-zero and finality is sub-second. Costs come down to smart contract creation fees plus network transaction fees, which is a materially different cost structure than executing the same distribution on Ethereum.
