StableLab Logo
Safeguarding on-chain governance
Safeguarding on-chain governance
Safeguarding on-chain governance

Safeguarding On-chain Governance

Matt Stein profile picture

Matt Stein

Aug 24, 2023

The Great On-chain Migration

Decentralized governance enables participants to make collective decisions and manage resources without centralized intermediaries. However, this approach is susceptible to governance attacks, where bad actors exploit vulnerabilities in the decision-making process. The most common type of attack occurs when a bad actor acquires enough voting power to propose and pass a measure that grants them control over the DAO, the protocol, or the treasury. Without additional safety measures and mechanisms, these attacks stand to destabilize the future of DAOs.

Currently, many DAOs use off-chain voting platforms like Snapshot and rely on trusted individuals, such as a foundation or a core team, to implement the voted changes. However, with the increasing popularity of on-chain governance tools like Tally, more DAOs are moving to on-chain governance, where proposals are automatically executed once a vote passes. While this does increase decentralization, it also creates new opportunities for governance attacks. On-chain proposals automatically execute transactions, which means that if a bad actor gains enough votes, they could pass a proposal with a transaction that proves to be catastrophic.

Cost of Governance Attacks

Let’s explore past instances of governance attacks and the financial impact they had on DAOs to better understand the severity of these types of attacks.

Beanstalk: Beanstalk, a stablecoin protocol, lost $182,000,000 when an attacker used a flash loan to gain sufficient voting power to force through a proposal to transfer $182M of Beanstalk’s reserves to themselves.

Tornado Cash: A malicious proposal in Tornado Cash allowed an attacker to withdraw all locked governance votes and drain all the tokens from the governance contract, resulting in a loss of approximately $1,000,000 for the protocol.

Build Finance: Build Finance lost $470,000 when an attacker was able to gain enough voting power to pass a proposal that gave them “full control of the governance, contract, minting keys, and treasury”.

Governance Safeguards

So how do you prevent malicious proposals from destroying your DAO? Below are common methods used by DAOs and the pros and cons of each. These methods are not mutually exclusive and can be used together to make your DAO even more secure. This overview aims to help guide you in choosing which method might be best for your DAO.

Execution Delay

If your governance contract executes an on-chain transaction in the proposal immediately then you have no way to stop malicious proposals once the vote is passed. One way to allow a buffer period where the DAO can catch and stop bad proposals is by implementing something called an Execution Delay. An Execution Delay provides an extra day or two after the vote has passed before it executes any transaction it may have on-chain. This gives the DAO time to identify and stop malicious proposals before they are added to the blockchain. There should almost always be an execution delay to add a layer of protection to governance. There are exceptions to this such as emergency proposals where you cannot wait to execute the proposal but emergency votes should follow an established fast-track process as we've previously discussed here.

Execution Delay + Foundation Intervention

Now that you have this day or two how do you actually stop the malicious proposal? Some protocols give a foundation (or trusted) member the ability to throw out (veto) malicious proposals once they are passed.

The Rari Foundation, responsible for stewarding the decentralization of the Rarible Protocol, uses a “cool down period” to delay passed proposals by 2 days to give time for their board to nix proposals that violate DAO rules. Importantly, Rari is currently in the process of adding a security council to fill this role.

RARI DAO uses a "Cooldown Period" in Phase 4 of its Governance Process


  • Prevents malicious proposals

  • Core Team is incentivized to protect the protocol and treasury


  • Creates centralization as the DAO must rely on a centralized entity to watch over proposals.

  • Gives the board the ability to reject any proposal they see fit even if they are not necessarily malicious.

Execution Delay + Security Council

Another method to filter proposals during the execution delay is through the use of a Security Council. A Security Council is a group of trusted contributors to the DAO who are responsible for safeguarding it in emergency situations. Their main role is to review and block any malicious proposal that may arise during the execution delay. Initially, the members of the Security Council can be appointed based on trust, but should eventually transition to an elected system with defined term limits. Security councils offer several advantages over foundations monitoring malicious proposals. Firstly, since the members of the Security Council are paid specifically to identify malicious votes, it ensures that at least one member of the council will detect any such proposal. Secondly, it introduces accountability, as any member who either overlooks a malicious proposal or attempts to approve one can be replaced. Lastly, having a diverse group of individuals provides safety in numbers and different perspectives. It should be significantly more challenging for an entire Security Council to organize, collude, and attack the DAO.

Arbitrum currently has a three-day voting delay and a 12-person security council that has the power to act in case of emergency should a malicious proposal be passed. This council initially started as an appointed position for trusted individuals but public election for new members will commence in September 2023.

Arbitrum DAO uses a 3-day proposal delay to prevent malicious proposals


  • Prevents malicious proposals

  • Security Council is held accountable since they can be replaced

  • Harder to corrupt an entire council

  • More people watching for malicious proposals


  • Some level of centralization as the DAO must trust this group to act in good faith

Whitelisting Addresses

Whitelisting addresses refer to when a DAO preapproves certain wallet addresses to post proposals on-chain. All other DAO members must request permission from these whitelisted addresses to post a proposal on their behalf. This prevents bad actors from posting malicious votes unless they are one of the few trusted ecosystem actors. This however causes major centralization issues and can prevent even beneficial proposals from moving forward.

For example, in ApeCoin DAO only moderators can move proposals to a vote. Anyone who authors a proposal must have it reviewed and posted by a moderator. While this can limit attacks it also limits DAO members' ability to contribute and slows down the governance process.

ApeCoin requires a whitelisted Moderator to post AIPs


  • Prevents bad actors from submitting malicious proposals


  • Very centralized as it means a few people must approve any proposal before it goes to a vote

  • Can prevent good-intentioned DAO members from making a positive change to the protocol

  • Can slow down governance if you have to wait on a small group of people

  • Even trusted members can turn bad and create malicious proposals

Token Staking Models

Governance attacks can happen suddenly if an attacker acquires tokens on the open market to manipulate a vote. One way to limit this is to incentivize users to stake or “lock” their tokens in order to receive rewards. This is done by separating tokens held and voting power. Instead of voting using the token itself, DAO votes are counted using a staked version of the token. People who stake their governance tokens are rewarded over time with more and more voting power. This prevents someone from being able to instantly buy the majority of the voting power. Instead, they would need to lock their tokens for multiple years and have their voting power grow over time.

For example, Curve Finance uses a vote escrow model for its token veCRV which grants users who lock their CRV voting rights and influence in the Curve Wars. More importantly, it promotes long-term commitment to the protocol while discouraging short-term manipulation.

The veCRV model incentivizes CRV users to "stake" their tokens in order to gain voting power

This means, for instance, if an attacker needed 100 votes to ensure any proposal would pass in a normal DAO they could buy these 100 votes. However, in Curve, they would need to buy 400 tokens and then stake these for 1 year in order to acquire the same 100 votes needed to force through a proposal. This means it costs 4 times more and delays their attack by 1 year. This added cost and time delay disincentivizes attackers from trying to force through a malicious proposal, at least in the short term.


Makes it significantly slower to attack.


  • Bad actors can still accumulate a large number of votes over time.

  • Makes it harder for new passionate DAO members to have a say.

Minimal Governance

A more extreme method to prevent governance attacks is simply not having DAO governance or very little. If the DAO does not have control over treasury funds or parameter changes then it is likely not worth it for a bad actor to invest resources into an attack, at least not from this attack vector.

For example, over at Ajna Finance delegates have limited power as they only have a say in the grants program. While a bad actor could theoretically acquire enough voting power to give themselves a grant, this would likely not be worth the effort for a small reward. In addition, Ajna uses a form of quadratic voting to lower the chances of this happening.


  • Reduces the attack surface of a protocol.

  • Disincentivizes attacks


  • Decreases community involvement in shaping the protocol’s future.

  • Usually a non-upgradeable protocol


While none of these methods are perfect, they do offer some level of valuable protection to a DAO. It’s crucial that every DAO consider all safety measures and strategies to keep themselves safe. At StableLab we have experience in implementing and serving as part of many of these frameworks. If you are confused about how you can implement them into your DAO reach out to us for help.

Share with your friends: