How to Send Tokens to Thousands of Wallets Onchain: Batch Transfers Explained

Most batch transfer tools work the same way: paste a list of addresses, sign a transaction, and the contract loops through the list sending tokens one by one. That works for 50 wallets. It starts hurting at 500, and it breaks entirely at 5,000, when gas costs, block limits, and failed transfers to contract addresses turn a simple payout into an operations problem.

Sending tokens to thousands of recipients is not a bigger version of sending tokens to one. It is a different problem, and it needs a different mechanism.

This guide covers when onchain rails beat traditional payout providers, how batch transfers work onchain, why the standard multisender approach stops scaling, and how to send tokens to any number of wallets in a single funding transaction using Merkl.

What is a batch token transfer?

A batch token transfer is a single operation that sends tokens to many recipients at once, instead of executing one transfer per wallet. Teams use batch transfers for airdrops, contributor payroll, community rewards, refunds, dividends on tokenized assets, and mass payouts in stablecoins to tens, hundreds, or thousands of addresses.

To be clear on scope: this is not about one-to-one payments. Sending USDC to a single freelancer is a wallet feature. Sending USDC to 3,000 contributors, or an airdrop to 200,000 users, is a distribution problem. That is what this guide is about.

Onchain rails or a traditional payout provider?

Before comparing onchain tools with each other, many teams are still weighing a prior question: why move the payout onchain at all, instead of running it through banks or a payout provider?

The short version: with stablecoins as the payment asset, cost stops depending on geography (no per-corridor pricing, no FX margin between USD-pegged tokens), settlement takes hours rather than business days and works on weekends, the entire payout is one operation instead of thousands of individual transfers that can each bounce, and the audit trail is the ledger itself. The trade-offs are just as clear: recipients need a wallet, converting to local currency happens outside these rails, and your tax and reporting obligations do not change with the rail.

The rest of this article assumes the payout is onchain, and focuses on doing it well.

Push vs pull: the two batch transfer models

Once the payout is onchain, there are two ways to execute it, and the difference between them determines your cost, your scale ceiling, and how much can go wrong.

Push: the multisender approach

Push tools (multisenders, disperse-style contracts, Safe CSV airdrops) execute every transfer inside the transaction you sign. The sender pays gas for each recipient, all at once.

Three things break at scale:

Gas scales linearly with recipients. Ten thousand recipients means ten thousand token transfers worth of gas, paid upfront by the sender. On an L1, that alone can eat a meaningful share of the amount being distributed.

Block limits cap the batch size. A single transaction cannot contain unlimited transfers. Large lists have to be split into dozens of transactions, signed and monitored one by one. One failed chunk in the middle and you are reconciling a half-executed payout by hand.

Contract recipients cause silent failures. Some addresses on your list are smart contracts: multisigs, vaults, exchange deposit addresses. Some of them cannot handle the incoming transfer, or the tokens land somewhere the actual owner never sees. With push, the tokens are gone the moment you sign.

Pull: Merkle-based distribution

The pull model inverts the flow. Instead of sending tokens to every wallet, the sender publishes the full list of entitlements as a Merkle root and deposits the total amount once. Each recipient then claims their tokens whenever they want, paying only their own claim gas.

This is how Merkl distributes tokens, and it changes the economics completely:

• One funding transaction, any recipient count. Whether the list has 40 addresses or 400,000, the sender signs once. The cost of the operation does not grow with the number of recipients.
• No failed transfers. Tokens sit in the Merkl Distributor Contract until claimed. Nothing is pushed into a contract that cannot receive it.
• Recipients claim on their own terms. They claim from the Merkl App, or any interface with the Merkl API integrated, whenever they want.
• Unclaimed tokens are not lost. Once the distribution ends, the sender can freely reallocate whatever was never claimed. With push transfers, there is no getting anything back.

What a batch transfer costs

Cost is where the two models diverge most.

With a push multisender, the real cost is gas, and it compounds with list size and chain choice. A large distribution on Ethereum mainnet can cost more in execution than many teams expect to spend on the entire operation. Dust entitlements make it worse: sending a $0.40 payout can cost more than $0.40 to execute.

With Merkl, the sender pays gas for a single funding transaction, and JSON-based airdrops are charged a reduced fee of 0.5% of the distributed amount, compared to the 3% standard campaign fee. The fee is added on top of what you distribute, so recipients always receive the full amount: send 100,000 USDC to your list, and the system pulls 100,500 USDC from your address. For large distributions, a fixed fee can be arranged with the team. Full details are in the fee model documentation.

For most teams, the comparison is straightforward: a flat 0.5% with one transaction to sign beats per-recipient gas, transaction batching, and manual reconciliation, and the gap widens with every additional recipient.

How to batch transfer tokens with Merkl

Everything runs from the Airdrop campaign template in Merkl Studio, with no smart contract to deploy and no code to write.

1. Open the template. Go to studio.merkl.xyz/templates/airdrop-campaign. If confidentiality matters, use Airdrop Tokens Privately instead.
2. Upload your recipient list. Provide a JSON file mapping each address to its amount, either by uploading it directly or linking to a hosted file. The expected format follows a simple template available in Merkl Studio.
3. Select the chain and schedule. Choose the chain the tokens live on. Keep "Execute immediately" on for a one-shot payout, or set dates to schedule the distribution.
4. Review and fund the batch. Set the reward token in the batch settings, review, and sign the funding transaction. You can bundle several distributions, even on different terms, in the same batch.
5. Recipients claim on Merkl. Each recipient sees their tokens in their Merkl dashboard and claims when they choose. Tokens become claimable about two hours after the funds are sent, the time for the Merkl Engine to process the distribution and push it onchain.

The same flow scales from a 30-address contributor payout to a six-figure-wallet airdrop, because the mechanism underneath does not change. For a walkthrough with screenshots, see the step-by-step airdrop guide.

And if you would rather recipients not have to claim at all, Merkl's Autoclaim service runs the claims in the background and pushes tokens directly to recipient wallets, on the cadence you define and with a minimum amount per claim so gas never exceeds the payout. Push-style UX, on pull-style infrastructure.

Keeping custody: batch transfers without prefunding

In the standard flow, you deposit the budget into Merkl's distribution contracts upfront. Some teams cannot or do not want to do that: treasury policy, multisig governance, or simply the size of the amounts involved.

For these cases, Merkl supports token wrappers: small contracts that pull the underlying tokens from your address only at the moment a recipient claims, through a standard ERC-20 allowance. The funds stay in your treasury, multisig, or any address you control until then.

This changes the risk profile of a large batch transfer:

• No prefunding. Nothing is transferred to Merkl upfront. You only spend what is actually claimed.
• Unclaimed tokens never leave your address. Recipients who never claim cost you nothing.
• You stay in control. Revoke the allowance to pause the distribution, or top up the address to extend it, without any Merkl operation.

Wrappers deploy directly from Merkl Studio in a few clicks, with Pull-on-Claim being the standard template for airdrops and batch transfers.

Making batch transfers private

By default, onchain transfers are public. Anyone can see who paid whom and how much, which is a problem for payroll, bonuses, or any payout where amounts should stay between sender and recipient.

Merkl supports private batch transfers. Private distributions do not appear in the Merkl App or the API, and because every campaign on Merkl funds the same Distributor Contract, individual claims cannot be traced back to the sender. Recipients only see their own allocation, never anyone else's.

This unlocks payouts that were previously impractical onchain: paying a team in tokens without every salary being public, running vesting programs where contributors cannot compare allocations, or settling deals discreetly.

What teams use batch transfers for

• Airdrops: distribute a token launch or a rewards season to the full eligible user base in one operation.
• Payroll and contributor payments: pay a team or a contributor network in USDC or another stablecoin on a schedule, publicly or privately, from a single funding transaction per pay cycle.
• Community and quest rewards: settle points seasons, contests, or ambassador programs based on your own eligibility data.
• Dividends and yield on tokenized assets: distribute stablecoin entitlements to holders pro-rata. See the full guide on distributing dividends onchain.
• Refunds and reimbursements: return funds to a list of affected users without processing each one manually, like the $634M Hourglass refund.

FAQs

What is the cheapest way to send tokens to thousands of wallets?

A Merkle-based pull distribution. The sender funds the distribution in a single transaction regardless of recipient count, and each recipient pays only their own claim gas. On Merkl, JSON-based airdrops carry a 0.5% fee added on top of the distributed amount, so recipients receive the full amount, and a fixed fee can be arranged for large distributions.

Is a stablecoin batch transfer cheaper than a traditional payout provider?

For cross-border payouts, usually yes. Traditional providers charge per payment and add an FX margin on each transfer, so cost scales with recipients and countries. A stablecoin batch transfer is one funding transaction plus a 0.5% fee on Merkl, with no FX spread between USD-pegged tokens, whatever the recipient's location. For domestic, single-currency payouts, traditional rails can stay competitive; the gap opens as recipient count and countries grow.

How many recipients can a batch transfer support?

With push multisenders, block gas limits cap each transaction at a few hundred transfers, so large lists require many transactions. With a Merkle-based distribution like Merkl's, there is no practical ceiling: the recipient list is committed as a single Merkle root, so a distribution to 500,000 wallets costs the sender the same single funding transaction as a distribution to 50.

Can I batch transfer tokens without writing code or deploying a contract?

Yes. In Merkl Studio, you upload a JSON file of addresses and amounts, select the chain and token, and sign one funding transaction. No smart contract deployment, no scripts, no developer time.

How long does a batch transfer take?

Funding takes a single transaction. Recipients can then claim their tokens about two hours after the funds are sent, the time for the Merkl Engine to process the distribution and push it onchain.

Can I use batch transfers for mass payouts in stablecoins?

Yes. Mass payouts are one of the main uses of batch transfers: paying contributors, settling rewards, or distributing refunds in USDC or another stablecoin. The sender uploads the payout list, funds it once, and each recipient claims their share. For recurring payouts like payroll, the same list can be reused and adjusted each cycle.

Can batch transfers be private?

Yes. Merkl supports private distributions that are hidden from the app and the API. Because all campaigns fund the same Distributor Contract, claims cannot be traced back to a specific sender, and recipients only see their own allocation.

Do I have to send all the funds to Merkl before the batch transfer?

No. The standard flow prefunds the distribution in one transaction, but Merkl also supports token wrappers that pull funds from your treasury only when each recipient claims. Nothing is transferred upfront, you only spend what is actually claimed, and unclaimed tokens never leave your address.

What happens to tokens that recipients never claim?

With push transfers, tokens are sent whether or not the recipient ever notices. With Merkl's pull model, unclaimed tokens remain in the Distributor Contract, and the sender can freely reallocate them once the distribution ends.

Which chains support batch transfers through Merkl?

Merkl operates on 60+ chains, including Ethereum, Base, Arbitrum, and non-EVM chains starting with Stellar. The same Merkl Studio flow works across all of them.