Worked example · 2022-20
Snapshot off-chain voting exploitation via flash-loaned and delegated voting power — Ethereum — 2022–2024
Summary
Snapshot (snapshot.org) is the dominant off-chain governance voting platform for Ethereum and EVM-chain DAOs. The platform's architecture is deliberately lightweight: DAOs define a "space" with a voting strategy (typically "balance of governance token at block N"), proposals are submitted and voted on off-chain with signed messages, and the results are published on Snapshot's interface. No on-chain execution occurs through Snapshot itself; the vote is a signalling mechanism that the DAO's multisig signers or on-chain governance contracts are expected to honour.
The T16.004 attack surface arises from the gap between the Snapshot voting model (balance-at-block equals voting power) and the economic commitment model that the DAO's governance design assumes (voting power should represent long-term economic alignment with the DAO).
The canonical exploitation pattern:
Attacker identifies a DAO using Snapshot with a token-balance voting strategy. The DAO's Snapshot space is configured to count governance-token balance at a specified block as voting power.
Attacker acquires voting power through flash loan or temporary delegation. A flash loan of the governance token from a lending market (Aave, Compound, Euler) gives the attacker a token balance that passes the Snapshot voting threshold at the snapshot block. Alternatively, the attacker can solicit temporary delegation from liquidity-provider or staking-pool addresses that hold the governance token but do not actively participate in governance.
Attacker votes on a proposal during the voting window. The Snapshot vote is signed off-chain (no gas cost) and submitted to Snapshot's relay. The vote is valid because the attacker's balance at the snapshot block meets the threshold.
Attacker unwinds the position. If flash-loaned: the loan is returned within the same block (or within the voting window). If temporarily delegated: the delegation is revoked after the vote. The attacker retains zero net governance-token exposure.
The proposal passes or fails based on the attacker's voting power. The DAO's multisig signers or on-chain governance contracts are expected to honour the Snapshot result. A proposal that passed due to flash-loaned voting power may not represent the DAO's genuine governance consensus.
The class is most visible at the DAO-specific level: protocols including Beanstalk (2022-04 — on-chain governance attack via flash loan, T16.002-primary with adjacent T16.004 surface), various smaller DAOs (2022–2024) whose Snapshot votes were influenced by flash-loaned voting power, and protocols that have adopted anti-flash-loan Snapshot strategies (e.g., requiring token locking, staking, or time-weighted balance) specifically in response to this class.
No single named T16.004 incident is asserted as canonical at v0.1 because: (a) Snapshot voting is off-chain signalling, so a T16.004-influenced vote does not directly execute on-chain value transfer; (b) the public forensic record on flash-loan-influenced Snapshot votes is sparser than on on-chain governance attacks (T16.001–T16.003) because the attack is at the signalling layer rather than the execution layer; (c) many DAOs have adopted anti-flash-loan Snapshot strategies as a pre-deployment guard, moving the surface from realised-exploit to audit-firm-advisory space.
Timeline
| When | Event | OAK ref |
|---|---|---|
| 2020–2021 | Snapshot adoption as dominant off-chain DAO voting platform | (surface deployment) |
| 2022 | Flash-loan-influenced Snapshot votes documented at smaller DAOs; community awareness of the surface grows | T16.004 class onset |
| 2022–2024 | DAOs adopt anti-flash-loan Snapshot strategies (token locking, staking, time-weighted balance, delegation-window minimums) | (mitigation deployment) |
| 2024 | T16.004 is an audit-firm-advisory surface rather than a headline-incident surface; most DAOs with Snapshot governance have adopted some form of flash-loan-resistant voting strategy | T16.004 steady state |
What defenders observed
- Balance-at-block is a necessary-but-not-sufficient condition for legitimate governance participation. A token balance at a specified block confirms that the address held the tokens at that block; it does not confirm that the address has long-term economic alignment with the DAO. Flash-loaned and temporarily-delegated balances satisfy the balance check while circumventing the economic-alignment assumption.
- Snapshot's gasless, off-chain architecture is both the reason for its adoption and the reason T16.004 is resilient. Gasless voting enables broad participation; it also enables attackers to vote without incurring any per-vote cost, making flash-loaned-voting a cost-free attack when the loan fee is covered by favourable lending-market rates.
- The mitigation is at the voting-strategy layer, not the Snapshot platform layer. Snapshot supports pluggable voting strategies. DAOs can require: (a) token locking during the voting window, (b) time-weighted balance (balance held for a minimum duration before the snapshot block), (c) delegation with a minimum delegation-age requirement, (d) staking with unbonding period. Each of these closes the flash-loan vector by adding an economic-commitment dimension to the balance check.
What this example tells contributors writing future Technique pages
- T16.004 is the off-chain analogue of T16.002 (Flash-Loan-Enabled Governance Manipulation). T16.002 covers on-chain governance attacks where flash-loaned voting power directly executes a malicious proposal. T16.004 covers the off-chain signalling layer where flash-loaned voting power influences the Snapshot vote that the DAO's on-chain actors are expected to honour. The two compose: a T16.004-influenced Snapshot vote that directs on-chain execution is a T16.002 ↔ T16.004 compound.
- No single named incident is canonical for T16.004 at v0.1 because the surface operates at the signalling layer. Contributors writing future T16.004 examples should expect the public forensic record to be at the DAO-governance-review layer rather than the exploit-forensic layer, and should treat per-DAO Snapshot strategy audits as the primary defensive evidence.
Public references
- Snapshot. "Voting Strategies."
docs.snapshot.org— pluggable voting strategies including token-balance, delegation, and time-weighted-balance strategies. - Snapshot. "Anti-Flash-Loan Voting Strategies." Community documentation, 2022–2024.
- Cross-reference: T16.004 (Snapshot Off-Chain Voting Exploitation) at
techniques/T16.004-snapshot-off-chain-voting-exploitation.md. - Cross-reference: T16.002 (Flash-Loan-Enabled Governance Manipulation) at
techniques/T16.002-flash-loan-governance-manipulation.md. - Cross-reference: T9.002 (Flash-Loan-Enabled Exploit) at
techniques/T9.002-flash-loan-enabled-exploit.md.
Proposed new BibTeX entries
@misc{snapshotantiflashloan2024,
author = {{Snapshot community}},
title = {Anti-Flash-Loan Voting Strategies for Snapshot Governance},
year = {2024},
note = {Token locking, time-weighted balance, delegation-age minimums, and staking-with-unbonding-period strategies that close the T16.004 flash-loan vector}
}