DAO Governance Attacks: What 2020–2025 Incidents Teach Founders

A practical guide for executives designing or investing in DAOs: what went wrong in real incidents (2020–2025), how attackers actually moved money, and concrete engineering and process controls to prevent a repeat.

Summary: Governance is now a primary attack surface. From flash‑loan vote captures to malicious proposals and low‑turnout treasury drains, recent cases show repeatable patterns—and fixable design flaws.

Why this matters to decision‑makers

If your product or treasury will ever be controlled by token voting or a DAO, governance is production security—not a “community” nice‑to‑have. The most expensive recent failures weren’t reentrancy or bridge bugs; they were governance abuses that used allowed powers to do harmful things. The good news: modern Governor frameworks, time‑locks, optimistic execution, and voter‑engagement mechanics can materially reduce risk, fast. (docs.openzeppelin.com)

---

Attack patterns we keep seeing (and why they work)

• Flash‑loan vote capture: borrow voting power just long enough to pass an on‑chain proposal that pays the attacker, then repay. This works when voting power is measured at “now,” or when an emergency commit can bypass normal delays. (certik.com)
• Malicious “lookalike” proposals: clone a previously passed proposal but add a hidden function (self‑destruct or logic swap) that grants votes or drains treasuries after execution. Voters trust the description; the code differs. (theblock.co)
• Low‑engagement drains: in inactive DAOs, a single holder meets quorum with their own tokens, hiding a malicious payload among many benign proposals. (blockworks.co)
• Exchange/custody vote capture: custodians temporarily wield customer deposits to swing governance in delegated‑PoS systems, forcing contentious forks. (coindesk.com)
• “Governance as negotiation”: after an exploit, attackers push on‑chain votes that whitewash or pay them; low turnout and user pressure lead communities to approve controversial “settlements.” (theblock.co)
• Whale accumulation attacks: a small coalition buys/delegates enough tokens to pass a self‑serving treasury proposal during weekends/holidays when turnout is lowest. (theblock.co)

---

What the biggest cases taught us (2020–2025)

1) Steem 2020: exchange‑powered governance takeover -> community fork

In March 2020, major exchanges powered up customer STEEM and voted out Steem’s witnesses in favor of a Justin Sun–aligned account. The community countered by forking to Hive weeks later, a canonical example of how exchange custody can distort governance and force social recovery via forks. For founders: consider the risk of custodied supply in your voting model. (cointelegraph.com)

2) Build Finance (Feb 2022): hostile DAO takeover by quorum and mint

An attacker marshaled enough votes to gain control of the governance contract, minted 1.1M+ BUILD, seized treasury/LP positions, and effectively “rugged” the project—without a protocol bug, just governance design. Liquidity pools were drained and the token collapsed to near‑zero. This shows why proposal thresholds, graduated quorums, and guarded mint authorities matter. (cryptoslate.com)

3) Beanstalk (Apr 2022): $182M via flash‑loan majority + emergency commit

The exploiter borrowed roughly $1B, amassed a supermajority of governance power, and used an emergencyCommit pathway to pass BIP‑18 within ~24 hours, draining the protocol and laundering funds via Tornado Cash. Technically, the vote was “valid”—the design wasn’t flash‑loan resistant and the emergency path overrode normal delays. Fixes: vote snapshots from prior blocks, remove emergency shortcuts, and add time‑locks with veto/cancel powers. (coindesk.com)

4) Mirror (Dec 2021): spammed governance polls to drain community funds (thwarted)

Attackers flooded Mirror Protocol’s on‑chain governance with fake “security” polls designed to redirect tens of millions in MIR to attacker addresses. Community vigilance and warnings defeated them, but the attempt shows how proposal spam and confusing UX can be a direct treasury risk. (cointelegraph.com)

5) Synthetify (Oct 2023, Solana): 10 nearly identical proposals, one drains the treasury

With the DAO inactive, an attacker created ten look‑alike proposals; nine were benign, the tenth sent ~$230k to the attacker. By the time anyone noticed, funds had moved (some via Tornado Cash). Solana’s Anatoly Yakovenko summed it up: “Any DAO with pure token voting is just waiting to be attacked”—arguing for paid veto councils who actually watch proposals. Build monitoring and human failsafes. (blockworks.co)

6) Tornado Cash (May 2023): “identical” proposal with a twist hijacks governance

A malicious proposal imitated an earlier upgrade but with a hidden function; once passed, the attacker granted themselves ~1.2M fake votes, assumed full control, and withdrew governance assets. Days later, control was returned, but the incident is a precise blueprint for “proposal logic swap” attacks. Require full bytecode diffs and independent simulation reports before execution. (coindesk.com)

7) Indexed Finance DAO (Nov 2023): a $90K drain attempt defeated by attention

An attacker tried to pass a self‑paying proposal on a neglected DAO; only public scrutiny and quick mobilization killed it. Lesson: even “dead” DAOs with residual treasuries are targets—set wind‑down safeguards and spending caps if you mothball governance. (blockworks.co)

8) Mango Markets (Oct 2022–2025): exploit -> DAO “settlement” -> courtroom

After a market‑manipulation exploit drained >$100M, the exploiter proposed a governance “deal” to return part of the funds if allowed to keep ~$47M and avoid legal action; Mango token holders approved, then the DAO sought to unwind the deal in court. Legal proceedings have continued into 2025, underscoring that “code‑is‑law” settlements can collide with real‑world law. Don’t rely on ad‑hoc crisis votes to paper over missing controls. (theblock.co)

9) Compound (July 2024): weekend whale vote, proposal later withdrawn under pressure

“Proposal 289” aimed to move 499k COMP ($24–25M) from the treasury to an externally controlled vault; it passed by a razor‑thin margin after a small group amassed votes. Security advisors publicly labeled it a governance attack; the proposer agreed to cancel and pursue a different staking design. The DAO later moved to upgrade governance contracts to modern OpenZeppelin Governor, adding stronger safety features. Build in the guardrails before your treasury becomes tempting. (theblock.co)

---

The root causes (recurring design and process gaps)

• Voting power measured “now”: enables flash‑loan voting. Use historical checkpoints (ERC‑20 Votes) so voting power is from a previous block/timepoint. (docs.openzeppelin.com)
• Emergency execution paths: “emergencyCommit” or similar bypasses. These need separate, tightly scoped authority or multi‑party guardianship—and a higher quorum. (certik.com)
• No timelock or weak queueing: if execution can follow immediately after a vote, there’s no time to review payloads. Tie execution to a Timelock controller. (docs.openzeppelin.com)
• Unbounded treasuries under single‑chamber token voting: creates weekend‑raid incentives. Consider bicameral checks or emergency vetoes with transparent scope and sunset. (blockworks.co)
• Poor proposal hygiene: no mandatory code diff, no simulation report, ambiguous descriptions. This is how “lookalike” payloads slip through. (theblock.co)
• Chronic voter apathy: low quorum + easily acquirable tokens = capture risk. Design incentives and thresholds to make attacks uneconomic. (theblock.co)

---

What to implement now: engineering controls that work

These controls are battle‑tested in modern governance stacks; we deploy them by default in new DAO builds.

1. Use snapshot‑based voting power and anti‑flash‑loan mechanics

• Adopt OpenZeppelin Governor with ERC‑20 Votes checkpoints so voting power is measured at a past block; combine with a votingDelay to lock in the snapshot before voting starts. (docs.openzeppelin.com)

1. Mandate timelocks on all successful proposals

• Execute via a Timelock controller, not directly from the Governor. Add a minimum delay to review/contest proposals; reserve only tightly scoped, multisig‑controlled emergency powers. (docs.openzeppelin.com)

1. Prevent last‑minute quorum sniping

• Enable GovernorPreventLateQuorum so passing a quorum near the deadline automatically extends voting, giving the community time to react. (docs.openzeppelin.com)

1. Graduated quorums and proposal thresholds

• Set higher quorum and super‑majority for treasury transfers, token mints, or parameter changes; require a meaningful proposalThreshold so only credible holders can propose. (docs.openzeppelin.com)

1. Bicameral or delegated checks

• Pair token voting with a limited‑scope guardian/council that can cancel only on enumerated grounds (e.g., payload mismatch, missing diff/sim, or out‑of‑scope spending). This cuts “lookalike” and weekend drains without reverting to centralized control. (docs.openzeppelin.com)

1. Hard‑limit treasury blast radius

• Separate “core protocol” governance from treasury disbursements. Route spending through a Safe with daily/weekly spend caps, require multi‑tx (two‑phase) approvals, and maintain hot/warm/cold treasuries. For Snapshot‑based DAOs, use UMA’s oSnap to execute off‑chain votes with on‑chain challenge periods and bonds. (docs.uma.xyz)

1. Require payload transparency and simulation

• Ship a “proposal packet”: human‑readable spec, bytecode diff against prior proposals, and third‑party simulation output (Tenderly or equivalent). Block execution if the posted calldata hash doesn’t match the reviewed payload. (theblock.co)

1. Adopt ve‑style or non‑transferable voting for sensitive controls

• veToken models (e.g., veCRV) require time‑locked, non‑transferable voting power—materially reducing borrowability and flash‑attacks. Consider lockups for any vote that can move funds. (curve.readthedocs.io)

1. Monitoring and alerting as first‑class features

• Run bots that watch for: identical‑looking proposal spam, execution calls outside normal windows, or governance actions that exceed preset budgets. Public dashboards help mobilize voters in hours, not days. The Synthetify and Indexed attempts show attention alone can stop a theft. (blockworks.co)

1. Custody‑aware governance

• Track exchange/custody concentrations; consider excluding custodied balances from certain votes, or require longer holding periods to gain voting rights. The Steem/Hive split is a cautionary tale. (coindesk.com)

---

Emerging practices we recommend in 2025 builds

• Optimistic execution with a challenge window: UMA’s oSnap v2 automates Snapshot -> on‑chain execution but gives anyone the ability to dispute invalid proposals by posting a bond; disputed proposals get deleted. It’s fast when honest, and stoppable when not. (medium.com)
• “Seatbelts” for governance: pre‑commit to kill‑switch criteria that are objective (payload mismatch, out‑of‑budget spend, missing simulation), with transparent roles and audit trails. OpenZeppelin’s latest Governor extensions (e.g., ProposalGuardian, PreventLateQuorum, SuperQuorum) are built for this. (docs.openzeppelin.com)
• Proactive framework upgrades: Compound’s 2025 plan to migrate to modern OpenZeppelin Governor, with proposal moratorium during the cutover, is the right pattern—upgrade before the treasury size attracts coordinated governance capture. (comp.xyz)
• Human‑in‑the‑loop attention: Yakovenko’s point applies to EVM DAOs too—pay a small committee to monitor proposals and publish “go/no‑go” reports during voting. Cheap insurance. (blockworks.co)

---

A 12‑point “ship checklist” for founders and enterprise sponsors

Before you put a dollar under DAO control:

1. Governance framework: OpenZeppelin Governor with ERC‑20 Votes checkpoints, votingDelay, votingPeriod set for your holder profile. (docs.openzeppelin.com)
2. Execution path: Timelock enforced; no direct Governor execution for sensitive calls. (docs.openzeppelin.com)
3. Quorum tiers: higher super‑quorum for treasury/mint/parameter changes. (docs.openzeppelin.com)
4. Proposal thresholds: set at a % of total supply or ve‑power; restrict who can propose. (docs.tally.xyz)
5. Anti‑sniping: PreventLateQuorum enabled. (docs.openzeppelin.com)
6. Emergency powers: limited ProposalGuardian cancel on enumerated, objective criteria; sunset and audits. (docs.openzeppelin.com)
7. Treasury segmentation: Safe‑based hot/warm/cold with spend caps; oSnap for Snapshot DAOs. (docs.uma.xyz)
8. Payload hygiene: require code diffs, calldata hash pinning, and third‑party simulation attached to every proposal. (theblock.co)
9. Vote lockups: ve‑style locks (non‑transferable power) for proposals that move funds. (curve.readthedocs.io)
10. Monitoring: public bots that flag suspicious proposals, weekend votes, or multi‑proposal spam. (blockworks.co)
11. Custody exposure: track exchange holdings; consider warm‑up periods to vote. (coindesk.com)
12. Upgrade plan: schedule quarterly governance audits and framework updates; moratorium windows during upgrades. (comp.xyz)

---

If you already run a DAO: a 30‑day hardening plan

Week 1

• Enable PreventLateQuorum and increase votingDelay to create a robust snapshot; raise proposalThreshold for treasury actions. (docs.openzeppelin.com)

Week 2

• Move execution to a Timelock (if not already); publish an emergency cancel policy with objective criteria; add a small, elected guardian committee with limited scope. (docs.openzeppelin.com)

Week 3

• Implement oSnap (if Snapshot‑based) with a non‑trivial bond and 72h challenge window; route high‑value transactions through Safe with spend caps. (docs.uma.xyz)

Week 4

• Adopt a “proposal packet” requirement (diff + simulation report); stand up monitoring bots and a public “voter alert” channel; schedule a tabletop exercise of a malicious‑proposal scenario.

---

Key takeaways for executives

• Governance is an attack vector, not a community ritual. Every dollar the DAO can touch is a dollar an attacker will design a vote to take.
• Incidents are repeatable patterns with known fixes: checkpointed voting power, enforced time‑locks, higher quorums for money moves, payload transparency, and automated challenge windows. (docs.openzeppelin.com)
• Social layers matter: when turnout is low, whales and coalition buyers can win narrow weekend votes. Pay for attention and publish clear “stop rules.” (theblock.co)

---

Appendix: incident quick refs (for your board packet)

• Beanstalk (Apr 17, 2022): ~$182M loss via flash‑loan supermajority + emergencyCommit BIP‑18; code‑is‑law, design wasn’t flash‑loan resistant. (coindesk.com)
• Tornado Cash (May 20, 2023): lookalike proposal + hidden logic grants ~1.2M fake votes; attacker returns control days later. (coindesk.com)
• Synthetify (Oct 24, 2023): 10 similar proposals; one drains ~$230k; underscores inactivity risk; public callouts recommended veto councils. (blockworks.co)
• Build Finance (Feb 14, 2022): hostile takeover via governance; mint authority abused; LPs and treasury drained. (cryptoslate.com)
• Mango (Oct 2022): exploit + on‑chain “settlement” kept ~$47M; later litigated in U.S. courts—on‑chain votes don’t preempt legal risk. (theblock.co)
• Compound (July 2024): Proposal 289 (≈$24M) passes narrowly amid governance‑attack allegations; later withdrawn; DAO plans Governor upgrades. (theblock.co)

If you want a tailored governance threat model, we can map your token distribution, voting stack, and treasury flows against these attack classes and ship a hardened configuration with monitoring in under four weeks.