NFT Snapshot

An NFT snapshot captures the exact state of a collection at a specific block height on the blockchain. This record includes:

• Wallet addresses of all holders.
• The specific token IDs each wallet owns.
• Associated metadata (e.g., traits, rarity) for each token.

Once recorded, this data is cryptographically verifiable and cannot be altered, providing a reliable historical ledger for distribution or analysis.

The most common application is to distribute new tokens or rewards to a specific historical holder set. For example:

• A project may airdrop a new ERC-20 token to all holders of its genesis NFT collection.
• A gaming DAO could distribute in-game assets to holders of a particular character class.

This allows for permissionless, verifiable distribution based on proven past ownership, rewarding early supporters or specific community segments.

Snapshots are foundational for snapshot voting, a popular off-chain governance mechanism. A snapshot of token holders is taken to determine voting eligibility and weight for a proposal.

Key aspects include:

• Prevents vote buying by locking the eligible voter set.
• Allows voting via signed messages without gas fees.
• Ensures only historical holders can participate, protecting against last-minute token accumulation.

A snapshot is not a native blockchain function but is created by querying and recording on-chain data. Common methods include:

• Using an indexer or subgraph (e.g., The Graph) to query ownership at a target block.
• Running a custom script via a node provider (e.g., Alchemy, Infura) to call the balanceOf and tokenOfOwnerByIndex functions of the NFT contract.
• The resulting data is typically stored in a Merkle tree for efficient, verifiable proof of inclusion in an airdrop.

To efficiently and verifiably distribute assets from a snapshot, projects often use a Merkle tree. This cryptographic structure:

• Compresses the entire snapshot holder list into a single Merkle root stored on-chain.
• Allows each eligible user to submit a concise Merkle proof to claim their tokens.
• Is highly gas-efficient, as only the root hash needs to be published, not the entire list of addresses.

Platforms like OpenZeppelin's MerkleDistributor provide standard implementations for this pattern.

Beyond distributions, snapshots serve as critical datasets for on-chain analytics. Analysts use them to:

• Track holder concentration and whale movements over time.
• Analyze the correlation between specific NFT traits and holder behavior.
• Measure retention rates and community growth between snapshot events.

This data provides insights into collection health, market trends, and community dynamics that are not visible from current-state data alone.

The block height (or block number) is the most critical parameter. It defines the exact moment the snapshot is taken. Developers must consider block finality to ensure the recorded state is irreversible. On proof-of-work chains, waiting for multiple confirmations is standard. On proof-of-stake chains, finality is often faster, but the specific epoch or slot must be chosen carefully to avoid reorganizations.

Snapshots rely on querying a blockchain node's state. The choice of node provider is crucial.

• Archival vs. Full Nodes: An archival node is required to query historical state (e.g., ownership at block #15,000,000). A standard full node may only have recent data.
• Provider Reliability: Using a single centralized provider like Infura or Alchemy introduces a point of failure. Best practice involves cross-referencing multiple nodes or running a self-hosted archival node for critical operations.

Not all NFT ownership is straightforward. The snapshot logic must account for:

• ERC-721 vs. ERC-1155: ERC-1155 can represent multiple token IDs in a single contract, requiring different query logic.
• Nested Assets (Staked NFTs): NFTs locked in a staking contract or used as collateral in a lending protocol are technically owned by the smart contract, not the end user. Special logic is needed to map the ultimate beneficiary.
• Delegate.cash & Token-Bound Accounts: Protocols that allow delegation of asset control without transferring ownership must be considered for governance snapshots.

For large airdrops, storing a full list of addresses is inefficient. The standard solution is to generate a Merkle tree (or Merkle root) from the snapshot data.

• Off-Chain Generation: The tree is constructed off-chain from the snapshot data.
• On-Chain Verification: Users submit a Merkle proof—a cryptographic path proving their inclusion in the snapshot—to claim their allocation. This method minimizes on-chain storage and gas costs for distribution.

The act of taking a snapshot itself is gas-free (it's a read operation), but subsequent actions have costs.

• Airdrop Execution: Distributing tokens based on the snapshot requires a transaction for each recipient or a clever use of Merkle claims, which shifts gas costs to the user.
• Timing Attacks: Snapshot timing can be gamed. "Snapshot squatting," where users buy assets just before a known snapshot and sell immediately after, is common. Projects often use randomized or surprise snapshot blocks to mitigate this.

Common Tools:

• The Graph: Indexes historical blockchain data into queryable subgraphs.
• Dune Analytics: SQL-based platform for querying and analyzing on-chain data, useful for verifying snapshots.
• Custom Scripts: Many teams write scripts using web3.js or ethers.js to query an archival node.

Pitfalls to Avoid:

• Ignoring token approvals and delegated balances.
• Using a non-archival node and getting empty results.
• Not accounting for the snapshot block's transaction ordering (state after the block, not before).

A distribution of tokens or assets to a predefined list of wallet addresses, often determined by an NFT snapshot. Key uses include:

• Community rewards for early supporters or holders of a specific collection.
• Governance token distribution to decentralize project ownership.
• Marketing campaigns to drive engagement and liquidity. The integrity of the airdrop relies entirely on the accuracy and immutability of the underlying snapshot data.

A cryptographic data structure used to efficiently and securely verify inclusion in a snapshot without storing the entire list on-chain.

• Merkle Root: A single hash representing all addresses in the snapshot, stored in a smart contract.
• Merkle Proof: A small set of hashes a user provides to prove their address was part of the original dataset. This method minimizes gas costs and on-chain storage while maintaining verifiable integrity for claims like airdrops or allowlists.

A permissioned list of addresses granted exclusive access, commonly derived from an NFT snapshot. Applications include:

• Mint phases for NFT projects, where only snapshot-verified holders can mint.
• Token-gated access to websites, Discord channels, or real-world events.
• Early access to product features or sales. The list is typically implemented via a Merkle tree or stored in the minting contract's state.

Defines where the snapshot data is stored and verified.

• On-Chain Snapshot: Ownership data is queried directly from the blockchain (e.g., via a smart contract call) at a specific block height. Highly transparent and verifiable but can be gas-intensive.
• Off-Chain Snapshot: Data is collected by indexing nodes or subgraphs (e.g., using The Graph) and stored in a centralized database or IPFS. More flexible for complex queries but requires trust in the data provider's integrity.

The specific point in the blockchain's history when a snapshot is taken. This is a critical parameter because:

• It creates an immutable, timestamped record of ownership at that exact moment.
• Prevents users from buying/selling assets after the snapshot to qualify.
• Serves as the definitive reference for all subsequent calculations and verifications (e.g., 'Snapshot taken at block #15,840,267').

The process of cryptographically proving ownership of an NFT from a snapshot, often required to claim an airdrop or access gated content. Common methods include:

• Signature Verification (Signing): The user cryptographically signs a message with their wallet to prove control.
• Merkle Proof Submission: Providing a proof to a smart contract.
• Live Balance Check: The contract checks the caller's current balance, though this is vulnerable to post-snapshot transfers.