Governance attacks can drain treasuries without a code exploit

At a glance

What this is: Hypernative’s case study shows that DAO treasury theft can happen through legitimate governance flows, not just code flaws, when an attacker can buy enough voting power and execute immediately after approval.

Why it matters: This matters because IAM and treasury governance teams have to treat proposal authorization, execution timing, and monitoring as part of the control plane for digital assets, not as separate concerns.

By the numbers:

• The attacker walked away with an estimated $20.5M from Bonk DAO's treasury.
• The attacker acquired approximately 882.3 billion BONK, about 1.003% of supply.
• Reserve's hyUSD proposal was stopped within 24 hours.

Context

DAO governance is only as strong as the gap between approval and execution. If a treasury can move value immediately after a vote passes, governance becomes the last line of control rather than a meaningful gate, especially when an attacker can accumulate just enough voting power to cross the threshold. Non-Human Identities are not the main issue here, but the same governance principle applies: authority must be bounded by lifecycle and timing controls, not assumed to be safe because it is legitimate.

The article’s central finding is that the control failure was procedural, not cryptographic. A passed vote became sufficient authorization on its own, which left no delay, no secondary review, and no monitoring trigger between approval and transfer. That is atypical only if a DAO has already built friction into its governance model; otherwise, it is a predictable failure mode.

Key questions

Q: What breaks when a DAO governance vote can execute treasury transfers immediately?

A: A governance vote becomes equivalent to full authorization when no delay or second check exists between approval and execution. That lets an attacker convert voting power into asset movement as designed, which is why the control failure is procedural rather than technical. The remedy is to separate approval from execution so defenders have a window to intervene.

Q: Why do low-turnout governance systems create treasury risk?

A: Low turnout makes approval thresholds cheaper to buy because the attacker needs only enough voting power to cross the line, not broad community support. When a proposal can pass with minimal participation, the governance threshold may look strong on paper but function as a purchaseable control in practice. Security teams should test thresholds against adversarial turnout, not normal conditions.

Q: What are the signs that a governance proposal is malicious?

A: Watch for treasury transfers, contract upgrades, or role changes bundled into proposals that lack prior discussion, target unfamiliar destinations, or appear in a dormant governance process. Those signals do not prove malice on their own, but they are the right triggers for investigation before finalization. Monitoring should focus on privileged intent, not just proposal count.

Q: Should treasuries use timelocks, quorum rules, or monitoring first?

A: Use all three, but prioritise timelocks and monitoring first because they create the response window that quorum rules alone do not provide. Quorum can be bought if turnout is low, while timelocks and alerting give defenders time to challenge a malicious proposal before assets move. Governance security is strongest when authority, timing, and visibility work together.

Technical breakdown

How token-weighted governance becomes an attack path

Token-weighted DAO governance turns voting power into transactional authority. If a proposal can carry treasury-transfer instructions and the approval threshold is low enough, an attacker can buy just enough tokens to cross the line, submit a proposal, vote it through, and let the system execute the transfer as designed. The attack does not require code exploitation because the governance contract is behaving normally. The weakness is that legitimacy is inferred from the vote alone, even when turnout is low and the proposal is adversarial. Practical implication: model proposal approval as an access decision, not just a community process. See the Vulnerability Management Guide.

Practical implication: Treat governance approvals that can move funds as privileged actions and require additional policy gates before execution.

Why execution timelocks matter more than most treasuries assume

A timelock inserts a delay between approval and execution so that a community, security team, or automated monitor can react before funds move. Without that delay, approval and transfer collapse into one continuous control step, which means the attacker only needs one successful vote window. In Bonk DAO, no execution timelock stood between the vote and the treasury transfer, so finalization immediately became loss. Timelocks do not stop a bad proposal from passing, but they create a response window that changes the economics of the attack. Practical implication: place a mandatory delay on any governance action that can move treasury assets or change privileged roles.

Practical implication: Use a timelock on high-impact governance actions so monitoring and response can interrupt malicious approvals.

How governance monitoring detects malicious proposals before funds move

Governance monitoring looks for the difference between routine proposals and proposals that request privileged actions such as contract upgrades, role changes, or treasury transfers to unfamiliar destinations. The useful signal is not simply that a proposal is dangerous in the abstract, but that the destination, code path, or action history is unusual compared with normal governance behaviour. In Reserve’s case, the same pattern was caught because the new implementation address had no history and no forum discussion behind it. That kind of monitoring turns governance from a blind vote tally into a control surface. Practical implication: alert on privileged actions and unknown destinations, not on proposal volume alone.

Practical implication: Monitor governance proposals for privileged actions and unfamiliar destinations before finalization occurs.

Threat narrative

Attacker objective: The attacker’s objective was to use Bonk DAO’s own governance process to transfer treasury assets to an attacker-controlled wallet and recover the voting stake after execution.

1. Entry occurred when the attacker acquired enough BONK to cross Bonk DAO’s approval threshold and create a legitimate-looking governance proposal.
2. Escalation happened when the attacker secured the decisive vote and converted governance weight into authority over treasury movement.
3. Impact followed immediately after finalization because no execution timelock or secondary check stood between approval and transfer, allowing roughly 4.43T BONK to leave the treasury.

Breaches seen in the wild

• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Governance is now an access-control problem for treasuries. Once a proposal can move assets without additional checks, the vote itself becomes a privileged action rather than a deliberative signal. That shifts the control question from code correctness to authority boundaries, timing, and approval context. Treasury teams should treat governance parameters as part of access governance, not as an administrative detail.

Low-turnout governance creates a standing threshold illusion. A quorum expressed as a percentage of supply looks protective until an attacker can cheaply buy the missing slice of voting power. The article shows that a threshold without participation assumptions can collapse into a purchaseable control, which is why governance design must account for adversarial turnout, not average community behaviour. Practitioners should test whether approval thresholds are actually resilient under attack conditions.

Token-weighted governance needs monitoring that understands privileged intent. The useful signal is not merely that a proposal exists, but that it proposes treasury movement, contract replacement, or role changes to a destination with no normal history. That is where security teams should focus detection logic, escalation rules, and community notification paths. Without that layer, a DAO can remain formally governed and still be operationally undefended.

The Reserve near-miss and Bonk loss are the same pattern at different speeds. One governance proposal was detected, challenged, and reversed within 24 hours; the other sat long enough to complete. The difference was not the sophistication of the attacker, but whether governance monitoring and community response created a usable intervention window. Practitioners should measure how much time their governance model actually gives defenders.

Smart contract audits do not cover maliciously valid governance. The article makes the boundary explicit: the code did exactly what it was told to do, which means the failure mode sits above the contract layer. That is why governance security, monitoring, and execution friction have to be treated as first-class controls in digital asset programmes. Teams should map governance risk as a separate control domain, not as an audit afterthought.

What this signals

Governance attack windows are now the practical metric. Teams should stop measuring governance safety only by whether a proposal passed and start measuring how much time exists between approval and asset movement. That window determines whether humans or automation can still intervene before value leaves the treasury.

Threshold design has to assume adversarial participation. A quorum that depends on normal community turnout is not a control if an attacker can cheaply assemble the missing vote share. Governance programmes should be tested against the cheapest plausible path to approval, not the expected path.

Execution friction belongs in digital asset governance. The article shows that a simple delay can change the outcome from irreversible loss to coordinated response. Programmes that manage treasuries, protocol parameters, or privileged roles should treat delay, alerting, and review as operational controls, not optional extras.

For practitioners

• Harden treasury proposals with execution delays Require a timelock between proposal approval and treasury movement for any action that can transfer funds or change privileged roles.
• Raise the approval bar for high-impact votes Revisit quorum and approval thresholds so an attacker cannot cheaply buy the missing voting power on a low-participation proposal.
• Alert on privileged governance actions Configure monitoring to flag treasury transfers, contract upgrades, and role changes when they appear in proposals, especially if the destination is unfamiliar.
• Build a rapid challenge path for suspicious proposals Define who must review, where the alert goes, and how quickly the community can coordinate before execution completes.
• Treat governance parameters as security controls Document approval thresholds, execution delays, and emergency intervention steps as part of the treasury’s access governance model.

Key takeaways

• The core failure was not a code exploit but a governance design that let a passed vote become immediate asset movement.
• The attacker spent roughly $4M in BONK and walked away with an estimated $20.5M, which shows how cheap threshold purchase can become compared with treasury value.
• A timelock and privileged-action monitoring are the controls most directly tied to stopping this pattern before funds leave the treasury.

Related NHI Mgmt Group resources: Guide to NHI Rotation Challenges · Guide to the Secret Sprawl Challenge · Ultimate Guide to NHIs: What are Non-Human Identities · Internet Archive breach 2024

Key terms

• Governance Attack: A Governance Attack is a hostile attempt to capture or manipulate a protocol’s decision-making process. Attackers use stolen voting power, borrowed tokens, bribery, or proposal abuse to change rules or drain treasuries. Defenders should monitor quorum thresholds, voting concentration, timelocks, and privileged proposal paths.
• Execution Timelock: An execution timelock is a delay between approval and action that creates time for review, alerting, and intervention. In treasury governance, it separates a passed vote from an irreversible transfer, making it much harder for attackers to complete a malicious proposal without detection.
• Threshold Purchaseability: Threshold purchaseability is the condition where an attacker can buy or assemble enough voting power to meet a governance threshold at acceptable cost. It turns nominal community approval rules into a transactional risk, especially when turnout is low and the value under control is high.
• Privileged Action: A privileged action is a sensitive operation that can change data, configuration, access, or control inside an environment. In modern PAM, the action matters more than the account label because the same identity may be harmless in one context and high risk in another.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.