Snapshot off-chain voting exploitation via flash-loaned and delegated voting power — Ethereum — 2022–2024

Summary

Snapshot is the dominant off-chain governance voting platform for EVM-chain DAOs. DAOs define a "space" with voting strategies; proposals are voted on with signed messages; no on-chain execution occurs through Snapshot itself, and the vote is a signalling mechanism that a DAO's multisig signers or on-chain governance are expected to honour.

Per Snapshot's documentation, when a proposal is created the snapshot block defaults to the latest block synced by Snapshot's node; each voter's power is evaluated against chain state at that block, so tokens acquired after proposal creation are not counted, and validation by default also checks strategies at the snapshot block. Spaces may combine multiple strategies, and some validate at the latest block for non-transferable tokens.

The residual surface that remains is: (a) power acquired before the snapshot block that carries no lasting commitment (purchased or borrowed beforehand, or delegated), (b) strategies configured to read the latest block, and (c) the gap between a signalling vote and the economic alignment the DAO assumes. Flash-loan governance exploits are documented on-chain governance systems that read voting power at or after proposal creation (for example the FutureSwapX case described by Verichains, which exploited the FST token's on-chain snapshot() flow), not Snapshot.org.

No named T16.004 incident is asserted as canonical here; contributors should treat the technique as a structural surface until a sourced incident exists.

What defenders observed

• The snapshot block, not the vote time, determines Snapshot voting power. Mitigations are at the voting-strategy layer: validation settings, time-weighted or locked balances, and delegation requirements. Which of these specific strategies each DAO adopted, and when, is not established in the cited sources.
• Gasless voting removes per-vote cost. That broadens participation and makes pre-acquired power cheap to use.

What this example tells contributors writing future Technique pages

• T16.004 should not be described as a same-block flash-loan attack. The same-block flash-loan pattern belongs to T16.002 on on-chain governance with latest-block or post-proposal balance reads.
• Require a named, sourced incident before treating T16.004 as realised. This file documents a design surface, not an event.

Public references

• [snapshotcreate] — Snapshot docs, "Create a proposal": https://docs.snapshot.box/user-guides/create
• [snapshotvalidation] — Snapshot docs, "Validation strategies": https://docs.snapshot.box/user-guides/validation-strategies
• [verichainsflash] — Verichains, "Governance Attack: Flashloan Vote Manipulation" (FutureSwapX, on-chain): https://blog.verichains.io/p/governance-attack-flashloan-vote
• Cross-reference: T16.004 at techniques/T16.004-snapshot-off-chain-voting-exploitation.md.
• Cross-reference: T16.002 at techniques/T16.002-flash-loan-governance-manipulation.md.
• Cross-reference: T9.002 at techniques/T9.002-flash-loan-enabled-exploit.md.