How to Airdrop Tokens on Arc with a Multisender

An airdrop is two problems wearing one hat: deciding who deserves tokens, which is a data problem, and paying them, which is a cost problem. One transfer per recipient pays a full transaction overhead each time.

Arctools splits them. Arc Token Snapshot builds the list for free by replaying a token's transfer history to the block you choose. Arc Token Multisender does the paying, batching recipients so the per-transaction overhead is paid a handful of times instead of once per wallet.

Before you start

• The token you are distributing, and enough of it. ERC-20 airdrops are supported directly, and native USDC payouts work too. ERC-721 and ERC-1155 transfers need a per-token-id mint, so they are not a fungible multisender job.
• A wallet on Arc Mainnet. Chain id 5042, RPC https://rpc.mainnet.arc.io, explorer https://explorer.arc.io. The 50 USDC service fee and the gas both come from the same USDC balance.
• A defensible eligibility rule. "Everyone who held at block 12,345,678, above 1,000 tokens, excluding pools and the deployer" is defensible. "Everyone in the export" is not.
• A budget that includes gas. The service fee is flat regardless of recipient count, so gas is the only cost that scales.

The snapshot step is free and needs no wallet at all: you can audit an Arc token, build a holder list and check concentration without owning a single unit of it.

1. Take a snapshot at the block that defines eligibility

Open the snapshot tool, paste the token address and pick the block. The tool replays every Transfer event from deployment to that block and reconstructs each address's balance, which makes the result reproducible: anyone can run the same query at the same block and get the same numbers.

The tool also reports holder count, top-10 and top-100 concentration, and the share held by the deployer and by pools. Read those before you decide anything, because they usually change the plan.

Choose the snapshot block for a reason and write the reason down:

• Before an announcement, so nobody can farm eligibility after reading the tweet.
• After a distribution event, if the airdrop recognises people who held through a specific period.

Because Arc blocks finalise deterministically in under a second, the block you snap at is settled almost instantly. There is no reorganisation to wait out.

2. Filter the list before you spend anything

The export is a complete ledger of balances, which is not the same thing as a list of people. Airdropping the raw export sends a large share of your tokens to addresses that cannot use them:

• Liquidity pools. The pair holds a large token balance by design, so sending it tokens is equivalent to donating them to the pool.
• The deployer wallet. Your own wallet is not usually a recipient, and excluding it removes the most obvious criticism of the drop.
• Contract addresses. Staking, vesting and locker contracts hold balances, and unless the contract knows how to distribute what it receives the tokens are stranded.
• Burn and zero addresses, which inflate the cost of the drop for nobody's benefit.
• Dust balances. A minimum holding threshold removes wallets that exist only to farm airdrops, and it can cut the recipient count dramatically for very little loss of goodwill.

Every exclusion you make is a decision you will be asked about later, so list them explicitly. The honest publishable form is: "snapshot at block N, minimum 1,000 tokens, pools, deployer and known contracts excluded."

3. Check concentration and size the drop

Before sizing the allocation, look at what the drop is actually buying you. Concentration tells you how much of the supply the airdrop will hand back to large holders, and combined with your distribution plan it tells you the real message the drop sends.

Practical sizing questions:

• Is the drop proportional or flat? Proportional rewards existing size, so your largest holders receive the most. Flat amounts reach more wallets and broaden distribution. Either is legitimate; they signal different things.
• Is the supply you are distributing already accounted for? Tokens set aside at launch should sit in a wallet you control, excluded from circulating-supply claims.
• Does anything left over need destroying? Unsold or unclaimed allocation is usually burned rather than returned to the treasury — the token burn tool destroys supply properly and shows the new total supply before you sign.

Airdrops are also where people reach for randomness. PREVRANDAO returns 0 on Arc, so there is no usable onchain randomness: draw lottery winners offchain from the snapshot and publish the list, rather than building a contract that pretends to be random.

4. Upload the CSV and validate every row

Export the filtered list and upload it to the multisender. The export is a two-column address, amount CSV, which is exactly what the form expects; you can also paste rows straight in.

Validation happens in the browser, before anything is signed:

• Every address is checksum-checked. Mixed-case addresses must pass their EIP-55 checksum, so a flagged row is usually a casing problem — re-export it in lowercase if you are not sure.
• Every amount is parsed against the token's decimals. A row with too many decimal places is rejected rather than silently rounded.
• Duplicate addresses are visible, so you can decide whether the same wallet twice is intentional.

Nothing is spent on a row that cannot succeed. Compare the validated total against the allocation you intended before you move on; a decimal-place slip in a spreadsheet is the single most common airdrop error, and it is much cheaper to catch here.

5. Approve the token for exactly the total

An ERC-20 contract cannot move your tokens unless you allow it, so every ERC-20 airdrop is approve-then-send. The tool requests an allowance for exactly the total you are sending rather than an unlimited one, which caps what a future contract bug could ever move.

Two things worth doing before you approve:

• Exempt the multisender in the token's settings. If your token charges a transfer tax, burns on transfer or enforces a maximum wallet limit, a batch can under-deliver or revert. The Arc Token Manager can exempt the multisender contract, and it is the right place to do that before the drop rather than after a failed batch.
• Confirm the wallet holds more than the naive total. With burn-on-transfer, the contract must send enough that every recipient still receives their row amount.

6. Send the batches and watch them settle

Recipients are chunked into batches and each batch is its own transaction with its own status and hash. That structure is deliberate:

• Failures are contained. If one batch reverts, its tokens stay in your wallet and settled batches are unaffected — a monolithic transaction would fail as a whole.
• Gas estimation stays sane. Very large airdrops are simply more batches; lists of several thousand addresses are routine.
• Progress is visible. Because Arc finalises in under a second, each batch goes from submitted to final almost immediately and you can watch the recipient count climb.

One practical warning if you are scripting the airdrop yourself instead of using the tool: Arc's mempool rejects blob transactions (type 3). L2-oriented tooling that batches calldata into blobs will fail outright. Use ordinary transactions.

7. Publish the proof and clean up

The airdrop is only as credible as the record you leave behind. Publish the snapshot block, the eligibility rule, the exclusion list, the validated CSV and the batch transaction hashes. Anyone can then reproduce the list and verify the payments on https://explorer.arc.io without trusting your summary.

Then tidy up:

• Revoke the outstanding allowance in a follow-up transaction, checking the fee notice shown in the tool before you sign.
• Burn unallocated supply if the airdrop left tokens in the treasury that were reserved for distribution. A burn reduces total supply for real; sending tokens to a dead address does not.

What it costs

Item	Amount	Notes
Snapshot	Free	Read-only, no wallet needed
Multisender service fee	50 USDC flat	Same price for 10 recipients or 10,000
Gas	Scales with recipients	Paid in USDC, at the 20 Gwei floor
Tokens distributed	Your allocation	Your own supply
Allowance revoke	Gas only	Optional cleanup transaction

Gas arithmetic you can reproduce. Arc's floor is 20 Gwei, or 0.00000002 USDC per gas unit, so 100,000 gas costs 0.002 USDC. A plain ERC-20 transfer typically consumes on the order of 50,000 gas; taxed or burning transfers cost more:

• 100 recipients at 50,000 gas each is about 5,000,000 gas, roughly 0.10 USDC.
• 500 recipients is about 25,000,000 gas, roughly 0.50 USDC.
• 2,000 recipients is about 100,000,000 gas, roughly 2.00 USDC.

Treat those as order-of-magnitude estimates built from the fee floor, not quotations: the actual total depends on your token's transfer logic, how full each batch is, and the gas price at the moment you send. What is not an estimate is the shape of the cost — 50 USDC flat, plus a couple of USDC of gas for thousands of wallets. Compare that with sending one transfer at a time, paying the per-transaction overhead and signing thousands of confirmations.

Common mistakes

• Airdropping to the pool. The raw export includes the Uniswap pair, which holds a large balance. Filter it out or you are handing tokens to buyers.
• Choosing the block after the fact. Eligibility decided during list assembly is not eligibility. Publish the block first.
• Using onchain randomness. PREVRANDAO returns 0 on Arc, so any "random" selection is deterministic. Draw winners offchain and publish the method.
• Forgetting taxes and limits. A taxed or max-wallet-limited token can reject or under-deliver batches. Exempt the multisender first.
• Approving an unlimited allowance. Approve the exact total; it costs nothing extra and removes an open-ended risk.
• One giant batch. Big single transactions fail as a unit and are harder to gas-estimate. Batches exist to make failure cheap.
• Sending airdrop tokens to an exchange deposit address. Unless the exchange supports Arc assets and that specific token, the funds are unlikely to be credited.
• Airing an unverifiable claim. "We airdropped to holders" means nothing without the block, the rule and the hashes.

Where to go next

Once the tokens are in holders' hands, the questions shift from distribution to credibility: make your Arc token safe takes you through the checker, the ownership renounce and the liquidity lock that turn a distribution into a track record. If the drop revealed settings you want to change — a tax that should be lower, a limit that should be gone — the token management guide covers every parameter you can still adjust, and which ones disappear forever when you renounce.