OAK — OnChain Attack Knowledge

Worked example · 2022-02

Build Finance DAO hostile-takeover — Ethereum — 2022-02-09 to 2022-02-14

Loss
approximately $470,000–$490,000 realised across (a) 1,000,000–1,100,000 BUILD tokens minted by the attacker after gaining governance control and dumped against on-chain liquidity, and (b) 130,000 METRIC tokens drained from Build-controlled Balancer liquidity pools and dumped against METRIC's available liquidity. Approximately 0.5M tokens-worth of proceeds were routed to Tornado Cash by the attacker (Suho.eth ENS domain). The realised loss was bounded by the underlying liquidity profiles of BUILD and METRIC, not by the nominal mint authority the attacker had captured.
OAK Techniques observed
OAK-T16.002 (Hostile-Vote Treasury Drain — direct-market-accumulation sub-shape: attacker accumulated outsized BUILD voting power across multiple wallets, then submitted and passed a self-dealing proposal under a thin-cohort voting base) + OAK-T9.003 (Governance Attack — generic-class anchor) + OAK-T9.004 (Access-Control Misconfiguration — once the malicious proposal passed, the attacker held mint authority over BUILD, control of the governance contract, and admin keys over the Balancer pool LP positions held by the DAO) + OAK-T1.003 (onlyOwner / Proxy Rug — the malicious governance proposal granted the attacker the BUILD mint role; the attacker then minted 1.0–1.1M BUILD tokens from nothing and dumped them against on-chain liquidity, exercising the owner-privilege mint surface that the governance outcome had conferred) + OAK-T5.005 (Treasury-Management Exit — the on-chain framing of the resulting treasury egress, including the METRIC-pool drain). Adjacent: OAK-T15.005 (Operator Communication-Channel Takeover — the attacker disabled / silenced the Discord bot that would have alerted the broader holder cohort to the live proposal, deliberately suppressing the defender-side vote-mobilisation channel during the proposal's voting window). OAK-T7.001 (Mixer-Routed Hop — approximately 0.5M tokens'-worth of proceeds were routed to Tornado Cash).
Attribution
pseudonymous — attacker self-identified on-chain via the Suho.eth ENS domain; no real-world identity has been linked publicly. The attacker had been a Build Finance member prior to the takeover and used that standing to participate in pre-proposal community discussion before submitting the malicious proposal.
Key teaching point
Build Finance is the cleanest "DAO did exactly what it was designed to do" case on the Ethereum public record, complementing TSD March 2021 (examples/2021-03-true-seigniorage-dollar.md) on BSC. The case demonstrates that T16.002 is enabled not just by governance-design (quorum-vs-circulating-supply ratio) but also by governance-process failures — the attacker used standard, contract-enforced governance procedures and combined them with a deliberate communication-channel takeover (T15.005) to suppress the holder-cohort response. The case is also the cleanest worked example of a failed counter-proposal mechanism — the Compound Proposal 289 case (examples/2024-07-compound-vote-takeover.md) is the worked example of successful counter-proposal deployment in the timelock window; Build Finance is the worked example of what happens when no such operational capability exists.

Summary

Build Finance DAO was an Ethereum-based decentralised governance organisation that managed treasury funds and operated metric.exchange, a Balancer-based DEX. The DAO held its treasury in a combination of native BUILD tokens, METRIC tokens (the Metric protocol's separate governance token, where Build Finance was a major LP), and ETH. Voting power was computed against directly-held BUILD; the governance contract granted the holder of a passed proposal full administrative authority, including the BUILD mint role and admin control over the DAO-held Balancer pool positions.

In early February 2022, an attacker operating from the Suho.eth ENS domain accumulated BUILD across multiple wallets to a position large enough to single-handedly satisfy quorum and the approval threshold. On 2022-02-09, the attacker submitted a first governance proposal that the wider community recognised as malicious; the community voted it down. The attacker then transferred their BUILD position to a fresh address and re-submitted a substantively identical proposal. Crucially, in the window between the first and second submissions, the attacker disabled the Discord bot that the Build community used to surface new proposals — the defender-side vote-mobilisation channel was effectively silenced. The second proposal proceeded through its voting window with the in-favour vote concentrated at the attacker's wallet and the counter-vote thinned by the suppressed community alert. The proposal passed on 2022-02-10.

On proposal-execution, the attacker received the BUILD mint authority, governance-contract admin role, and administrative control over the DAO-held Balancer LP positions. The attacker minted 1.0–1.1 million BUILD tokens (approximately 21x of pre-event circulating supply) and dumped against BUILD/ETH liquidity; they then withdrew the DAO's METRIC tokens from the Balancer pool — approximately 130,000 METRIC — and dumped against METRIC's available liquidity. Combined realised proceeds were approximately $470,000–$490,000; approximately 0.5M tokens'-worth of the proceeds were routed to Tornado Cash. The Build Finance team formally acknowledged the takeover on 2022-02-14, framing it explicitly as a hostile governance takeover and documenting the disabled-Discord-bot communication-channel suppression as a load-bearing enabler.

The DAO did not recover. The Build Finance treasury was effectively zeroed; the BUILD token's market value collapsed; and although the Metric protocol (separate-but-affiliated; built on the same team's earlier work) continued to operate with its own governance token, Build Finance itself was abandoned over the following weeks. No bounty negotiation, no compensation pool, no operator-side response that recovered material funds.

Timeline (UTC)

When Event OAK ref
pre-2022-02-09 Build Finance DAO operating with standing governance contract: voting on directly-held BUILD; passed-proposal payload grants mint authority + Balancer-pool admin + governance-contract admin to caller (standing T9.003 / T16.002 surface)
pre-2022-02-09 (multi-week window) Attacker (Suho.eth) accumulates BUILD across multiple wallets to a position sufficient to satisfy quorum + approval threshold under thinned voting cohort T16.002 setup (direct-market-accumulation sub-shape)
2022-02-09 Attacker submits first governance proposal — community recognises it as malicious; the proposal is voted down (defender response — held by community alert capability still functioning)
2022-02-09 (post-failure) Attacker transfers BUILD position to a fresh address; disables Discord bot used to surface new proposals to the community T15.005 (Operator Communication-Channel Takeover — suppression of vote-mobilisation channel)
2022-02-09 to 2022-02-10 Attacker submits second proposal substantively identical to the first; voting window opens with the holder cohort largely unaware due to the disabled Discord alert T9.003 + T16.002 (proposal payload)
2022-02-10 Second proposal passes; in-favour vote concentrated at attacker's fresh wallet; counter-vote thinned T16.002 vote-passage
2022-02-10 (proposal execution) Attacker receives BUILD mint authority, governance-contract admin, Balancer-pool admin T9.004 (access-control surface, executed)
2022-02-10 to 2022-02-14 Attacker mints 1.0–1.1M BUILD; dumps against BUILD/ETH liquidity; withdraws and dumps 130,000 METRIC from DAO-controlled Balancer pools T16.002 extraction + T5.005 treasury-management exit
2022-02-10 to 2022-02-14 Approximately 0.5M tokens'-worth of proceeds routed to Tornado Cash T7.001 (mixer-routed hop)
2022-02-14 Build Finance team posts formal acknowledgement on Twitter framing the case as a hostile governance takeover and documenting the disabled-Discord-bot enabler (operator response — defender record)
weeks following Build Finance treasury effectively zeroed; BUILD token market value collapses; protocol abandoned (post-event collapse)

What defenders observed

  • Pre-event (governance-design layer): Build Finance's quorum threshold and approval threshold were both satisfiable from a single concentrated BUILD position under the prevailing thinned-cohort voting base. Like TSD (examples/2021-03-true-seigniorage-dollar.md) before it, the static quorum threshold did not adapt to the active-voting-cohort population dynamic — the threshold was set as a fraction of supply, not as a function of how many active voters were realistically going to participate in any given proposal. The mitigation surface here is identical to TSD's: quorum-floor-on-active-voters, or quorum computed as a fraction of meaningfully-active circulating supply rather than total supply.
  • Pre-event (cohort-surveillance layer): the attacker's multi-week BUILD accumulation across multiple wallets was on-chain visible in real time. Like TSD, no defender stack with cohort-surveillance instrumentation was watching. The Tally / Boardroom-class governance dashboards reached production maturity for top-tier Ethereum DAOs through 2022-2023, but smaller DAOs like Build Finance were not in the coverage scope.
  • At-event (governance-process layer — the deliberate first-proposal sacrifice): the attacker's two-proposal pattern (sacrificial first proposal that draws community attention, followed by a substantively-identical second proposal under suppressed-attention conditions) is a governance-process attack distinct from the underlying governance-design vulnerability. The first proposal served as a probe of the holder-cohort's defender capability; the second proposal exploited the same design under degraded defender conditions. Future T16.002 detection tooling should treat recently-failed proposal followed by substantively-identical re-submission as a high-confidence cohort-level signal.
  • At-event (T15.005 communication-channel takeover): the disabled Discord bot is a clean example of T15.005 in a non-standard form — typically T15.005 covers operator-side comms (Twitter, official Discord, governance-blog) being taken over by the attacker; here the attacker disabled the defender-side alerting channel without taking it over. The mechanism is the same (the holder cohort's situational awareness was degraded), but the defender mitigation differs: out-of-band alerting (governance-only Twitter account, on-chain proposal indexer with email / push delivery, multi-channel redundancy) closes the suppression vector that single-Discord-bot-alerting leaves open. The case is the v0.1 OAK reference for defender-side communication-channel suppression as a sub-shape of T15.005.
  • At-event (vote-distribution signal): the second proposal's in-favour vote concentrated at a single fresh wallet with on-chain history showing recent receipt of a large BUILD position from a different address — a clean cohort-level T8.001 (cluster-reuse) signature visible in real time. No defender stack was watching at the runtime layer.
  • Post-event (no recovery channel): the case follows the same post-event shape as TSD March 2021: protocol abandonment, no bounty, no compensation pool, no recovery negotiation. The realised $470K-$490K is small in absolute terms but represented near-100% of the recoverable Build Finance treasury, and the user-side outcome was total loss for remaining BUILD holders.

What this example tells contributors writing future Technique pages

  • T15.005 has a defender-side suppression sub-shape distinct from operator-side takeover. The standard T15.005 framing is operator comms taken over; Build Finance demonstrates a sub-shape where the attacker disables the defender-side alerting channel without taking it over. Worked T15.005 contributions should distinguish these two sub-shapes and document the mitigation-surface difference (out-of-band redundant alerting closes the suppression vector; operator-controlled-channel hardening closes the takeover vector).
  • The two-proposal probe-then-execute pattern is a recurring T16.002 governance-process anti-pattern. The first proposal serves to probe the defender cohort's response capability; the second proposal exploits the same design under degraded conditions. Worked T16.002 contributions should treat recently-failed proposal followed by substantively-identical re-submission under different proposing wallet as a cohort-level pre-execution signal.
  • Multi-token-treasury composition matters for the realised-loss measure. Build Finance held both BUILD (its own governance token; mint authority captured) and METRIC (a different governance token held as LP). The realised-loss calculation has to enumerate both, and the per-token monetisation-side liquidity profiles bound the attacker's realised proceeds independently. Future T16.002 / T5.005 contributions documenting multi-token treasuries should report per-token realised-loss figures rather than a single aggregate.
  • The TSD → Build Finance → Beanstalk → Mango Markets → Curio → Compound 289 chain is the canonical T16 worked-example sequence. TSD March 2021 (BSC, ESD-fork, hostile-vote, $16.6K) → Build Finance Feb 2022 (Ethereum, hostile-vote with comms-channel suppression, $0.5M) → Beanstalk April 2022 (Ethereum, T16.001 flash-loan vote, $76M) → Mango Markets Oct 2022 (Solana, T9.001 + T16.002 settlement vote, $47M retained) → Curio March 2024 (Ethereum, MakerDAO-fork, storage-collision-mediated T9.003, $1M realised) → Compound Proposal 289 July 2024 (Ethereum, prevented in timelock window, $0). The chain spans three chains, four sub-shapes (hostile-vote, flash-loan vote, settlement vote, storage-collision vote), and three loss-magnitude scales (sub-million, single-digit-million, eight-figure). Future T16-class contributions should situate each new case against this chain.

Public references

Citations

  • [buildfinanceannouncement2022] — Build Finance operator-side acknowledgement; canonical source for the hostile-takeover framing.
  • [decryptbuildfinance2022] — contemporaneous press; Suho.eth attribution and Discord-bot suppression.
  • [theblockbuildfinance2022] — contemporaneous press; loss figure.
  • [cryptoslatebuildfinance2022] — contemporaneous press; BUILD mint and METRIC drain figures.
  • [quadrigabuildfinance2022] — retrospective case-study summary.
  • [utodaybuildfinance2022] — contemporaneous press; Tornado Cash routing.
  • [zhou2023sok] — academic taxonomy entry.

Discussion

Build Finance February 2022 sits at the second slot in the canonical T16 worked-example chain — TSD March 2021 → Build Finance Feb 2022 → Beanstalk April 2022 → Mango Markets Oct 2022 → Curio March 2024 → Compound Proposal 289 July 2024 — and demonstrates the hostile-vote-with-communication-channel-suppression sub-shape on Ethereum, two months after TSD's BSC sub-million case and two months before Beanstalk's flash-loan-funded eight-figure case. The structural lesson is that T16.002 governance-process failures (suppressed defender alerting, two-proposal probe-then-execute patterns) compose with governance-design failures (static quorum vs thinned active-voter cohort) and are not closed by purely contract-layer mitigation. The same governance-design vulnerability that enabled TSD's mint-flooding produced Build Finance's mint-flooding-plus-Balancer-pool-drain because the governance-process layer (defender alerting via Discord bot) was a single point of failure that the attacker deliberately removed.

The realised loss ($470K–$490K) is small in absolute terms but represented near-100% of the recoverable Build Finance treasury. Like TSD, the attacker's realised ceiling was bounded by monetisation-side liquidity (BUILD/ETH and METRIC pools) rather than by the design ceiling (full mint authority would have allowed effectively unbounded nominal mint). The realised-vs-nominal-loss-gap observation that runs through the T16 chain (TSD: >10⁴×; Build Finance: ~21×; Beanstalk: ~2.4×; Mango Markets: notional inflation orthogonal; Curio: ~16×) is consistent with the broader observation that design-ceiling extraction is liquidity-bounded at the monetisation step, and the gap narrows for protocols with deeper post-mint liquidity profiles.

Attribution-strength is pseudonymous (not pseudonymous-unattributed) because the attacker self-identified on-chain via the Suho.eth ENS domain and had been a Build Finance community member prior to the attack. The case is between TSD (pseudonymous-unattributed) and Indexed Finance October 2021 (Andean Medjedovic, US-prosecutor-indicted, confirmed once the indictment becomes the operative attribution document) on the T16 attribution-strength spectrum. The cohort-level OAK observation that pseudonymous-unattributed T16.002 attackers tend to operate at smaller dollar-magnitude than named / indicted T16.002 attackers continues to hold — Build Finance's $0.5M sits between TSD's $16.6K and Mango Markets' $47M.

The disabled-Discord-bot enabler is the v0.1 OAK reference for defender-side communication-channel suppression as a sub-shape of T15.005 distinct from the standard operator-side communication-channel takeover shape. The mitigation surface differs: out-of-band redundant alerting (governance-only Twitter, on-chain proposal indexer with email / push delivery, multi-channel redundancy) closes the suppression vector. Future T15 / T16 contributions should distinguish these two T15.005 sub-shapes explicitly.

Techniques demonstrated (7)