Governance Attack

What is a governance attack, and how does it differ from what people typically think of as a hacking attack?

A governance attack refers to an attacker using a decentralized autonomous organization's (DAO) voting mechanism itself as the attack tool — after obtaining a sufficient amount of governance tokens, submitting and passing a proposal that looks legitimate on the surface but is substantively harmful to the protocol, such as transferring the protocol treasury's funds to an address the attacker controls, or modifying core parameters to let the attacker bypass normal security checks. Because the entire process follows the protocol's designed governance procedure exactly, from a technical standpoint this isn't 'cracking' any security vulnerability — it's 'legitimately' exploiting the governance mechanism itself.

The key difference from what's typically thought of as a hacking attack lies in the 'attack path': most hacking attacks exploit a technical flaw in the smart contract code (such as the reentrancy attack or oracle manipulation covered in earlier articles), essentially bypassing or deceiving the system's security mechanism; a governance attack, by contrast, doesn't need to bypass any technical defense line at all — the attacker openly achieves their goal through the protocol's own designed voting process, to some extent 'attacking the rules using a flaw in the rules themselves,' rather than attacking a flaw in the code. This is also why a governance attack is often considered a particularly hard risk type to guard against through traditional code auditing.

Why do governance attacks happen, and why does a flash loan make this type of attack particularly easy to execute?

Most DAO governance designs originally assumed governance token holdings would be relatively distributed, making it hard for any single participant to obtain a vote-swinging amount within a short time — this assumption roughly held true early in a protocol's launch when token distribution was genuinely relatively spread out. But this design had a hidden premise that wasn't sufficiently considered: if the governance token itself has enough liquidity available for borrowing on the open market, an attacker theoretically doesn't need to genuinely 'hold' these tokens for very long — they just need control at the exact moment of voting.

The emergence of the flash loan turned this vulnerability from a theoretical risk into a practically viable attack technique: an attacker can, within a single transaction, borrow a massive amount of governance tokens via a flash loan, use these tokens to vote through a malicious proposal, execute the profit the proposal brings (such as transferring treasury funds), and then repay the borrowed tokens — the entire process requires no long-term capital preparation from the attacker, nor bearing any token price volatility risk. This is also why most protocols, after experiencing a similar attack incident, began re-examining their own governance mechanism design — such as adding a token lockup time requirement before voting (which is precisely the veToken model covered on this site), fundamentally ruling out the possibility of instantly borrowing for voting power.

How does a governance attack actually get executed, and what does one complete attack flow look like?

A typical flash-loan-style governance attack flow involves several steps:

1. Finding a target: the attacker looks for a protocol whose governance token itself has sufficiently deep on-chain liquidity (enough to be borrowed in bulk via a flash loan), and whose governance mechanism has no pre-voting lockup period or time delay set
2. Submitting a malicious proposal: the attacker might have pre-prepared a proposal that looks normal on the surface but is substantively harmful to the protocol (such as 'adjust treasury fund allocation strategy,' with the actual content transferring funds to the attacker's address), or launch an attack targeting an already-existing proposal whose vote hasn't concluded yet
3. Borrowing voting power: at the critical moment right before voting ends, instantly borrowing a massive amount of governance tokens via a flash loan — this batch of tokens' voting power far exceeds the sum of other holders normally participating in the vote
4. Executing the vote: voting with the borrowed tokens, pushing the malicious proposal past a threshold it wouldn't otherwise have passed
5. Executing the proposal and repaying funds: if the protocol is designed so the proposal executes automatically immediately upon passing (with no additional time delay), the attacker can immediately execute the proposal's resulting profit within the same transaction, then repay the flash loan — the entire flow can complete within seconds, within a single transaction

One key element here is especially worth noting: if a protocol sets a mandatory time delay (called a 'timelock') between a proposal passing and it actually executing, this can effectively block this instantaneous attack pattern, since an attacker can't let the borrowed tokens sit for longer than a single transaction — the timelock's existence gives the community enough reaction time to spot the anomaly and take response measures before the proposal genuinely executes.

What's the practical impact of a governance attack on everyday users, and how can they assess whether a DAO is vulnerable?

For a user holding a given protocol's governance token or storing funds within that protocol, a successful governance attack could directly result in the protocol treasury getting drained, or key security parameters being maliciously modified leading to subsequent attacks piling on — this kind of loss is often immediate and irreversible, since the voting and execution process fully complies with the protocol's own designed rules, with no centralized authority able to declare the vote invalid and forcibly reverse it afterward.

A few concrete indicators for assessing whether a DAO is vulnerable: whether the governance token itself has substantial on-chain liquidity available for flash loan borrowing (the deeper the liquidity, the higher the risk of a massive amount of voting power being instantly borrowed out); whether there's a timelock set between a proposal passing and actually executing (no timelock or an excessively short delay means the community lacks enough reaction time to respond to an anomalous vote); whether voting requires a minimum participation threshold (quorum) — if day-to-day voting participation is already low, the voting-power threshold an attacker needs to obtain is correspondingly lower too, more easily swayed by a small amount of sudden capital; and whether the protocol has ever experienced a similar attack attempt before (even an unsuccessful one) — this kind of historical record provides concrete reference on how genuinely attack-resistant a protocol's governance mechanism actually is. When checking whether a protocol is trustworthy, these concrete governance mechanism design details often carry more reference value than simply looking at 'is this a DAO.'