How to prevent the extraction of value from governance procedures and the security of GEV hazard agreements?

This article was published on Ethereum Enthusiasts, authors: Leland Lee & Ariah Klages-Mundt, translation: A Jian.

The governance process is the ultimate owner of the protocol. Whether it is a dictatorship or a plutocracy, the governance process controls every mutable aspect of the relevant protocol and how they change. Unlike traditional companies, the governance process of blockchain applications is transparent, defined by specialized smart contracts (thus deterministic), and any changes are visible to everyone. But where there is light, there is also darkness. The governance process can sacrifice the entire system for its own benefit, which we refer to as "Governance Extractable Value (GEV)." Unlike traditional companies, there is no judicial framework to restrain poor governance.

What is the Governance Process?

The governance of a protocol can be represented by two axes: what is controlled by the governance process and how many people participate in governance. Each protocol has its own goals, so the design space is quite diverse. Some protocols are immutable, while others have very few parameters (such as fee switches and pause functions), and some can even completely replace the functionality of business contracts (or are termed "upgradable"). Ultimately, control may be unowned, or it may fall into the hands of one person, a small group of people (entities corresponding to multi-signature contracts), or a large group of people (governance token voting). Without mechanisms to check power, the complexity and flexibility of contracts can become a breeding ground for opportunism.

GEV Exploitation

Will the governance process keep the ultimate interests of users in mind? It seems too full to be right : ) GEV exploitation can be broadly divided into two categories: capital structure exploitation and short-termism.

Capital Structure Exploitation

Capital structure exploitation, commonly known as "rug pull," involves the governance process stealing collateral from the system or directly transferring collateral to themselves. A rug pull is similar to a bank running away with depositors' money, although capital structure exploitation can be done more secretly and indirectly. Most users would not deposit money into a contract with an obvious callable rug pull function. However, developers can later add a rug pull function or exploit the structure of the system to pull off a rug pull in an indirect (and dazzling) way. Here are some examples:

• Malicious upgrade rug pull. Normally, in a bank, users can only deposit and withdraw their own money, and should not be able to withdraw others' money. The initial design of Compounder did not have a backdoor. However, when developers upgraded the contract, they added a rug pull function that allowed them to steal a total of $10.8 million in collateral assets. Although there was a 24-hour time lock before the upgrade took effect, during which users could withdraw their assets, very few users would actually monitor the contract closely.

• Infinite minting exploitation. The owner account of the PAID network's ERC20 token contract is singular, allowing for the minting of new coins. In the attack, developers minted millions of coins, drained the PAID-ETH liquidity pool on Uniswap, and then ran away with the ETH, leaving countless PAID tokens worthless due to hyperinflation.

• Selling out minority shareholders. DigixDAO voted to return the ICO fundraising to token holders because the capital raised at that time was even more valuable than the governance tokens. Behind the scenes, a coalition controlled most of the shares, and it was unclear who these people were and how they would vote (the Digix team consistently opposed dissolution). Before the vote was initiated, parties could purchase DigixDAO tokens from minority shareholders, with the market price differing from the corresponding ETH reserves by as much as 48%. To this day, it remains unknown whether these buyers were members of the coalition looking to profit by selling out minority shareholders or unrelated individuals merely betting on the voting outcome.

• Voting rug pull. MakerDAO theoretically has an attack vector: the governance process can vote to transfer all collateral in the system to themselves without notifying end users. However, the risk has been mitigated by time locks.

Short-termism

While both governors and users hope for the protocol's growth, they may have differing opinions on the specific methods and steps. Users aim for sustainable growth. In contrast, holders of governance tokens may pursue growth at all costs. Therefore, making high-risk bets for immediate visible benefits (transaction fees / increasing the value of governance tokens) is not out of the question, although this can harm the entire system and make it more fragile. Short-termism can manifest in many ways. One example is using higher-risk assets in the operating system and increasing the overall debt ceiling.

• Cream Finance is a copy of Compound that incorporated many low-growth DeFi tokens and did not set a debt ceiling to attract users and volume. However, deposits of the FTT token ultimately constituted 40% of Cream's deposits, significantly increasing the risk of this protocol. If the price of FTT plummets, lenders on Cream may lose their assets.

Addressing GEV

In traditional companies, the preventive mechanisms for GEV include conservative forces, regulators, and class-action lawsuits, which serve as a stick to deter exploitative behavior. However, these cannot be translated into smart contracts (whose logic is pre-programmed). In an on-chain world, the governance process must be pre-programmed and have incentives to curb malicious behavior, as we all know that no centralized institution can administer justice for us after an exploitation.

Decentralizing Power ------ Multi-signature and Token Voting

There are many considerations in arranging who governs the protocol. Simply assigning a single ownership account is the most convenient for developers, as upgrading the protocol requires only one key and does not need to coordinate with other key holders in different time zones or indifferent token holders. The development process can be unilaterally invested and completed quickly, but users must trust the holder of this private key.

Multi-signature control and token voting systems are better choices for more mature protocols, as they can achieve broader consensus. However, in reality, if the development team controls a majority of the voting tokens, the system will revert to a dictatorship or coalition mode.

No or Limited Contract Upgradability

Early smart contracts attempted to achieve a literal sense of "immutability." Changes and upgrades to contracts were impossible. If a contract had a bug, or if developing smart contracts became akin to designing unmodifiable hardware, it would be terrifying, much like an irreparable Mars probe. Adding new features to an immutable contract requires users to migrate their funds themselves. From one perspective, this is a feature (one can imagine that the code does not change), but it can also be seen as a terrifying user experience black hole (YAM users had to migrate their tokens twice).

The most direct improvement method is to design a minimal upgrade space, such as a pause function, which is very useful when a bug is discovered, along with some very limited parameters.

The most flexible design is to use upgradable contracts (compositions), where a core (proxy) contract stores all data and references a replaceable contract to load all business logic. Users may not even know that the underlying contract has been upgraded, resulting in a smooth user experience (though rug pulls can also be smooth).

Time Locks

The design of time locks in the governance process is intended to give users time to adapt to upgrades. Assuming liquidity is sufficient, time locks allow users to exit the protocol (assuming they do not like the upcoming changes). For this purpose, users would prefer to design longer time locks, giving them time to understand the changes and react, but longer time locks also reduce the protocol's flexibility. MakerDAO has long refused to implement time locks for this reason.

However, time locks are not a panacea: users can theoretically do this, but that does not mean there is liquidity in the market for them to do so. If Maker's governance process attempts to seize all collateral in a CDP while DAI's liquidity is low ------ then those wanting to obtain DAI to close the CDP will have to fend for themselves. Moreover, this assumes that all users will continuously monitor the time lock to guard against malicious behavior (Compounder, we are talking about you).

Optimistic Permissions

As an upgrade to time locks, optimistic permissions allow the protocol to quickly pass proposals unless someone initiates a veto. The veto function enables retail users of the protocol, i.e., those who use the protocol but do not participate in the governance process, such as DAI holders, CDP holders, and Uniswap liquidity providers, to reject proposals from the governance process. If a sufficient number of users initiate a veto, the time lock will be extended to allow more users to support or reject the veto. The result is that developers can also respond quickly, but users have ways to protect themselves.

• Support for recourse ------ If there were only time locks, malicious upgrades would lead to bank runs and panics. Now users do not need to exit immediately.

• Safety valve ------ In the context of malicious proposals, an absent user does not need to worry about losing funds (no need for a watchtower-like service). Just a few users monitoring the time lock can ensure everyone's safety.

The optimistic permission method essentially changes the incentives of governance, making rug pulls unprofitable. When attempting a rug pull, vigilant users will initiate a veto to protect themselves and others. Governors will face failure because the attack cannot succeed, and users will be less willing to join the protocol.

A key aspect of optimistic permissions is determining which teams are qualified to initiate a veto. In systems like MakerDAO, should CDP owners and DAI holders have veto power? Or should only a specific team have it?

Long-term Governors

The governance process must align with the long-term success direction of the protocol. Generally, this requires token holders to lock up capital or prove they are long-termists. The former can take the form of indefinite staking or maturity release systems (like Curve). The latter can take the form of lifetime voting systems (where users holding tokens for longer have greater voting weight).

In general, derivative products and smart contracts can be used to manipulate token locking mechanisms. However, a lifetime voting system does not guarantee that a long-term token holder still wants to continue being a long-termist. Perhaps when this long-term holder has more power, they may find it more profitable to change their approach.

An alternative approach is to delay capital returns (dividends / buyback-destroy) to governance token holders and set conditions based on stability / KPI metrics. The rationale behind this is that the governance process should not receive returns from the current growth of the protocol but should receive returns from future growth to ensure they continue to perform well. Essentially, if the system becomes unreliable, the governance process must take responsibility (they will not receive returns). Conversely, these bonuses should be contingent on the system continuing to grow healthily. A stark contrast: the short-term incentive mechanisms of bankers and politicians. DeFi gives users an opportunity to correct this in governance structures.

Reducing GEV Will Enhance the Credibility of the Protocol

Although there are many apes and degens, making it seem that even high-risk protocols can attract capital and users ------ most users are more risk-averse. GEV is also a risk, and it is more pervasive than the risk of a direct rug pull. Designing systems to counterbalance GEV will be key for dApps to gain popularity and achieve the original vision of decentralized finance. May there be no rug pulls in the world.

Footnotes:

【0】 The Aave governance process has a multi-signature backdoor guard that can veto malicious proposals (more for developers than for user service).

【1】 The distortion of the veto mechanism can create a poison pill (i.e., confiscation) for malicious proposers ------ although this may be abused and requires additional analysis. Enabling confiscation is dangerous unless its conditions are provable. For example, it is easy to prove that a validator signed two competing blocks (PoS); under given state assumptions, it is also easy to prove that a transaction is valid (by verifying the block's validity), but it is not easy to prove that a governance decision is malicious using these methods. Ultimately, it will come down to consensus agents to determine whether it is bad, but that is not the same as whether it is inherently bad. This raises a series of questions: how to protect minority shareholders against the tyranny of the majority?

【2】 Smart contracts can be designed to lock governance tokens and trade a derivative token representing the locked assets. A blacklist function can be used to prohibit contracts from participating in governance, but this will also disable multi-signature wallets (although specific bytecode can be allowed through a whitelist, etc.).