Description

Governance / Voting Manipulation covers the post-launch use of a protocol's voting / governance surface to direct on-chain authority — treasury, parameters, upgrade slots, role assignments — into the attacker's favour. The defining shape is that the on-chain authority being misused is the protocol's own legitimate governance authority: votes are cryptographically valid, proposals pass quorum, the timelock either expires or is bypassed by a contract-level mechanism the design itself permits. The attack lives at the layer where voting power converts into protocol decisions; mitigation lives at the governance-design + governance-process layer.

T16 is intentionally distinct from T3 (Holder Capture). T3 covers the launch-time mechanics that produce a concentrated or controllable holder base — sybil-bundled launches, insider allocation, airdrop-farming clusters. The defender signal at T3 is at deployment / distribution time (genesis-balance distribution, funder-graph clustering at TGE). T16 covers the post-launch operational use of voting power that has already been concentrated (or that the attacker has just acquired via flash-loan, market accumulation, or delegation pull) to push the protocol's governance into a malicious decision. The two tactics are sequentially linked one-to-many: a single T3 outcome may underwrite multiple downstream T16 events over the protocol's governance lifetime, and a T16 sub-Technique can fire against a protocol whose holder base was not concentrated at genesis (the attacker just acquired voting power on the open market or rented it via flash-loan).

T16 is also distinct from the generic T9.003 (Governance Attack) sub-Technique inside T9. T9.003 is the generic class label — "governance was used as an attack vector against a protocol" — and remains in place at the smart-contract-exploit Tactic level as the catch-all for governance-class failure modes. T16 is the Tactic-level home for the load-bearing operational sub-patterns within that class — flash-loan vote takeover, hostile-vote treasury drain, delegation-cluster takeover, off-chain Snapshot exploitation, malicious-proposal snowballing — that share enough common structure (voting-power as the load-bearing surface, post-launch operational use, governance-design + governance-process mitigation, kill-chain phase that sits after T3 and before / parallel to T5) to deserve their own Tactic. v0.1 OAK had to document these patterns as paragraphs inside T9.003's Discussion section because no Tactic-level home existed; T16 closes that gap. Existing T9.003 mappings on anchor worked examples are preserved — every T16.x example also maps to T9.003 — so downstream consumers pinned to the v0.1 schema continue to resolve the existing IDs without breakage.

T16 sits in the kill-chain after T3 (post-launch, the holder state already exists or is acquired) and before / parallel to T5 (T16.002 is the upstream of a T5.005-class treasury egress). The Tactic boundary is the layer at which the load-bearing surface is voting power: if the attack converts voting power into a protocol decision, it is T16; if the attack manipulates an oracle, exploits a reentrancy bug, or hijacks a deployer key without going through a vote, it is T9 / T11.

What defenders observe

Sudden acquisition of governance-token voting power by a single address or a tightly-related cluster, often funded by a flash loan inside a single block (T16.001) or accumulated over weeks-to-months on the open market (T16.002 / T16.003); voting-power-vs-circulating-supply ratio at vote-submission well above the protocol's typical participation ratio.
Submission and rapid execution of a governance proposal whose payload directs treasury, mint privileged roles, modifies the upgrade slot, or performs a delegatecall to a non-canonical target; use of emergencyCommit-class expedited-execution functions that bypass the normal proposal lifecycle (Beanstalk pattern).
Coordinated delegation flows from a cluster of addresses pulling delegation to a single delegate within a narrow window prior to a contested proposal (T16.003); the delegation cluster's funding-graph signal frequently overlaps with T8.001 cluster-reuse.
Off-chain Snapshot.org-class vote outcomes that are disputed, overridden, or shown post-hoc to have been Sybil-attacked or signature-replayed (T16.004); the trust-substrate failure is that the off-chain vote result was treated as binding without on-chain economic finality.
Proposal calldata that obscures malicious effect — delegatecall to attacker contract, hidden state-replacement via selfdestruct + redeploy, storage-slot manipulation via inherited-contract layout collision (T16.005, Tornado Cash 2023 + Audius 2022 + Curio 2024 patterns).
Multisig-to-governance pivots: an attacker who compromises a privileged multisig (T11.x) submits a malicious proposal that the multisig itself executes, converting a custody compromise into a governance compromise.

Relationship to other tactics

T16 is the operational-use Tactic for downstream T5 / T11 / T9 events that go through the governance surface. The shape of the kill-chain that T16 makes legible:

T16.001 (flash-loan vote takeover) → T5.005 / T9 treasury egress is the canonical Beanstalk April 2022 pattern: flash-loan the voting tokens in one block, vote, drain the treasury via the malicious proposal payload, repay the flash-loan, exit. Pairs with T9.002 (flash-loan precondition) and T9.003 (generic governance-attack class).
T16.002 (hostile-vote treasury drain) → T5.005 is the canonical Mango Markets October 2022 second-step pattern: legitimate market accumulation of governance tokens (post-T9.001 oracle manipulation that inflated the attacker's MNGO position) used to vote a $47M settlement out of the DAO treasury into the attacker's pocket. Pairs with T9.001 (oracle-manipulation as the value-inflation step) and T5.005 (treasury exit framing).
T16.003 (delegation-cluster vote takeover) is the canonical Compound Proposal 289 July 2024 pattern: delegation accumulation across a multi-week window from a publicly-identified cluster ("Golden Boys" / Humpy), proposal submission whose payload self-deals treasury into the cohort's vehicle. Pairs with T8.001 (cluster-reuse signal as the defender-side detection layer) and T9.003 (parent technique class).
T16.004 (Snapshot off-chain exploitation) is the canonical class for off-chain-only voting platforms whose results are not enforced by economic finality. v0.1 has the class but no canonical anchor at the dollar-loss scale of the on-chain T16.x sub-Techniques; documented Sybil / signature-replay patterns at Snapshot.org and similar platforms exist but the public-record concentration is at the dispute / governance-legitimacy layer rather than at extraction events.
T16.005 (malicious proposal snowballing) is the canonical class for proposals whose malicious effect is obscured at proposal-text time and only manifests on execution: hidden delegatecall, storage-collision-mediated authority capture, selfdestruct + redeploy with attacker-controlled logic. Anchors: Tornado Cash governance May 2023 (Proposal 20 self-modifying-contract), Audius July 2022 (storage-collision proposer-eligibility), Curio DAO March 2024 (storage-collision in MakerDAO-fork).

T16 mitigation is concentrated at the governance-design layer (snapshot-based / time-averaged voting power, mandatory minimum proposal delay / timelock, removal of emergencyCommit-class expedited paths, proposal-payload static analysis (OAK-M02), execution-target allowlists, voting-power-resistance against flash loans by computing voting weight at proposal-creation time over a multi-block window), the governance-process layer (timelock-gated execution paired with active community counter-proposal capability — the Compound 2024 lesson), and the cohort-surveillance layer (T8.001 cluster-attribution applied to delegation flows; CTI integration on publicly-known governance-coordination cohorts). The dollar-loss-prevented metric for T16 is most sensitive to time-between-proposal-passage-and-execution — every T16 incident at v0.1 either had no timelock (Beanstalk's emergencyCommit realised the loss within a single block) or had a timelock that the community used as the review window to deploy a counter-proposal (Compound 2024 prevented the loss).

Sub-Techniques

OAK-T16.001 — Vote Takeover via Flash-Loan
OAK-T16.002 — Hostile-Vote Treasury Drain
OAK-T16.003 — Delegation-Cluster Vote Takeover
OAK-T16.004 — Snapshot / Off-chain Voting Exploitation
OAK-T16.005 — Malicious Proposal Snowballing

Discussion

The core editorial question this Tactic answers: why split T16 out of T9 rather than continue documenting these events as sub-patterns inside T9.003? The answer is structural, not taxonomic.

A defender reading T9.003 at v0.1 was reading a Technique page that conflated five operationally distinct sub-patterns under a single "governance attack" label: same-block flash-loan vote takeover (Beanstalk), multi-week delegation-cluster accumulation (Compound 289), market-accumulated hostile vote against a DAO treasury post-oracle-inflation (Mango Markets), self-modifying proposal payload (Tornado Cash 2023), storage-collision-mediated authority capture (Audius / Curio). The mitigation surfaces for these five sub-patterns are structurally different — flash-loan vote takeover is mitigated by snapshot-based / time-averaged voting power; delegation-cluster takeover is mitigated by cohort-level surveillance + counter-proposal capability; hostile-vote treasury drain is mitigated upstream at the oracle layer; malicious-proposal snowballing is mitigated by proposal-payload static analysis + execution-target allowlists; off-chain Snapshot exploitation is mitigated by economic-finality enforcement (or by not treating Snapshot as binding for high-stakes decisions). A single Technique page covering all five made the enumeration awkward and consistently produced worked-example pages that gestured at the sub-class structure in their Discussion sections without giving each sub-class Tactic-level visibility.

T16 makes the kill-chain read correctly. A Beanstalk-class incident now reads as T16.001 (flash-loan vote takeover) → T9.003 (generic governance-attack class) → T5.005 (treasury egress). A Mango Markets-class incident reads as T9.001 (oracle inflation) → T16.002 (hostile-vote treasury drain) → T5.005. A Compound Proposal 289 reads as T16.003 (delegation-cluster takeover) → T9.003 → (prevented). A Tornado Cash 2023 reads as T16.005 (malicious proposal) → T9.003 + T9.004. The Tactic boundary is the layer at which the load-bearing surface is voting power; sub-Technique boundaries inside T16 partition by the operational-acquisition mechanism (flash-loan / market / delegation / off-chain / proposal-payload).

T16 is purely additive against T9.003. The generic T9.003 page remains in place as the smart-contract-exploit-Tactic catch-all for governance-class failures; every T16.x sub-Technique cross-references T9.003 as parent class; every anchor worked example carries both the existing T9.003 mapping AND the new T16.x cross-reference. Downstream consumers pinned to the v0.1 schema continue to resolve T9.003; consumers consuming the v0.2-and-later schema see the additional T16.x granularity.

Maturity boundary: T16.001 / T16.002 / T16.003 are anchored by canonical worked examples (Beanstalk, Mango Markets, Compound Proposal 289) and are emerging at introduction. T16.005 is anchored by Tornado Cash 2023 + Audius 2022 + Curio 2024 and is emerging. T16.004 (Snapshot off-chain exploitation) lacks a clean dollar-loss anchor at v0.1 — the public record at Snapshot.org-class platforms concentrates at governance-legitimacy disputes rather than at dollar-extraction events — and is introduced as draft with the gap explicitly documented; future contributors should anchor it once a canonical Sybil / signature-replay / off-chain-vote-without-binding case lands at extraction-scale.

T16 is also the OAK editorial response to the v0.1 TAXONOMY-GAPS observation that governance-attack sub-class structure was the largest single un-Tactic'd cohort in the corpus: Beanstalk + Mango + Compound + Tornado Cash + Audius + Curio collectively represent ~$300M+ in realised or prevented loss across multiple distinct operational sub-patterns that the v0.1 T9.003 page could only enumerate in a "deferred sub-class structure" footnote. Adding T16 lifts those sub-patterns to Tactic-level so future worked examples can map to the operational sub-pattern without forcing reviewers to choose between "T9.003 with a sub-class footnote" and "an undocumented Technique."

Maintainer notes

T16 is an explicit response to the v0.1 observation in T9.003-governance-attack.md that the "deferred sub-class structure" footnote (T9.003.001 / T9.003.002 / T9.003.003) was load-bearing across Beanstalk, Tornado Cash, and Compound 289 worked examples but had no Tactic-level home. Promoting these to T16.001 / T16.005 / T16.003 (and adding T16.002 for the Mango Markets-class chain and T16.004 for the off-chain Snapshot class) gives them Tactic-level visibility and lets future contributors anchor against the operational sub-pattern.

Per VERSIONING.md, adding T16 is an additive schema change (schema-minor bump): existing T1-T15 IDs are unchanged, and existing T9.003 / T9.001 / T9.002 / T8.001 / T5.005 worked-example mappings are preserved. Anchor worked examples carry both the existing on-chain Technique mapping AND the new T16.x cross-reference, so downstream consumers pinned to the v0.1 schema continue to resolve the existing IDs without breakage.

Future T16 contributions should preserve three boundary rules:

Voting power is the load-bearing surface. If the attack does not go through a vote (or through a vote-equivalent governance signal whose result the protocol enforces), it is not T16. Oracle manipulation that doesn't go through a vote is T9.001; deployer-key compromise is T11.x; reentrancy is T9.005.
Post-launch, not launch-time. T16 is the operational-use Tactic. Launch-time concentration of holder state is T3. A worked example that maps to T3 without a downstream T16 is incomplete-by-time only — the holder base may not yet have been used against the protocol; T16 maps when the use happens.
T9.003 mapping preserved. Every T16.x worked example also maps to T9.003. Removing T9.003 in favour of T16.x is a downstream-consumer-breaking change and is explicitly forbidden by VERSIONING.md without a schema-major bump.

OAK-T16 — Governance / Voting Manipulation