Snapshot
Recorded state at a chosen time or block used for voting or distribution.
A snapshot is a recorded view of balances, ownership, or other state at a specific time or blockchain block. Governance systems use snapshots to determine who can vote and how much voting power each participant has. The term also applies to token distributions, migrations, rewards, and technical backups that depend on a fixed reference state.
Without a snapshot, voting power could change throughout an election as tokens move between wallets. A user might vote, transfer the same tokens, and vote again from another address. Measuring balances at one chosen block prevents this simple reuse. Delegation and specialized strategies can still affect the calculation, so proposals must explain exactly which assets, addresses, and rules count.
Snapshot is also the name of a widely used off-chain governance platform. Voters sign structured messages rather than paying gas for ordinary on-chain votes. The platform reads historical blockchain state and applies a community's voting strategy. This makes participation cheap, but the signed vote alone usually does not execute a treasury transfer or contract upgrade.
Execution depends on governance design. A multisignature group may treat the result as instruction, or an integration may connect an approved proposal to on-chain execution after validation and delay. Users should identify who can implement, veto, modify, or ignore the outcome. An off-chain majority is not automatically binding when administrators retain final control.
Snapshot selection can influence results. A block chosen before a public announcement may exclude newly acquired tokens, while one selected later can allow strategic borrowing or transfers. Token balances held by exchanges, bridges, contracts, or vesting systems may be included or excluded. Communities should publish the reference block and calculation method early enough for independent verification.
For an airdrop or migration, a snapshot proves eligibility under announced rules, not guaranteed value or immediate delivery. Scammers often imitate claim pages after snapshots. Verify the official source, contract, network, and signature request. Preserve the published block and methodology so independent users can reproduce results. A well-defined snapshot creates a reproducible historical boundary, but fairness depends on transparent timing, accurate data, appropriate eligibility rules, and a trusted path from recorded state to final action.
Frequently asked questions
- A community defines a proposal, voting strategy, eligible assets, and reference block. Voters sign messages without submitting ordinary on-chain transactions, and the system calculates voting power from balances or delegation at that block. Strategies can include several tokens or rules. Users should verify the official space, proposal terms, message domain, and whether the result is binding.
- A basic Snapshot vote records signed preferences off-chain and does not automatically change a contract. A multisignature, governance module, or other executor may implement the result. Some integrations connect voting to on-chain execution with additional validation. Check who can execute, change, delay, or ignore the outcome because a successful vote may be advisory rather than self-enforcing.
- Each governance space defines proposer requirements, which may include a minimum token balance, delegated voting power, membership, or an allowlist. Open proposal creation improves access but can create spam. Confirm that a proposal appears in the official space and meets its rules. A copied space name, logo, or link can be used to collect misleading signatures or promote scams.