Arc Token Snapshot Guide: Holders at Any Block, Exported to CSV
An Arc token snapshot freezes holder balances at a block you choose and exports a CSV. Here is how snapshots work, what they cost and where they go wrong.
An Arc token snapshot reconstructs every holder's balance at a specific Arc block by replaying the token's Transfer events from deployment up to that block, then exporting the result as a CSV. It is free in the Arctools Arc Token Snapshot tool, needs no wallet connection, and produces a file that uploads straight into an airdrop.
Snapshots are the least glamorous and most consequential part of a distribution: they decide who counts, and getting the block or the exclusions wrong is how airdrops become disputes.
How an Arc token snapshot is calculated
An ERC-20 does not store a list of holders. It stores a balance per address and emits an event on every movement. To know who held what at block N, you have to walk history:
- Find the token's deployment block.
- Read every
Transferevent from that block to N. - Apply them in order: subtract from the sender, add to the recipient. Mint events add to supply; burn events remove it.
- Read the current balances as a cross-check, and treat any address that cannot go negative as a real balance.
This is exactly how indexers and block explorers do it. The difference is that you can verify the output: each step can be reproduced from public events on the Arc Explorer, and the tool reports the concentration metrics alongside the list.
Why Arc makes this unusually easy
Two properties of Arc Mainnet matter here.
Deterministic sub-second finality. One confirmation is final. On a chain with a reorg window you have to snapshot a block that is already several confirmations deep, or accept that a late reorg can change the holder set after you exported it. On Arc, the block you choose is the block; there is nothing to wait for.
No blob transactions and a simple fee market. Type-3 transactions are rejected on Arc, and every transaction must meet the 20 Gwei maxFeePerGas floor, which means the blocks you replay contain only conventional transactions. Fewer exotic transaction types means fewer edge cases in event decoding.
Choosing the snapshot block
The block is the whole decision, because it defines eligibility. Three practical patterns:
| Pattern | Block | Why |
|---|---|---|
| Retroactive | A block from before you announced anything | Prevents farming; nobody could have positioned for criteria they had not seen |
| Announced | A specific future block, published in advance | Fair and transparent, but expect new wallets to appear between announcement and block |
| Activity-based | A block after a period of use (trading, holding, staking) | Rewards real usage; requires a rule for what counts as activity |
A retroactive snapshot is the strongest anti-sybil measure available to you for free: you can announce the airdrop after taking it. The trade-off is that anyone who bought and sold during the window is treated as a holder or a non-holder based on their balance at one instant, which can feel arbitrary if you do not explain the rule.
If you must announce in advance, publish the block number, the eligibility rule and the exclusions at the same time. Ambiguity in an announced airdrop is a sybil subsidy.
Reading the concentration metrics
The exported list is more than a payout schedule; it is a map of who owns your token.
- Top-10 share. Above roughly 40–50% concentrated in ten addresses, the token has a serious overhang problem, especially if those addresses include team and deployer wallets.
- Deployer share. Any wallet that still holds more than a few percent from launch should have a stated and verifiable plan — a lock, a vesting contract, or a burn.
- Pool share. The Uniswap pair holding your token is not a "holder" in the human sense; its balance is the pool's inventory. Exclude it from any payout, but watch it: a pool holding 20% of supply with thin USDC reserves means every meaningful sell moves the price hard.
- Holder count relative to distribution. 2,000 holders where the top 20 hold 70% is a much thinner market than 2,000 holders where the top 20 hold 25%.
These numbers are also the fastest way to sanity-check someone else's token before buying it — the same data feeds the analysis in how to avoid rug pulls on Arc.
Cleaning the list before you use it
A raw snapshot is a starting point, not an airdrop list. Filter it:
- Remove Uniswap pairs and LP-relevant contracts. Tokens sent to a pair are donated to liquidity providers.
- Remove the locker, factory and tooling contracts you used yourself.
- Remove zero balances. They are noise, and they inflate your recipient count.
- Apply a dust threshold. A payout worth less than the gas to claim it is not a gift; on Arc gas is tiny, so even small thresholds are more about presentation than cost.
- Flag known exchange and bridge addresses if you want to avoid sending into custody you cannot control.
- Check the deployer and team wallets separately, and decide explicitly whether they are included. Silence here is read as hiding.
The result — a two-column CSV of address and amount — is the input format expected by the Arc Token Multisender, so the snapshot-to-airdrop path never requires a spreadsheet round trip unless you want one.
Snapshot use cases beyond airdrops
- Governance. A snapshot defines voting power at a block, which is what makes a vote resistant to last-minute borrowing. Note that onchain vote checkpoints (the ERC-20
getPastVotespattern, as used by delegation-based systems) serve a similar purpose inside the contract; a snapshot is what you use when the vote happens offchain. - Revenue share. Distributing trading fees or protocol revenue in proportion to holdings at a block requires exactly this data.
- Points and loyalty programs. Snapshotting weekly or monthly builds a usage history and lets you weight recent holders more heavily.
- Holder analytics. Tracking concentration over time is one of the few genuine quality signals a token has, and it is measurable rather than asserted.
Where snapshots go wrong
Taking the snapshot before the token was transferable. If trading had not been enabled — or the pool did not exist — at the block you picked, every eligible holder is whoever received tokens from the deployer, which is usually not what you meant.
Snapshotted the old token, airdropped the new one, no explanation. Migration airdrops need a clear "what happened and why" post. Otherwise the recipients assume a random token appeared in their wallet and ignore it.
Ignoring reflections and rebasing mechanics. For a standard ERC-20, replaying Transfer events gives the true balance. For a token with reflection or rebasing logic, the balance implies a claim on a growing pool rather than a fixed number of tokens; exporting a CSV at a block captures the balance at that moment, but the value of that balance may keep changing. If you are distributing a rebasing token, say so in the announcement.
Assuming unpaid balances stay. An airdrop recipient who never claims — in a claim-based design — is a wallet that never engaged. With a direct batch send there is nothing to claim, which is one of the reasons it is the default approach on Arc; see how to run an Arc airdrop.
Reusing an old snapshot for a new purpose. A list taken for a governance vote eight months ago reflects a different token, a different price and probably a different holder set. Take a new snapshot.
Running one
Open Arc Token Snapshot, paste the token address, choose the block, and export. The tool shows the reconstructed supply, the holder count and the concentration metrics before you download anything, so you can sanity-check the block by checking that the supply matches the token's total supply at that point.
Snapshots are free. The paid step is the send, and you should plan the two together — a snapshot taken before your pool is deep enough to absorb the payout creates price damage that no amount of good distribution design fixes. If you are still at the planning stage, the Arc Mainnet launch checklist puts the ordering in one page.