Snapshot

A snapshot is a point-in-time capture of the entire ledger state, recorded at a precise block height. It freezes data such as token balances, NFT ownership, and staking positions. This creates an immutable, verifiable record for off-chain processes without interrupting the live chain.

• Key Data Captured: Native token balances, ERC-20/ERC-721 holdings, delegated voting power, and staking positions.
• Verification: The data is cryptographically tied to the block hash, ensuring its integrity and preventing manipulation after the fact.

The most common application is for off-chain governance. Platforms like Snapshot.org use snapshots to determine voting power for DAO proposals. A user's voting weight is calculated based on their token balance at the recorded block, allowing for gas-free voting.

• Mechanism: Voting occurs on a separate interface; only the snapshot data and subsequent votes are stored off-chain (often on IPFS).
• Example: A DAO takes a snapshot at block #15,000,000. A member's vote power is determined by how many governance tokens they held in their wallet at that exact block, not at the time of voting.

Snapshots are essential for planning and executing fair token airdrops and distributions. Projects capture a snapshot of an existing community (e.g., Ethereum holders, early users) to create a merkle tree for claim eligibility.

• Process: 1. Announce snapshot block height. 2. Capture balances. 3. Generate a merkle root from the data. 4. Deploy a claim contract that verifies proofs against this root.
• Purpose: Rewards past users, decentralizes token ownership, and bootstraps a new network (e.g., Uniswap's UNI airdrop to historical users).

During a hard fork or major protocol upgrade, a snapshot of the pre-fork state is often used to bootstrap the new chain. This ensures all user balances and contract states are preserved identically on the new network.

• Fork Initiation: The new chain begins by loading the snapshot data as its genesis state.
• Examples: The Ethereum Classic fork from Ethereum, or the creation of a new Layer 2 rollup which may snapshot balances from Layer 1 at the time of its launch.

A critical distinction is where the snapshot data and subsequent actions are stored and executed.

• Off-Chain Snapshot (Common): The state data is recorded and stored off-chain (e.g., on IPFS). Actions based on it, like voting, are also off-chain. This is cheap and fast but requires trust in the snapshot's integrity.
• On-Chain Snapshot (Less Common): The state data is written to and verified by the blockchain itself, often via a smart contract. This is more secure and trustless but incurs gas costs. It's used for critical functions like on-chain merkle drops.

The security of processes relying on a snapshot depends on its immutability and accurate capture.

• Trusted Source: Participants must trust the entity taking the snapshot (e.g., a DAO's multisig) to have captured the data correctly and not manipulated it.
• Verification: The snapshot's block hash should be widely published and verifiable by anyone running a node. Any user can independently replay the chain to confirm the recorded state.
• Rug Pull Risk: Malicious actors could take a snapshot, distribute tokens based on it, and then drain the treasury before the snapshot is used, making the awarded tokens worthless.

Snapshot executes votes off-chain to eliminate gas fees. Voters sign a message with their wallet to cast a vote, which is stored on IPFS. The platform uses Merkle proofs to verify that the signer's token holdings (e.g., ERC-20, ERC-721) were valid at a specific block height (the snapshot block). This creates a verifiable, tamper-resistant record without on-chain execution costs.

A voting strategy is a plugin that defines how voting power is calculated for a proposal. Common strategies include:

• Token-based: Power is proportional to the balance of a specific ERC-20 token (e.g., UNI, AAVE) held at the snapshot block.
• Multi-strategy: Combines power from multiple tokens or NFTs.
• Delegation: Respects token delegation systems like Compound's or ERC-20Votes. Strategies query on-chain data to compute each voter's power, enabling flexible governance models beyond simple token holdings.

A Space is a dedicated hub for a DAO or project's governance. An admin configures its settings:

• Voting strategies and symbol.
• Voting types (single choice, weighted, quadratic).
• Validation rules and proposal thresholds. The lifecycle of a proposal involves:

1. Creation: A member submits a proposal to the Space.
2. Voting Period: Members cast off-chain signatures.
3. Execution: Results are finalized on IPFS; on-chain execution often requires a separate, permissioned transaction.

Snapshot is a foundational governance layer integrated by thousands of DAOs. Key integrations include:

• Wallet Interfaces: MetaMask, WalletConnect for signature signing.
• Blockchain Data Providers: The Graph for querying token balances at historical blocks.
• Execution Plugins: Tools like Gnosis Safe Snapshot Executor to automate the on-chain execution of passed proposals.
• Forking: Communities can fork a Space's configuration to create their own governance instance, promoting experimentation.

Snapshot's security relies on the cryptographic integrity of EIP-712 signed messages and the immutability of the referenced blockchain state. Key considerations:

• Sybil Resistance: Depends entirely on the chosen voting strategy (e.g., token ownership).
• No On-Chain Enforcement: A successful vote is a signal; it does not automatically execute code or move funds.
• Snapshot Block Manipulation: The choice of block height is a trusted parameter set by the Space admin.
• Front-running: Since votes are off-chain, traditional MEV front-running is not applicable, but proposal timing can be strategic.

A snapshot is a point-in-time capture of blockchain state, typically recording token balances or NFT holdings for a specific set of addresses at a predetermined block height. It is a read-only operation that does not require user interaction or a transaction. The process is deterministic, meaning anyone can independently verify the recorded data by querying the historical state of the chain.

• Key Inputs: Block number, token contract address, and a list of target addresses.
• Output: A verifiable dataset (e.g., a Merkle tree) mapping addresses to their balances.

Snapshots are a foundational tool for distributing resources or rights based on historical ownership.

• Airdrops & Retroactive Funding: To fairly distribute new tokens to past users of a protocol (e.g., Uniswap's UNI airdrop to historical liquidity providers).
• On-Chain Governance: To determine voting power for token-weighted voting systems, ensuring votes reflect holdings at a specific past time to prevent manipulation.
• Protocol Upgrades & Migrations: To record user positions before a major network upgrade or token migration, ensuring a seamless transition.

Trust in a snapshot's accuracy is paramount. Integrity is ensured through cryptographic verification and transparency.

• Merkle Proofs: A common method where the snapshot data is hashed into a Merkle tree. Users can provide a compact Merkle proof to verify their inclusion and balance without needing the entire dataset.
• Full Transparency: The block height and contract address are public. Anyone can run an archive node to replay the chain state and validate the snapshot data.
• Challenge: Relies on the availability of archive node data, which can be resource-intensive to store and query.

Creating a reliable snapshot involves several technical hurdles.

• State Finality: Must wait for sufficient block confirmations to ensure the recorded block is not part of a reorg. Proof-of-Stake chains with fast finality simplify this.
• Data Scale: Snapping large ecosystems (e.g., all ERC-20 holders) requires efficient indexing and can generate massive datasets.
• Edge Cases: Must account for delegated tokens (e.g., staked or in lending pools), internal balances within smart contracts, and tokens in cross-chain bridges.

It's critical to distinguish between a historical snapshot and a live balance query.

Using a live query for an airdrop would allow sybil attacks and last-minute balance stuffing.

Several specialized tools and services exist to create and manage snapshots.

• The Graph Protocol: Indexes historical blockchain data into queryable subgraphs, often used to generate snapshot datasets.
• Blockchain Clients (Geth, Erigon): Can be used to programmatically query historical state via RPC calls (eth_getBalance at a specific block).
• Snapshot.org: A popular off-chain voting platform that uses snapshots of token holdings to weight votes, storing the data on IPFS.
• Custom Indexers: Many projects build custom indexers using services like Chainscore to track and snapshot complex user interactions and liquidity positions over time.

Snapshot is an off-chain voting platform. Votes are signed messages stored on IPFS, not executed as on-chain transactions. This eliminates gas fees and reduces voter fatigue, but the final execution of a proposal's outcome is a separate, manual step. On-chain governance, like in Compound or MakerDAO, executes votes directly via smart contracts, providing stronger guarantees but at higher cost and complexity.

A voting strategy defines the rules for who can vote and how voting power is calculated (e.g., token balance, delegated votes). The critical security assumption is that the data source for this strategy (like an RPC node or The Graph subgraph) is providing the correct, unaltered blockchain state for the specified block number. Manipulation of this data source could distort voting power allocation.

Voters sign their vote with their private key, creating a cryptographic signature that proves ownership of the voting address. The core Sybil resistance comes from the voting strategy itself (e.g., 1 token = 1 vote). However, strategies based on simple token holdings are vulnerable to vote buying or whale dominance, where a single entity controls a majority of voting power.

• Proposal Upload: A malicious or poorly configured IPFS pinning service could lose proposal data.
• Execution Lag: The gap between a Snapshot vote passing and its on-chain execution creates a window for governance attacks. A token holder could vote 'yes' and then sell their tokens before execution, avoiding the consequences.
• Multisig Reliance: Execution often depends on a multisig wallet, introducing centralization and signer collusion risk.

Projects can implement more robust strategies to mitigate risks:

• Time-weighted voting: Voting power is based on tokens held for a minimum duration, reducing flash loan attacks.
• Delegation: Allows token holders to delegate voting power to experts, improving participation quality.
• Execution Safeguards: Using timelocks or zodiac modules to delay or automate execution, reducing multisig power.
• Data Verification: Using multiple, reputable RPC providers or indexers to cross-check state data.

Understanding Snapshot requires familiarity with adjacent systems:

• IPFS (InterPlanetary File System): The decentralized storage layer for proposal and vote data.
• EIP-712: The standard for typed structured data signing used by Snapshot votes.
• Safe (Gnosis Safe): A common multisig wallet used as the executor for Snapshot proposals.
• Snapshot X: An extension allowing cross-chain voting strategies using state proofs.

Plug-in modules that define how voting power is calculated for a Snapshot space. They allow governance to move beyond simple token-weighted voting. Common strategies include:

• Token-weighted: 1 token = 1 vote.
• Delegated: Votes from token delegates (e.g., ve-token models).
• Multichain: Aggregating balances across multiple chains.
• NFT-based: Voting power based on NFT ownership (e.g., 1 NFT = 1 vote). Strategies are composable, enabling complex quadratic voting or conviction voting models.

A dedicated hub on the Snapshot platform for a specific DAO or community. Each Space is configured with:

• Admins and moderators who manage proposals.
• A custom domain (e.g., snapshot.org/#/uniswap).
• Voting strategies and validation rules.
• Voting systems (single choice, weighted, quadratic). A Space is the primary interface where token holders interact with a project's governance process.

A Gnosis Safe module that bridges off-chain Snapshot votes with on-chain execution. It enables trust-minimized execution of governance decisions by:

1. Proposing a transaction hash on Snapshot.
2. Voting off-chain on the proposal.
3. Executing the transaction automatically if the vote passes, using a reality.eth oracle to verify the Snapshot result on-chain. This creates a seamless flow from signal to execution without relying on a centralized multisig operator.