OAK — OnChain Attack Knowledge

Worked example · 2022-20

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

Loss
structural — Snapshot is an off-chain, gasless voting platform used by thousands of DAOs for governance proposal signalling. Because Snapshot voting power is computed from on-chain token balances at a snapshot block, and Snapshot does not enforce any vote-validity checks beyond the balance-at-block calculation, flash-loaned and temporarily-delegated voting power can pass Snapshot's voting-power threshold while representing zero economic commitment to the DAO. Individual governance outcomes affected by T16.004 are DAO-specific and not reducible to a single dollar-loss figure; the structural cost is the corruption of the governance-signalling function that the DAO relies on for legitimate decision-making.
OAK Techniques observed
OAK-T16.004 (Snapshot Off-Chain Voting Exploitation — primary; the Snapshot platform's off-chain architecture accepts token-balance-at-block as the sole voting-power input without on-chain commitment or economic-stake requirements). OAK-T16.002 (Flash-Loan-Enabled Governance Manipulation — structurally adjacent; flash-loaned tokens are the most common mechanism for temporarily acquiring the token balance needed to pass a Snapshot vote threshold). OAK-T9.002 (Flash-Loan-Enabled Exploit — the capital-acquisition primitive that funds the governance attack without requiring the attacker to hold the underlying governance token).
Attribution
pseudonymous (specific Snapshot proposals that passed via flash-loaned voting power are identifiable post-hoc; per-proposal attribution to named attackers is sparse at v0.1). The attack surface is structural to the Snapshot platform's architecture rather than attributable to specific adversaries.
Key teaching point
Snapshot's off-chain, gasless, balance-at-block voting model enables voting-power acquisition without economic commitment. Because Snapshot voting does not require the voter to lock tokens, stake tokens, or incur any per-vote cost (voting is gasless), an attacker can acquire voting power via flash loan, vote on a proposal, and return the loan within a single block — exercising governance influence over a DAO in which the attacker holds zero net economic interest. The "balance at snapshot block" check is a necessary-but-not-sufficient condition for legitimate governance participation.

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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}
}

Techniques demonstrated (3)