What Is a Governance Attack in Crypto and How Can Protocols Protect Themselves?

What Is a Governance Attack in Crypto?

A governance attack is when someone uses or takes over the decision-making of a DAO or protocol to carry out a (usually) harmful action. A DAO is an organization that makes decisions through rules in smart contracts and votes from participants.

In many protocols, tokens determine how much voting power you have. Whoever gathers enough voting power can, for example, propose changing settings, adding new features, upgrading a contract’s logic, or moving money out of a treasury. A treasury is simply the shared pool of resources of a protocol.

Not every governance attack comes from a programming bug. Sometimes an attacker is formally just following the rules, but gathers enough influence to push through a proposal that is harmful to other users. That is called governance capture: decision-making has effectively ended up in the hands of one party or a small group.

One possible trick here is a flash loan. That is a loan that has to be paid back within the same blockchain transaction. If a protocol bases voting power on the current number of tokens in a Wallet, without a waiting period or historical snapshot, an attacker can temporarily get a lot of voting power.

Example: Suppose a protocol treats one token as one vote. Someone temporarily borrows a huge number of tokens, votes for a proposal to move money out of the treasury, and pays back the loan right away. If the system counts those temporary tokens, that may be enough to influence the vote.

Key Takeaways

• A governance attack abuses the decision-making of a DAO or protocol for a harmful action.
• In token-weighted governance, the number of tokens often determines how much voting power someone has.
• An attack can use a technical flaw, but it can also happen within the existing rules.
• Flash loans can temporarily create a lot of voting power if a protocol uses current balances.
• Proposals can include changing settings, upgrading contracts, or moving treasury assets.

How Does a Governance Attack Work?

A governance attack usually works by first collecting enough effective voting power, then getting a harmful proposal approved, and finally carrying it out. The exact process depends on the protocol’s rules.

Voting power can come from tokens you own, votes others delegate to you, staked tokens, or LP positions. An LP position is your share in a liquidity pool. The key question is: at what point does the protocol lock in how much voting power you have?

An attack often looks something like this:

1. Collect voting power The attacker buys tokens, gathers delegations, uses existing large voting power, or temporarily borrows tokens through a flash loan.

2. Submit a proposal The proposal contains one or more actions that smart contracts must execute. These can be changes to settings, but also an upgrade or a transfer from the treasury.

3. Win the vote The proposal has to get enough votes and reach the required quorum. A quorum is the minimum amount of participation needed before a vote is valid.

4. Execute the action After a successful vote, governance carries out the planned transactions. Without a delay, that can happen right away. With a timelock, the action has to wait first.

A historical snapshot helps against certain flash-loan attacks. Such a snapshot is basically a picture of voting rights at an earlier, fixed moment. A voting delay, meaning a waiting period before votes count, only works well if temporarily borrowed tokens are not already included in that snapshot.

Beanstalk shows how big the impact can be. On April 17, 2022, the protocol was attacked through on-chain governance. The attacker used a flash loan to compromise the governance mechanism at the time and take assets from the DAO.

A snapshot is not a complete solution, though. If an attacker already bought or controlled the tokens before the chosen moment, that voting power still counts.

What Can a Governance Attack Do?

A governance attack can let an attacker take control of money, rights, or important settings in a protocol. How serious that is depends entirely on what governance is actually allowed to do.

In some protocols, governance can change system settings, add new markets or features, and upgrade parts of the protocol. If governance also controls important proxies, configuration components, or treasury contracts, a malicious proposal can do a lot of damage.

Possible effects include:

• loss of treasury or user assets;
• unwanted minting of new tokens;
• changed settings that hurt users;
• modified admin rights;
• an upgrade to harmful contract logic;
• temporarily or fully shutting down functions.

In the attack on Beanstalk, all non-BEAN user assets were stolen on April 17, 2022, worth about $77 million. After that, the protocol was paused, on-chain governance was removed, and the governance setup changed.

The damage is often bigger than just the direct loss. A protocol may have to migrate to new contracts, pay for audits and recovery work, and temporarily give more emergency control to a small group. That can seriously hurt user trust.

How Can a Protocol Lose Control?

A protocol effectively loses control once an attacker has enough rights over the contracts that carry out critical actions. Think of the owner of a proxy, an account that can perform upgrades, a role that can schedule proposals in a timelock, or the controller of the treasury.

A proxy here is simply a fixed contract address that points to a certain version of the contract logic. In an upgradeable protocol, governance can make that address point to new logic. That means one approved proposal can significantly change how the protocol works.

An attacker does not always need a majority of all token holders for that. With low turnout, a low quorum, or heavily concentrated delegations, a relatively small group may already have enough effective voting power.

After a harmful execution, recovery can be even harder. The attacker may change permissions, move assets away, or even change the future governance rules. In that case, the community may no longer be able to intervene through the same route, or only much later.

Loss of control can also happen without an attack. If the authorized accounts of a self-governed timelock are no longer available, a contract controlled by that timelock can get stuck indefinitely.

How Can Crypto and DeFi Protocols Protect Themselves?

Crypto and DeFi protocols can reduce the risk by making sure voting power, permissions, and execution do not all come together too easily at one moment. There is no magic setting that stops every attack, but several layers together make abuse harder.

Important measures include:

1. Use snapshots and a voting delay Lock in voting power at an earlier moment and build in a waiting period. That makes it harder to arrange temporary tokens right before a vote and use them immediately.

2. Choose appropriate voting thresholds A proposal minimum makes cheap spam proposals harder. A quorum prevents a very small turnout from deciding everything. The tradeoff is still tricky: too low makes capture easier, too high can make governance unusable.

3. Put sensitive actions behind a timelock Upgrades, major parameter changes, and treasury actions do not have to happen right after a vote. A timelock gives users time to review a planned action and possibly close their position.

4. Limit rights by role Do not give governance unlimited power by default. Rights for upgrades, minting, and unlimited external calls especially deserve extra limits. Emergency rights should be clearly defined.

5. Test the actual proposal actions It is not enough to check only the voting module. Teams also need to test and simulate the exact transactions behind a proposal. A proposal may look harmless at a high level, while the actual calls do something very different.

6. Monitor proposals and voting power Monitoring does not stop an attack by itself, but it can help a suspicious proposal or a big shift in delegations get noticed in time. A prearranged incident plan then helps with a faster response.

Audits are still useful, but they are not a guarantee. Not every governance attack comes from a bug in the code. Misleading proposals, low participation, and poorly reviewed transactions can also cause problems.

How Can Timelocks and Multisig Governance Help?

Timelocks and multisigs can add an extra layer of security because they stop one approved or compromised account from executing everything right away.

A timelock controller enforces a minimum waiting period between scheduling and executing an important action. If the timelock is the admin of a contract, that delay also applies to actions that otherwise could happen immediately with admin rights.

That reaction window matters. Users and security researchers can review the exact transaction data before the change goes live. With a dangerous proposal, users can, for example, close their position before the action is executed. The timelock does not automatically invalidate a harmful action, but it does slow down a visible attack.

Compound v2, for example, uses multiple phases: two days of review, three days of voting, and then two days of timelock. That means a protocol change there takes at least one week.

A multisig works differently. It requires multiple owners to confirm a transaction. In a 3-of-5 multisig, three valid signatures are needed. One stolen or compromised key is not enough to move money or change settings on its own.

A multisig can, for example, be the only party allowed to schedule actions in a timelock. That means a group of signers has to agree first, and only then does the set waiting period begin.

One important thing to know: a multisig shifts trust to the signers. If enough signers collude, if too many keys are stolen, or if signers are unavailable, problems can still happen. Extra modules or extensions also deserve attention, because under certain conditions they can execute transactions outside the normal signature check.

What Are the Limits of Governance in Crypto?

Governance in crypto can carry out decisions transparently and automatically, but the system does not automatically know whether a proposal is also smart or fair. A valid on-chain vote only proves that the rules were followed.

In token-weighted governance, influence is tied to economic weight. Large holders, funds, and well-known delegates can therefore have much more influence than small participants, even without an attack or a bug in the code. Delegation makes voting easier, but it can also concentrate power in a small group.

Speed and security also sometimes clash. Longer voting periods and timelocks give more time to review proposals carefully and respond. At the same time, they slow down useful upgrades, changes, and sometimes a response to an incident.

Quorums and proposal minimums have the same tradeoff. If they are too low, a small but well-organized group can make decisions. If they are too high, normal proposals can get stuck because too few people vote.

Another problem is complexity. The exact calldata of a proposal, an upgrade to contract logic, or the interaction between multiple smart contracts is hard for many voters to judge. That means a proposal can be procedurally correct while very few people really understand what is happening.

A multisig or guardian can lower the risk of a fast attack, but it also adds centralization and availability risk. A guardian is an account or group with special emergency rights. If such a party acts maliciously, is unavailable, or blocks transactions, that security layer itself can become a weak point.

Governance is therefore not a setting you configure once and then forget. The distribution of tokens, delegations, rights, incentives, proposal review, and emergency procedures all need to be checked regularly.

Conclusion

A governance attack is not just about hackers finding a technical flaw. A party that gathers enough voting power according to the rules can also put a protocol in trouble if governance has too many rights or if proposals are executed too quickly.

Good protection comes from multiple layers: snapshots, a voting delay, appropriate thresholds, limited permissions, review of proposal actions, and monitoring. Timelocks and multisigs can add extra time and control on top of that. In the end, the main question stays simple: who can change what, and how much time does everyone else have to see it and react?