Blue-chip DeFi governance and how they fence governance attack

Different Level of Decentralization

Source: OurNetwork: Deep Dive #2 – Governance Extractable Value

There are different levels of decentralization to govern a protocol. For early protocol, usually, the developers have a single key to control the protocol, this ensures 100% control of the protocol and won't have the governance attack problem at all. In the multsigs model, the control is maintained by several key parties and usually all from the development team, this doesn't differ much with the single key control.

Only when the development team widely distributes their governance power to the community and token holders, and all important decisions of the protocol will be governed by token voting, the successful proposal passed the voting will be implemented automatically according to the pre-defined code. At this time, the problem of governance attack emerges and the need to carefully design the governance mechanism becomes important.

A governance attack, the case of Build Finance

Let's start with a recent case of governance attack. Build Finance is a venture DAO, the project was maintained by a DAO, token holders can vote on minting and allocating tokens. On February 9, Build Finance moderator penned a message in the Discord that said someone had made a proposal that, if passed, would let them mint tokens unilaterally. The community voted down the proposal. However, the attacker somehow accumulated enough tokens and sent them to another wallet, and tries again. This time attacker somehow bypasses the Discord server's bot (which would detect proposals and put them in a dedicated channel). This proposal seems got unnoticed and passed on February 10.

The governance model has a two-day timelock, while the attacking proposal passed on February 10, the project teams only made a Twitter thread on February 14 that said the attacker took whole control over the DAO and its token minting ability to create 1.1 million BUILD tokens for themselves. They dumped the newly minted token and drained the liquidity pools on two decentralized exchanges, BUILD tokens became worthless.

According to Build Finance medium page, the protocol uses the Governor Bravo model for governance. Governor Bravo is a very successful governance model initially proposed by Compound Finance and is now widely applied by many major DeFi protocols including AAVE, Uniswap.

Protocol using Governor Bravo has the power to transfer admin privileges, treasury balances, or even ownership of the governance timelock itself to a new address. This contributes to the fact the attacker can get complete control over the protocol. While it is like a gold standard of governance, Governor Bravo alone does not deter the governance attack, but it is worthy to get an understanding of how it works.

Governor Alpha & Bravo, a successful model

Compound Finance's Governor Alpha and its latest version of Governor Bravo is widely used by DeFi protocols. The governance process of Governor Bravo is as below.

Source: Compound

The proposal creator needs 65,000 $COMP to create a proposal, and after creating, it enters into a two days review period. Voting lasts for 3 days; if a majority and at least 400,000 votes are cast for the proposal, it is passed and queued in the Timelock and can be implemented 2 days after.

Uniswap also uses the Governor Bravo model with a very similar setup. The main difference lies in the significant amount of $UNI to initiate a proposal and the required quorum to passed it. It requires 2.5 million $UNI to initiate a proposal, which roughly equals $25M at the price on 21 February. The quorum need is 40 million $UNI, which is roughly $400M.

AAVE- two additional functions on Governor model

AAVE uses a governance model similar to Governor Bravo but introduces two more functions. First, it uses multiple timelocks for different types of proposals. Less sensitive and low stake proposals can go through a quicker governance process and get implemented.

Another important feature is the Guardian miltisig. In the Governor model, there is a Pause function, which can disable the mint, borrow, transfer, and liquidate function of Compound, but this cannot stop a bad faith proposal get passed if attackers accrue enough governance tokens. AAVE uses a multisig to directly cancel proposals that make it into the governance process (before they're executed). This safeguard can effectively prevent malicious proposals that may negatively impact the protocol.

Source: https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/

The safety measures

In the Governor Bravo model, several safety measures are at play. Some measures already become the gold standard in governance, and no matter what different type of governance is in use by other protocols, these measures are more or less be included.

1. Timelocks: this gives users enough time to react after a proposal is passed. Theoretically, they could leave the protocol or sell the protocol tokens if they are unhappy with any protocol changes. This is theoretically since this is subject to if there is sufficient liquidity for them to sell. Users generally prefer a longer time timelock, but long timelocks also reduce the time a protocol can quickly fix any problems.
2. High quorum requirement: In the case of Uniswap, to pass a bad faith vote need a prohibitively expensive amount of money. Furthermore, DAO treasury of Uniswap consists of exclusively $UNI token. Even if an attack succeeds, the entire control of Uniswap has been taken, the market will react and $UNI price will fall significantly making the attack not profitable.

   Source: Tokeninsight Annual DeFi report

3. Guardian Multisig: This is a powerful method and can stop any malicious proposal as long as it get noticed. But it could raise the question of who can make the decision call to directly veto a proposal in a decentralized governance model. AAVE guardians consist of ten members and are selected by the community by votes. 5/10 of the Guardian can veto an AAVE proposal.

A different model from MakerDAO

MakerDAO has a very different voting mechanism from Governor Model. In the Governor model, token holders vote for a particular proposal and after a proposal is approved or declined, this particular voting procedure is finished.

MakerDAO uses continuous approval voting. When $MKR holders vote for a particular proposal, and the proposal gets approved, the governance token will remain in the said proposal. This is in contrast to other voting mechanisms where governance tokens will be returned to the voters after a proposal is approved or declined. For each $MKR token, you can only use it to vote for one proposal. Therefore, if you want to vote for a new proposal, you need to manually un-vote the old proposal which you previously voted for, take out the $MKR token.

A new proposal needs to surpass the voting of the last successful proposal.

Source: MakerDao

Let's use two examples to illustrate.

For example, the proposal dated Feb 25 2022 got 82,001.5 $MKR votes, and is waiting for execution. If now someone raises a new proposal, the number of votes needed to pass is at least 82,001.5 $MKR (as shown on the System Info section).

If people don't manually take out the $MKR voted, those tokens remain in the old proposal. For example, an earlier proposal dated Jan 24 2022 which has already been passed and executed, there is still 20,050 $MKR sit in it.

This voting method increases the barrier for a new proposal to get passed. A large number of $MKR sit in the already approved & executed proposal, resulting in a reduced number of $MKR tokens in the market. For a new proposal to get approved, it needs to convince people to manually take out their token from the old proposal.

Vote-Lock model by Curve

Vote-lock is pioneered by Curve. No matter in Governor Bravo or MakerDAO's continuously voting, every governance token represents one vote. The governance token is traded on the open market and can be borrowed from various lending protocols. In theory, anyone who has enough collateral, say $ETH, can borrow enough governance token, say $UNI from lending protocol, and initiate a governance attack. In this case, the attackers do not need to worry about the falling $UNI price caused by the attack. They can sell whatever amount of $UNI they get from the attack, return the remaining worthless token to the lender and redeem their $ETH back.

In Curve's vote-lock model, voting power is not represented by the governance token itself. Holders of $CRV need to lock their tokens in order to get voting power. The locking period can be up to 4 years, and voting power is proportional to token holdings multiples by times locked and decrease linearly over time as tokens get closer to unlocking. In this way, the feasibility to borrow governance token to vote is limited.

ve Model gaining popularity

The vote-lock model (i.e. ve model) has significantly gained popularity since last year. Many newly establish protocols choose to apply this kind of governance token mechanism. One example is Izumi Finance, which features a Liquidity as a Service. Similar to Curve, there are two kinds of token, the $iZi token and the locked version ve-iZi token. Holders of iZi token need to staked their $iZi to get the ve-iZi, ve-iZi token entitled the governance power, and is not tradable or transferable. The governance power is proportional to the remaining time locked.

New variations of ve model also start to emerge

In the initial Curve ve model, veCRV is not transferable and not redeemable once staked. People can only wait until the locking period ends and get their $CRV back. Recently, some new protocols like Izumi Finance and the Solidly from Andre Cronje start to test a new method, veNFT.

Take the example of Izumi Finance, when user locks their $iZi, what they get is a veiZi NFT. This NFT represents the governance power and is also interest-bearing, allowing holders to stake them for rewards. The NFT can be traded on NFT marketplace like Opensea. Through this method, it solves the capital inefficiency problem of the initial ve model. However, this new method's implication on governance safety has not been discussed.

Conclusion

This article has briefly reviewed several popular blue-chip DeFi protocols' governance models. While these models all have been time-tested, there are still problems that arose from time to time. Like many things in the world, there is no 100% safety mechanism, safety is achieved by a combination of various measures, including a well-tested model, an active community, and a well-designed economic model which disincentivizes malicious behavior.

In risk management, there is a theory called the Swiss Cheese risk model. Every slice of cheese is like a given measure taken to minimize risk, can be thought of as a line of defense against accidents. Every slice of cheese is full of holes, these are weaknesses and potential for failure for a given measure. However, if we stack them together, one or more slices of cheese will cover a hole in another slice of cheese. The probability for a given risk event that can go through the whole stack becomes very low.

Source: https://thedecisionlab.com/reference-guide/management/swiss-cheese-model/

Take the example of Build Finance, the first attack was successfully voted down by the community, but the second attack was not picked up by Discord's bot, and no one got noticed. An active community (which serves as a line of defense) could make this kind of neglect avoided. Furthermore, if the cost of attack may outweigh the potential benefit, an attack may never happen.