OAK — OnChain Attack Knowledge

Worked example · 2022-20

DAO Governance Exploitation Cohort — 2022–2025 — Aggregate $30M+ Attempted, ~$8M Realised

Loss
Aggregate nominal loss across the combined delegation-cluster vote-takeover and malicious-proposal-snowballing sub-cohorts spans approximately $30M+ in attempted extraction (Compound Proposal 289: ~$24M attempted, prevented; Audius: ~$6M realised; Tornado Cash: ~$1M nominal, ~$890K returned; Curio DAO: ~$16M nominal, ~$1M realised; Unleash Protocol: ~$3.9M). Realised loss across named cases is approximately $8M (Audius $6M + Curio $1M + Unleash $3.9M + Tornado net ~$110K), with the Compound $24M prevented by the timelock review window. The gap between nominal ($30M+) and realised (~$8M) is the most important number in the T16 corpus: it measures the effectiveness of the timelock review window as a governance-process mitigation.
OAK Techniques observed
OAK-T16.003 (Delegation-Cluster Vote Takeover — acquisition of governance voting power through delegation pull from a cluster of compromised, controlled, or coordinating wallets, used to push a malicious proposal through a protocol's governance. The defining shape is multi-wallet → single-delegate concentration of voting weight, accumulated over a multi-week to multi-month window. Canonical anchor: Compound Proposal 289, July 2024 — the "Golden Boys"/Humpy cohort.) OAK-T16.005 (Malicious Proposal Snowballing — submission of a governance proposal whose on-chain execution-payload semantics diverge from the proposal text as displayed by the front-end UI. The defining shape is proposal-text-vs-payload divergence: the community votes based on the benign front-end-displayed text; the hidden on-chain payload grants the proposer voting power, admin authority, or direct treasury access on execution. Canonical anchor: Tornado Cash governance May 2023.)
Attribution
unattributed — The named cases span independent actors across Compound, Tornado Cash, Audius, Curio DAO, and Unleash Protocol. The Humpy/Golden Boys cohort (Compound 289, Balancer, SushiSwap) is the only cross-protocol pattern-of-conduct actor in the T16.003 sub-cohort. The Tornado Cash governance attacker operated independently and returned ~$890K with an "I was demonstrating a vulnerability" framing.
Key teaching point
T16.003 and T16.005 attack the governance process at different layers — T16.003 at the voting-power-acquisition layer (who gets to vote), T16.005 at the proposal-execution layer (what the vote actually executes) — and a DAO that is defended against one is not automatically defended against the other. Snapshot-based voting power (T16.001 mitigation) does not close T16.003 because the attacker holds the position at every snapshot. Cohort-surveillance of delegation flows (T16.003 mitigation) does not close T16.005 because the attacker does not need to acquire voting power before the attack — the attack itself is the mechanism by which voting power is acquired or the malicious effect is delivered. The timelock review window is the only mitigation that spans both Technique classes: it provides the detection-and-response window for T16.003 (Compound 289 was caught in the timelock window) and the proposal-payload review window for T16.005 (proposal calldata can be statically analysed during the timelock window). A governance process without a timelock review window is structurally undefended against both T16.003 and T16.005.

Summary

This cohort entry documents two distinct but complementary T16 sub-patterns that together cover the governance-attack lifecycle: T16.003 attacks the voting-power-acquisition phase (accumulating delegation-pulled voting weight to clear quorum on a malicious proposal), and T16.005 attacks the proposal-execution phase (embedding a hidden malicious effect in a proposal that passes on legitimate vote weight). The two Techniques are structurally independent — an attacker can use either, both, or neither — but they share the same governance-process root cause: the gap between what the governance UI displays (voting power distribution, proposal text) and what the on-chain governance contract actually executes.

T16.003: Delegation-Cluster Vote Takeover

The delegation-cluster vote takeover exploits the delegation primitive that is standard in modern Governor-Bravo-pattern DAOs. The attacker accumulates governance tokens across multiple addresses through direct on-chain purchases over a multi-week to multi-month window, then pulls delegation from each holding address to a single coordinating delegate (or tightly-coordinated delegate set). The delegation graph topology — multi-wallet → single-delegate concentration — is the defining signal.

The canonical case is Compound Proposal 289 (July 2024). The "Golden Boys" cohort (including the wallet associated with the pseudonymous identity "Humpy") accumulated COMP across multiple addresses and pulled delegation to a coordinating delegate, reaching the COMP governance quorum threshold. The cohort submitted Proposal 289 directing 499,000 COMP ($24M) from the Compound DAO treasury to a "goldCOMP" yield-bearing vault effectively controlled by the cohort. The proposal passed the on-chain vote — the cohort's accumulated delegation-pulled voting power cleared quorum and the simple-majority threshold. Between vote-passage and the timelock-gated execution window, the broader Compound community recognised the proposal as self-dealing, deployed an emergency counter-proposal, and cancelled the malicious treasury action before the timelock expired. The case is the canonical OAK example of a prevented T16-class attack and the canonical validation of the timelock review window as a governance-process mitigation.

The Humpy/Golden Boys pattern-of-conduct across Balancer and SushiSwap prior to Compound 289 is the canonical T8.001 + T16.003 cross-protocol cohort-surveillance signal. The cohort's coordination was publicly visible for months before Proposal 289; the Compound community's ability to recognise Proposal 289 as self-dealing depended on this prior visibility.

T16.003 also covers the compromised-wallet delegation pull sub-shape: an attacker compromises a set of wallets via T11.x/T15.x/T4.x and pulls delegation from each compromised wallet to an attacker-controlled delegate. This sub-shape is structurally distinct from the cohort-coordination sub-shape because the underlying wallets are not voluntary participants. v0.1 has the class but no canonical anchor at scale.

T16.005: Malicious Proposal Snowballing

The malicious proposal snowballing attack exploits the gap between the proposal text displayed by the governance front-end UI and the actual on-chain execution payload. The attacker submits a proposal whose front-end-displayed text describes a benign or routine action; the community votes based on the displayed text and the proposal passes on legitimate vote weight; at execution time, the hidden on-chain payload grants the proposer voting power, admin authority, or direct treasury access.

Four operational sub-shapes are documented:

Self-modifying-contract proposal (Tornado Cash, May 2023 — ~$1M nominal, ~$890K returned). The canonical T16.005 anchor. The attacker submitted Proposal 20 with front-end-displayed text describing a routine governance-treasury-management proposal; the deployed proposal contract included a hidden setup()-style function that granted the proposer 1.2M voting power on execution. The attacker then submitted and self-passed Proposal 21, transferring the governance treasury balance (~$1M) to attacker-controlled addresses. The attacker subsequently returned ~$890K with an "I was demonstrating a vulnerability" framing. The case chains T16.005 → T9.003 → T9.004.

Storage-layout collision proposal (Audius, July 2022 — ~$6M; Curio DAO, March 2024 — ~$16M nominal, ~$1M realised). The proposal payload exploits a storage-layout collision between the governance contract and a downstream contract. Audius: storage-collision proposer-eligibility bypass allowing the attacker to submit a malicious proposal after bypassing the role-assignment guard. Curio DAO: storage-layout collision between a MakerDAO-fork governance proxy and the CGT token contract, elevating a 1% voting position (acquired via flash loan — T16.001 component) into CGT admin authority, enabling mint of ~1B CGT tokens. Both cases chain T16.005 → T9.003 → T9.004, with T16.001 as a contributing primitive at Curio.

Hidden delegatecall to attacker-controlled code. Proposal calldata contains a delegatecall to an address that has not been a governance target in the protocol's history; the delegatecall runs in the governance contract's storage context and rewrites privileged storage slots to attacker-controlled values. v0.1 has the class but no canonical named anchor at the scale of Tornado Cash or Audius.

Multisig-to-governance pivot (Unleash Protocol, December 2025 — ~$3.9M). An externally-owned address acquired administrative control over Unleash's multi-signature governance system through a weakness in admin-permission enforcement, then pushed a contract upgrade through the multisig that enabled direct asset withdrawal outside approved governance. Boundary case against T11.x (upstream multisig compromise) + T9.004 (access-control misconfiguration); the T16.005 mapping captures the proposal-payload-as-attack-vector dimension.

The Timelock Review Window as the Spanning Mitigation

The timelock review window is the only mitigation that spans both T16.003 and T16.005. For T16.003, it provides the detection-and-response window: the Compound 289 case demonstrates that a community with operational counter-proposal capability can cancel a malicious treasury action during the timelock window even after the on-chain vote has passed. For T16.005, it provides the proposal-payload review window: the proposal calldata can be statically analysed during the timelock window, and hidden delegatecall, selfdestruct+redeploy, setup()-style, and storage-collision payloads can be detected before execution.

The structural implication is that a governance process without a timelock review window is undefended against both Technique classes. The timelock duration determines the detection-and-response budget: a short timelock (hours) may not provide sufficient time for community recognition (T16.003) or proposal-payload static analysis (T16.005); a long timelock (days) provides the budget but introduces operational friction for legitimate governance actions. The Compound 289 case suggests that a multi-day timelock with active community monitoring is the current best-practice calibration.

Timeline (UTC)

When Event OAK ref
2022-07-23 Audius: storage-collision proposer-eligibility bypass; ~$6M realised T16.005 (storage-collision sub-shape)
2023-05-20 Tornado Cash governance: self-modifying-contract proposal (Proposal 20 → 1.2M voting power → Proposal 21 treasury drain); ~$1M nominal, ~$890K returned T16.005 (self-modifying-contract sub-shape, canonical anchor)
2024-03-23 Curio DAO: MakerDAO-fork governance proxy storage collision; ~$16M nominal, ~$1M realised T16.005 + T16.001 (storage-collision + flash-loan hybrid)
2024-07-28 Compound DAO Proposal 289: Golden Boys/Humpy delegation-cluster vote takeover; ~$24M attempted, prevented in timelock window T16.003 (canonical anchor)
2025-12-30 Unleash Protocol: multisig-to-governance pivot via admin-permission enforcement weakness; ~$3.9M realised T16.005 + T9.004 + T11.x (multisig-to-governance boundary case)
2022–2025 Smaller-DAO T16.003 and T16.005 incidents continue; typically not published forensically due to bounded dollar-loss at smaller protocols T16.003 + T16.005 (ongoing class)

Public references

  • Compound DAO Proposal 289 on-chain vote record and community response (Tally/Boardroom governance dashboards)
  • Tornado Cash governance Proposal 20/21 on-chain execution trace and post-mortem analysis
  • Audius storage-collision governance-attack post-mortem (July 2022)
  • Curio DAO MakerDAO-fork governance proxy storage-collision post-mortem (March 2024)
  • Unleash Protocol unauthorised-upgrade governance-attack disclosure (December 2025)
  • [zhou2023sok] — academic taxonomy documenting proposal-payload-as-attack-vector incidents as a recurring sub-class through 2018–2022
  • See techniques/T16.003-delegation-cluster-vote-takeover.md and techniques/T16.005-malicious-proposal-snowballing.md for Technique definitions
  • Cross-reference: techniques/T9.003-governance-attack.md (generic governance attack class preserved on every T16 worked example), techniques/T9.004-access-control-misconfiguration.md (access-control misconfiguration frequently the post-passage privilege-escalation mechanism), techniques/T8.001-cluster-reuse.md (load-bearing for delegation-graph attribution in T16.003)

Discussion

The DAO governance exploitation cohort is the canonical illustration of a governance-process attack surface — the attacker does not exploit a smart-contract vulnerability in the traditional sense (reentrancy, integer overflow, access-control miss) but rather exploits the gap between the governance process as designed (delegation-based voting, proposal-text-as-front-end-display, timelock-gated execution) and the governance process as operated (multi-wallet delegation pull that is visible but not flagged, proposal payloads that diverge from displayed text, timelock windows that may be too short for community response). The attacker's primitives are the governance primitives themselves — delegation, proposal submission, on-chain execution — used in ways that are technically within the governance contract's specification but economically inconsistent with the DAO's intended governance model.

The Compound 289 and Tornado Cash cases together define the defender's calibration range for the timelock review window: Compound 289 (T16.003) was caught during the timelock window and prevented — the mitigation worked. Tornado Cash (T16.005) executed before the community could respond — the mitigation failed because the attack was not the proposal's voting outcome (which passed legitimately) but the proposal's hidden payload (which was not reviewed before execution). The lesson for DAO operators is that the timelock review window must serve two distinct functions — voting-outcome review (T16.003 defence) and proposal-payload review (T16.005 defence) — and a DAO that performs only the first is undefended against the second.

Techniques demonstrated (2)