Snapshot

What Is a Snapshot?

A snapshot is a point-in-time record of a blockchain's state at a specific block height. It captures who holds what: every account balance, every token holding, every contract's internal storage, and the full validator set. On UTXO-based chains like Bitcoin, a snapshot records the complete set of unspent transaction outputs at that block.

Think of a snapshot as a photograph of the entire ledger at one precise moment. Transactions before that block are included; transactions after it are not. This makes snapshots useful whenever you need a definitive answer to "who held what, and how much, at a given time?"

The term is used in two related but distinct contexts. In the narrower sense, a snapshot refers to recording token balances for a specific purpose like an airdrop or governance vote. In the broader sense, it refers to a full dump of chain state used for node synchronization or chain forks.

How It Works

Taking a snapshot means indexing all relevant state at a target block height. The technical approach depends on the chain architecture and the snapshot's purpose.

Off-Chain Indexing

The most common method for token-balance snapshots is off-chain indexing. An archive node stores the full historical state at every block height. Developers query the node's RPC endpoints to enumerate all holders and their balances at the target block:

// Query ERC-20 balance at a specific block height
const balance = await tokenContract.balanceOf(
  walletAddress,
  { blockTag: snapshotBlock }
);

// Or iterate all Transfer events to reconstruct balances
const transfers = await tokenContract.queryFilter(
  tokenContract.filters.Transfer(),
  0,
  snapshotBlock
);

Subgraph indexers like The Graph process all Transfer events from a contract's deployment through the target block, reconstructing a complete balance map. Dedicated tools automate this process and output results as JSON or CSV files mapping addresses to balances.

On-Chain Snapshot Mechanisms

Some token contracts include built-in snapshot capabilities. OpenZeppelin's ERC20Snapshot extension (available in Contracts v3.x and v4.x) maintained on-chain balance checkpoints. Each call to _snapshot() incremented an internal counter and recorded balances, enabling queries like balanceOfAt(address, snapshotId) directly on-chain.

OpenZeppelin removed ERC20Snapshot in v5.0, replacing it with ERC20Votes: a more gas-efficient checkpoint mechanism that also supports vote delegation. This exposes getPastVotes(address, blockNumber) and getPastTotalSupply(blockNumber) for historical balance queries.

Full State Dumps

For node bootstrapping and chain forks, a full state dump captures the entire blockchain state: not just token balances but all account data, contract storage, and consensus information. Ethereum clients like Geth can export the state trie at a specific block. Bitcoin Core's dumptxoutset RPC command creates a serialized copy of the UTXO set at a given height.

Use Cases

Airdrop Eligibility

The most visible use of snapshots is determining who qualifies for token airdrops. A project selects a block height, records all addresses meeting certain criteria (holding a minimum balance, having interacted with a protocol, or staking tokens), and distributes new tokens proportionally.

Recent large-scale examples illustrate the pattern. Starknet took a snapshot in November 2023 and distributed 728 million STRK tokens to approximately 1.3 million wallets in February 2024. ZKsync snapshotted on March 24, 2024 (the one-year anniversary of its mainnet launch) and distributed 3.675 billion ZK tokens to 695,232 wallets, using a time-weighted formula based on how long assets had been bridged to the network.

Governance Voting

Snapshot.org is a decentralized off-chain governance platform used by over 35,000 DAOs and token communities across 52 blockchain networks. When a proposal is created, the platform records the current block as the "snapshot block." Voting power is calculated based on governance token balances at that block.

Voters sign an EIP-712 typed-data message with their wallet containing the proposal ID, their chosen option, and a timestamp. No on-chain transaction is submitted, so voting costs zero gas. Signed votes are stored on IPFS. Because voting power is locked at the snapshot block, buying tokens after proposal creation does not increase voting power, and selling does not reduce it.

Snapshot.org supports over 400 voting strategies, including ERC-20 balance weighting, ERC-721 NFT ownership, delegated votes, and whitelist-based eligibility.

Chain Forks

When a blockchain undergoes a hard fork, the new chain starts from a snapshot of the old chain's state at the fork block. Every address holding tokens on the original chain receives the same balance on the new chain. Bitcoin Cash forked from Bitcoin on August 1, 2017, at block height 478,558: every BTC holder at that block received an equal amount of BCH.

Node Bootstrapping

New nodes can use state snapshots to sync quickly instead of replaying every transaction from the genesis block. Bitcoin Core's AssumeUTXO feature hardcodes a UTXO set hash at a specific block height into the source code. A new node loads a snapshot matching that hash, immediately begins serving recent transactions, and validates the full chain history in the background. Research has shown this approach reduces data download by over 99% compared to standard sync.

Ethereum's snap sync protocol achieves approximately 10x faster initial sync by downloading account and storage data directly (the trie leaves) with range proofs, then reconstructing the Merkle tree locally rather than downloading intermediate nodes.

Snapshot Gaming and Countermeasures

When snapshot dates are announced in advance, a predictable pattern emerges: traders buy tokens before the snapshot block to qualify for an airdrop or inflate governance voting power, then sell immediately after. This is closely related to airdrop farming, where users create multiple wallets and perform minimum qualifying activity across each.

Projects have developed several countermeasures:

• Unannounced snapshots: the snapshot block is chosen before the airdrop is publicly announced, preventing front-running. Most major airdrops in 2024 and 2025 used retroactive snapshots.
• Time-weighted averaging: instead of a single block, projects measure average balances over weeks or months. ZKsync weighted addresses more heavily if assets had been held on the network since mainnet launch rather than deposited shortly before the snapshot.
• Points-based systems: Hyperliquid accumulated points over months of testnet and mainnet activity before distributing 310 million HYPE tokens to approximately 94,000 wallets in November 2024. Last-minute gaming was impractical.
• Sybil detection: on-chain forensic analysis identifies coordinated wallet clusters using funding source matching and transaction pattern analysis. Hyperliquid removed approximately 12,000 wallets flagged as Sybil accounts.
• Self-reporting mechanisms: LayerZero allowed users to self-identify as Sybils for a guaranteed 15% allocation, with remaining funds redistributed to legitimate users.

Risks and Considerations

Snapshot Manipulation

Even with countermeasures, snapshots remain gameable. Flash loans can temporarily inflate a wallet's balance within a single block, though most snapshot mechanisms now account for this by requiring balances to persist across multiple blocks. Large holders can also split their holdings across many wallets before a snapshot to maximize per-address airdrop caps.

Privacy Implications

Snapshot data creates a detailed map of who holds what at a specific moment. When published (as airdrop eligibility lists often are), this data enables chain analysis and address clustering. Addresses linked through common snapshot eligibility may reveal connections between wallets that owners intended to keep separate.

State Size and Storage

Full state snapshots grow with the blockchain. Ethereum's state trie contains hundreds of millions of accounts and storage slots. Storing and distributing these snapshots requires significant infrastructure. State bloat is an ongoing concern for chains that rely on snapshots for node syncing, as larger state means larger snapshots and longer processing times.

Trust Assumptions

When a node syncs from a snapshot rather than validating from genesis, it initially trusts that the snapshot is correct. Bitcoin's AssumeUTXO mitigates this by validating the full history in the background after loading the snapshot. Not all snapshot-based sync mechanisms include this background validation, which means nodes may operate on unverified state until they independently confirm it.

Why It Matters

Snapshots sit at the intersection of several critical blockchain functions: fair token distribution, decentralized governance, network scalability, and chain upgrades. For users, understanding snapshots means knowing how airdrop eligibility works and why holding tokens in self-custody (rather than on an exchange) matters at snapshot time: exchanges may or may not pass through airdropped tokens to users.

For developers building on platforms like Spark, snapshots are relevant when designing token distribution mechanisms or integrating with governance systems. Layer 2 networks and off-chain protocols need their own snapshot strategies to capture state that lives outside the base layer. As token distributions have grown in scale (over $4 billion in airdrops in the first half of 2024 alone), the mechanics of fair and manipulation-resistant snapshots continue to evolve.

For a deeper look at how airdrops and token distribution interact with broader market dynamics, see the research on institutional adoption patterns and the on-chain usage metrics that snapshot data helps produce.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.