Knowledge base
HomeCapersWiki homeEssays
How Caper worksFoundationsRaising & marketsGovernanceEditorial policyHelpGeneral referenceDAOsDAO governance & toolingDecentralized scienceEconomics
  1. Wiki
  2. /
  3. DAO governance & tooling
  4. /
  5. Concepts
  6. /
  7. Analysis, security & standards
  8. /
  9. DAO security and governance attacks

PreviousDAO procurement and requests for proposalsNextDAO service providers
MANIFESTO · CAPER / OWN THE GAME
An organization that raises and deploys its own capital. A market that never closes. Governance that can't be captured.
TermsPrivacy
Σ TVL:√3M|24H VOL:√0|CAPERS:14
LAUNCHGOVERN

A DAO governance attack is any manoeuvre that turns a decentralized organization's own decision-making machinery against it — capturing enough voting power, or exploiting the code that counts it, to pass a proposal the community never wanted, usually to drain the treasury. Because a DAO holds its funds in a public smart contract steered by a vote rather than by trusted officers, its governance is its attack surface: anyone who can acquire, borrow, or manufacture voting weight is a candidate attacker, and the contract executes the result without a referee. This page catalogs the recurring attack families with their landmark case studies, then the defenses that have become standard practice.

Why DAOs are uniquely exposed

Three properties that make DAOs attractive also make them fragile. Their treasuries are large and transparent — a would-be attacker can read the exact prize on-chain. Their control rule is mechanical — a proposal that clears the threshold executes automatically, with no board to say "this is obviously theft." And voting power is usually a liquid, purchasable token — the same tradability that bootstraps a community lets an outsider buy or rent influence on the open market. As a16z crypto puts it, a governance token is not just a coordination tool but "an attack vector" the moment its market price of control falls below the value it controls.

The attack taxonomy

Flash-loan vote seizure. The fastest attack borrows the voting power outright. In the April 2022 Beanstalk exploit, an attacker flash-borrowed more than $1 billion in stablecoins, converted it to a super-majority of Beanstalk's governance token, and used the protocol's emergencyCommit function to instantly pass a proposal (BIP-18) that transferred roughly $182 million of reserves to their own wallet — all inside a single transaction, netting about $76 million after repaying the loan (Halborn analysis). The enabling flaw was the absence of a meaningful execution delay: voting power that exists for one block should never be able to move funds in that same block.

Open-market or custodial token acquisition. A patient attacker simply buys control. When Justin Sun acquired Steemit in 2020, the community moved to freeze his stake; Sun allegedly used exchange-custodied user tokens from Binance, Huobi and Poloniex to out-vote the existing witnesses, and the community forked away to Hive in response. This social fork — abandoning a captured chain for an honest copy — is the ultimate backstop against a majority that cannot be out-voted, and EigenLayer's EIGEN token turns it into an explicit on-chain mechanism, forking to slash a colluding majority without assuming an honest one. The 2024 Compound "Golden Boys" episode was a subtler variant: a group led by "Humpy" accumulated COMP on the open market and narrowly passed Proposal 289, directing 499,000 COMP (~$24 million) into a yield vault under their influence, over the objections of core delegates — before public pressure forced them to rescind it. It showed that a bare majority, lawfully acquired, can still be a capture.

Slow Sybil accumulation. The quietest attack spreads a growing position across many anonymous wallets that behave like ordinary holders, avoiding the alarm a single whale would trigger, until the aggregate crosses a decision threshold. It is hard to detect precisely because each account looks legitimate, and it targets the same weakness as a low-turnout raid: when most holders are apathetic, a modest coordinated minority can decide a vote.

Oracle manipulation feeding governance. In the October 2022 Mango Markets exploit, Avraham Eisenberg manipulated the price oracle for the MNGO token to drain roughly $117 million, then used the MNGO he still held to vote through a governance proposal letting him keep about $47 million as a "bug bounty" and seeking immunity — laundering a market exploit through the DAO's own ballot. (A jury convicted Eisenberg in 2024; a federal judge overturned the convictions in 2026, a reminder that the legal status of these attacks is still unsettled.)

A payload that does not match its description. Where the frameworks above execute raw calldata, a proposal's title and its effect are separate objects, and only the title is read. Tornado Cash lost governance control of itself in May 2023 to a proposal presented as a copy of an earlier approved one; per Halborn's analysis the deployed contract carried extra self-destruct logic, and after the vote passed the attacker destroyed it, redeployed different code at the same address, and minted themselves 1.2 million votes against roughly 70,000 legitimate ones — draining about 483,000 TORN (~$2.17 million). No voting rule was broken. The gap it exploited is structural to arbitrary proposal execution, and no quorum or threshold setting can close it.

Code exploits of the governance contract itself. The original cautionary tale is The DAO (2016): not a vote-capture at all but a reentrancy bug in the withdrawal logic that let an attacker recursively drain about 3.6 million ETH (~$60 million then), an event so large it split Ethereum into ETH and Ethereum Classic. It is the permanent reminder that the safest governance rule is still only as safe as the contract implementing it.

Case study: BonkDAO, July 2026 — buying the quorum

The BonkDAO attack is the cleanest recent demonstration that the three defenses below are load-bearing, because it succeeded on a treasury protected by none of them. On 30 June 2026 an anonymous wallet filed BIP #76, titled "Sowellian BonkDAO" and presented as a governance-renewal plan, to the DAO's Realms instance on Solana. The operative clause instructed the treasury to send 4.43 trillion BONK — the bulk of it — to a wallet the proposer controlled, and it sat in public view for six days while no organized opposition formed (crypto.news).

Over 4–5 July the attacker bought just over 1% of the BONK supply — roughly 882 billion tokens for about $4.4 million, sourced on Bybit and Binance and part-funded by borrowing against DeFi collateral. That figure was not arbitrary: BonkDAO's quorum was set at 1% of supply, or 879.95 billion BONK, so the purchase was sized to clear the participation floor and nothing more. The final tally was 882.38 billion in favour against a 879.95 billion threshold — quorum cleared by about 0.3% — with the attacker holding roughly 99.878% of the votes cast (CoinDesk, Halborn).

The proposal passed on 6 July 2026 and executed immediately — Realms runs a passed instruction with no mandatory delay, so there was no window in which anyone could have cancelled it. Around $20 million left the treasury; roughly $188,000 was moved to an exchange within nine hours and about $19 million was parked in a "BONK 2.0" multisig with three attacker-linked signers. BonkDAO confirmed the attack publicly and said it was working with exchanges, the Solana Foundation, bridges and law enforcement on recovery.

Three ordinary design choices compounded into the loss. Quorum was a ceiling, not a floor. A 1% participation threshold in a DAO where turnout runs near 1% means the quorum figure is the electorate: buying it outright bought the outcome. Turnout made the raid cheap. Seven wallets voted out of more than 18,000 members — a turnout of about 2.9% — so the attacker never had to out-vote the community, only to out-vote the handful who showed up (see voter apathy). And execution was instant. A timelock would not have stopped the vote, but it would have converted a six-day-old public proposal into a cancellable one. Priced against the a16z framing above, control of the treasury cost about 22 cents for every dollar taken — which is the whole of the attack in one number.

The wave BonkDAO belonged to

BonkDAO read as a singular event at the time, and it was not. Blockaid's threat intelligence, published 18 August 2026, counted at least seven governance takeovers across three chains between 9 June and 6 August 2026, for combined losses of roughly $22 million, against DAO tooling, memecoin treasuries and DeFi protocols on Ethereum, Solana and Base. BonkDAO was the largest of them by more than a factor of ten and the least technically interesting; two of the others extend the taxonomy above.

Token of Power (Ethereum, 9 June 2026, about $1.59 million) was an Aragon-based governance token with a total supply of 16,384 units, which made a majority cheap to assemble outright. The attacker acquired just over half of it, then created, passed and executed a proposal inside a single transaction – no snapshot, no delay – minting 10 billion new tokens to themselves and selling them into a Balancer pool. It is the Beanstalk pattern with the flash loan removed: where the supply is small enough, an attacker does not need to borrow a majority, only to buy one.

BarnBridge SMART Yield (Ethereum, 15 July 2026, about $776,000) is the incident that adds a family. The protocol's governance was effectively abandoned but still held authority over the SMART Yield controller, so a proposal presented as a routine proxy upgrade swapped that controller for a contract the attacker controlled (BlockSec). The loss then came from nowhere near the treasury: it came out of roughly fifty users' own wallets, through ERC-20 approvals they had granted the BarnBridge contracts years earlier and never revoked, which the hijacked upgrade path could draw against without a single new signature. A governance takeover's blast radius is not bounded by the treasury. Wherever governance can reach an upgradeable contract, it can reach everything still approved to that contract – which makes a dormant DAO with live approvals more exposed than an active one, not less. The remaining two named in the cohort, Panther (a passing vote reaching the protocol's upgrade rights) and Unicly (voting power flash-borrowed for a single block), fall inside the families already described.

The shared causes across the seven are the ones this page names one at a time: a majority priced below what it unlocks, no delay between a proposal passing and executing, and mint, treasury and upgrade authority wired directly to a single vote. That is the case for reading the defenses below as a layered set rather than a menu. Blockaid's own recommendations are stated as classes and not as numbers – count voting power from a past block, put a real execution timelock with an emergency cancel in front of every privileged action, and keep the most dangerous powers behind controls a single proposal cannot clear – so any specific quorum or delay figure has to come from a protocol's own documentation rather than from the incident report.

Defenses that became standard

No single control is sufficient; mature DAOs layer several, and the widely-used OpenZeppelin Governor framework ships most of them by default.

  • Timelocks / execution delay. A mandatory delay between a vote passing and the action executing gives holders time to see a malicious proposal and react — the single control whose absence made Beanstalk possible.
  • Voting-power snapshots. Counting each voter's weight as of a past block (the proposal's creation) rather than live means tokens borrowed after a proposal is filed carry no weight — the standard structural answer to flash-loan seizure.
  • Proposal thresholds and quorum. Requiring a minimum stake to submit a proposal, and minimum participation for one to count, raises the cost of spam and low-turnout raids.
  • Guardian vetoes and security councils. A trusted multisig or elected council that can cancel a clearly-malicious proposal within the timelock window — as Nouns and others use — trades a little decentralization for a circuit-breaker.
  • Limiting governance scope. The most robust defense is architectural: if governance simply cannot express "transfer all reserves to this address," the most valuable attack has no proposal to ride. Restricting what a vote is allowed to do shrinks the attack surface more than any amount of vote-counting cleverness.

For a fuller academic treatment, see the 2025 survey on DAO governance attacks and defenses.

How Caper approaches this

A caper is built so that several of these defenses are structural rather than optional. Governance scope is bounded by construction: a proposal's executive option is one of five typed kinds – PAYOUT, INVEST, DIVEST, METADATA and UPGRADE – each with fixed fields the contract reads back itself, so there is no "call this arbitrary contract and drain the vault" proposal to ride: the single most valuable attack simply cannot be expressed. The one kind that can change what the others do, UPGRADE, swaps the platform's logic tier and is reserved for the $CAPER caper alone; it cannot be raised inside the caper whose treasury an attacker is after, and it lands only through the same delay and two-phase activation as everything else. Voting weight is the product of a member's stake and their earned, non-transferable participation tokens (minted one per vote and locked to the account), so a stack of governance tokens that just arrived — flash-borrowed or freshly bought — carries little to no weight until it has actually shown up over time, which capital cannot fake. Passing an executive proposal needs a ranked-choice super-majority, not a bare 50%, and execution only fires after the market window the trigger opens, in which any holder can veto by selling. And because every member who has voted or traded can exit for a treasury share sized by that same participation-weighted vote weight, even a captured vote cannot seize the value the participating members are entitled to redeem – the same vote-token balance that earns weight is what the exit requires, so the members with the most to lose to a capture are exactly the ones who can leave with their share. The exact mechanics are verified against the caper contract and described on the linked proposal and voting pages.

Part of a series onWhat is a DAO?
TopicHow DAOs get attacked through their own governance, and how they defend
Core riskA public, contract-enforced treasury steered by a vote anyone can try to acquire, borrow, or fake
Attack familiesFlash-loan vote seizure · open-market / custodial token acquisition · slow Sybil accumulation · oracle-manipulation-then-governance · code exploits
Landmark casesThe DAO (2016) · Beanstalk (~$182M, 2022) · Steem / Justin Sun (2020) · Mango Markets (~$117M, 2022) · Compound Prop 289 (2024) · BonkDAO (~$20M, 2026)
Core defensesTimelocks · voting-power snapshots · proposal thresholds & quorum · guardian vetoes · limiting governance scope
RelatedGovernance models, Treasury management, What is a DAO?