How to Airdrop Tokens on Arc: Snapshot, Upload, Batch Send
Run an Arc airdrop in minutes: snapshot holders with a free tool, upload the CSV and batch-send tokens or native USDC. Flat 50 USDC, no code required.
An Arc airdrop is two steps: get the recipient list, then batch-send to it. The list comes from a free Arc Token Snapshot, which reconstructs holder balances at a block you choose and exports a CSV; the sending is done by Arc Token Multisender, which groups recipients into batches so you pay transaction overhead a handful of times instead of once per wallet, for a flat 50 USDC service fee plus gas in USDC.
Everything below is the part people get wrong: the cost arithmetic, the choice between a direct send and a claim-based airdrop, how to avoid handing your tokens to a bot farm, and the address types that will break a batch.
What an Arc airdrop costs
Three line items:
| Line item | Cost |
|---|---|
| Recipient list | Free (snapshot tool) |
| Multisender service fee | 50 USDC flat, any number of recipients |
| Network gas | USDC, per batch — the variable you should estimate |
Gas on Arc is charged in native USDC at 18 decimals, with a minimum maxFeePerGas of 20 Gwei. At that floor, 1,000 gas costs 0.00000002 USDC, so batching is where the savings live:
| Approach | Transactions | Gas per transaction (illustrative) | Total gas at 20 Gwei |
|---|---|---|---|
| One transfer per recipient (1,000 wallets) | 1,000 | 65,000 | 1.30 USDC |
| Batched, 200 recipients per call | 5 | ~2,400,000 | 0.24 USDC |
The per-transfer approach also costs you 1,000 nonce increments and 1,000 chances to fat-finger an amount. The batching advantage on Arc is smaller than on a chain where a single transfer costs dollars — which is a good problem to have — but the operational simplification is the real prize.
Two honest caveats. First, larger batches consume more gas per transaction and can hit block gas limits, so "fewer, bigger batches" stops being optimal at some size; the tool chunks automatically for that reason. Second, the gas numbers above are illustrative metering, not a quote — check Arc's gas and fees reference and estimate against your real batch size.
Step 1 — Build the recipient list
You have three sources for a list:
- An existing token. Run Arc Token Snapshot against your token, pick the block, and export. The tool replays every
Transferevent from deployment to that block, so fee-on-transfer balances come out as the amounts holders actually received, not the amounts that were originally sent. - An offchain list. Wallet addresses collected from a waitlist, a Discord role, a points program. Upload it as a two-column CSV.
- A hybrid. Snapshot an old token's holders as the eligibility basis for a new one — the classic migration airdrop.
Whichever route you take, the snapshot is the step that determines whether the airdrop is fair, and it has its own guide: how Arc token snapshots work.
The anti-farming trick most teams miss
A snapshot can be taken at any block, including a block in the past. If you decide the eligibility block before announcing the program, nobody can farm it, because the window closed before they knew it existed. Announcing "snapshot at block 6,412,900" in advance buys you sybil wallets; announcing the criteria and the block one minute before the send does not.
Combine that with a minimum-holding threshold and a pool-address exclusion, and you filter out most of the noise without any offchain analysis.
Step 2 — Choose how much each wallet gets
Two formats are supported:
Flat amount. Every recipient receives the same number. Simple, cheap to explain, and it makes the total easy to compute: recipients × amount.
Per-row amounts. Each CSV row carries its own figure. This is what you want for tiered programs — for example, a points-based distribution where a wallet's share is proportional to a score. The tool validates every row before submission, so malformed amounts are flagged in the browser rather than failing onchain.
A quick reality check on scale: airdropping 10,000,000 tokens to 2,000 wallets is 5,000 tokens each. If 2,000 wallets each receive more than 0.5% of supply, your distribution is technically fine but your token will have a very large number of sellers at the same price. Size the amounts against your tokenomics plan, not against how generous the announcement sounds.
Step 3 — Approve, then send
For an ERC-20 airdrop this is an approve-then-send flow:
- Approve. The tool requests an allowance of exactly the total you are sending, to the multisender contract. Nothing more.
- Send. Recipients are chunked into batches. Each batch is one transaction, each settles in under a second, and each reports its own hash and status.
- Revoke (optional). The tool can revoke the remaining allowance in a follow-up transaction.
Native USDC payouts skip the approval entirely — you are distributing the 18-decimal native balance directly. That distinction trips people up, so it is worth reading the USDC gas token explainer before you airdrop native USDC: a payout of "1 USDC" is written as 1000000000000000000 on the native side and 1000000 through the ERC-20 interface, and getting it backwards is an expensive typo.
If a batch reverts, the tokens stay in your wallet and previously settled batches are untouched. Nothing is lost, but you will want to find out why before retrying — see the mistakes section below.
Direct send vs claim-based airdrop
A multisender pushes tokens out. A claim-based distributor (usually a Merkle tree) publishes a root and lets each recipient claim.
| Direct batch send | Claim-based (Merkle) | |
|---|---|---|
| Who pays gas per recipient | You, once per batch | Each recipient, on their own claim |
| When recipients get tokens | Immediately | Whenever they claim |
| Unclaimed allocation | Never exists — you sent everything | Stays in the distributor, or expires |
| Recipient experience | Tokens appear in the wallet | Requires a claim transaction and a working wallet |
| Best for | Small and mid-size programs, community payouts, native USDC | Very large programs where unclaimed supply should revert to the treasury |
The honest trade-off: on a chain where a transfer costs a fraction of a cent, the cost saving of a claim-based model mostly evaporates, and you inherit a support burden of people who never claimed. On Arc, a direct send is usually the right default, and unclaimed allocation is simply a non-issue because you choose to send it.
Airdrop mistakes that cost real tokens
- Sending to the token's own pair address. Tokens sent to a Uniswap V2 pair are, in effect, donated to liquidity providers. Filter pools out of the list — the snapshot tool marks them.
- Sending to contracts that cannot receive. A contract with no transfer handling will take the ERC-20 and hold it forever.
- Sending to exchange deposit addresses. Many will not credit an arbitrary ERC-20 that is not listed, and recovering it may be impossible.
- Mixed decimal assumptions. Native USDC is 18 decimals, the ERC-20 is 6. Always confirm which one your payout uses.
- Airdropping the whole float at once. If 40% of supply lands in 3,000 wallets on the same day, expect those wallets to sell into each other. Vesting part of the allocation, or staggering sends, changes that dynamic.
- Not telling anyone what they received. An airdrop nobody can explain produces confusion and panic selling, not loyalty.
Before you press send
Confirm the recipient count and the total, confirm the block your snapshot used, and dry-run the first batch with a handful of addresses if you are unsure. Then check the whole plan against the Arc Mainnet launch checklist — an airdrop that arrives before your pool is deep enough to absorb the selling is a self-inflicted wound. If you have not launched the token yet, start with creating it on Arc.
Arctools charges a flat 50 USDC for multisender runs, snapshots and the token checker are free, and no tool takes a percentage of your token. Arctools is not affiliated with Circle or the Arc Foundation.