Our Network is on-chain analytics and research-focused newsletter that reaches nearly 10k crypto investors every week 📈

Governance is the ultimate owner of a protocol. Whether it be a dictatorship of one or a plutocracy, governance controls every adaptable aspect of the protocol and how it evolves. Unlike traditional companies, governance in blockchain dApps is transparent and deterministic as defined by smart contracts, and changes are visible to all. But where there is light, there are also shadows. It can be easy for governance to extract value at the expense of the system, something we term Governance Extractable Value (GEV). And unlike traditional companies, there is no judicial framework as the ultimate recourse for bad governance.

Protocol governance is divided along two axes: what can be controlled and who has control. Each protocol has different goals, leading to a diverse design space. Some protocols are immutable and change is impossible, others have minimal parameters such as toggling fees or a pause function, while others enable the entire functionality of a contract to be replaced (or “upgraded”). These powers of control can rest in the hands of no one, a single user, a small group (multisig), or a large group (governance token voting). Without mechanisms to check powers, complexity and flexibility can be ripe for opportunistic behavior.

Does governance have users’ best interests at heart? History is mixed :) GEV exploits fall into two broad categories: capital structure exploitation and short-termism.

Colloquially known as a “rug pull”, capital structure exploitation involves governance stealing collateral from the system and giving it to themselves. Rug pulls are akin to a bank taking users' deposits and running away, although they can be more subtle and indirect. Most users would not knowingly participate in a contract with an obvious rug pull function that anonymous developers can call. But developers can often add rug features later or exploit the system structure to rug pull in indirect (and confusing) ways. Here are some examples:

• Malicious upgrade rug. In an imaginary bank account, users should deposit and withdraw only their money. They should not be able to withdraw other users’ funds. Compounder’s initial design had no backdoor. However, the developers upgraded the contract and added a rug pull function, allowing them to steal a total of $10.8m of collateral assets. While there was a 24hr timelock before upgrades took effect, during which users could have withdrawn their assets, few users were actually monitoring this.
• Infinite mint hack.PAID network’s erc20 token had a single account as an owner who could unilaterally mint new tokens. In the attack, the developers minted millions of tokens to drain the PAID-ETH Uniswap pool, running away with the ETH and rendering PAID valueless due to hyperinflation.
• Sidelining minority holders.DigixDAO voted to return the ICO treasury to token holders as it was worth more than the governance tokens. Behind the scenes, a coalition held a controlling share. It was unclear who they were and how they would vote (the Digix team was vocal against dissolution). Before the vote came in, parties were able to buy DigixDAO tokens from minority holders for as much as 48% spread against the underlying ETH settlement. It is unknown whether these parties were coalition members themselves, profiting at the expense of minority holders, or other parties betting on the vote outcome.
• Vote to rug. MakerDao had a theoretical attack vector where governance could vote to give all the system collateral to themselves without warning to end users. The time component now has been mitigated by a timelock.

Although governors and users want a protocol to grow, they may have different views on the particular approach and timeline. Users aim for sustainable growth. In contrast, governance token holders may want growth at any cost. It can be attractive to make risky bets on the future in order to get immediate benefits (fees / token appreciation) but at the system's expense, ultimately making the system more fragile. Short terminism can manifest in many things. An example is listing risky assets and increasing debt ceilings in tokens that are beneficial to governors.

• Cream Finance, a fork of Compound, listed many non blue chip DeFi tokens with no debt ceiling to attract more users and volume. However, $FTT deposits eventually represented 40% of all deposits on Cream, significantly increasing the protocol's risk profile. If FTT experienced a severe price drop, then lenders on Cream would lose their assets.

For traditional companies, GEV prevention is reactionary, with regulators and class action lawsuits acting as a stick to discourage extractive behavior. But that world does not translate to decentralized smart contracts where logic has to be programmed beforehand. In an on-chain world, governance needs to be preprogrammed or have robust incentives not to be bad as there is supposed to be no centralized party to react with recourse after exploitations.

There are many trade-offs with who actually governs the protocol. Deploying with a single owner account is amazing for developers. Only one key is required to upgrade the protocol, and there is no need to coordinate with other key holders in different time zones or to rally apathetic token holders. Development is fast and unilateral, but the trust is with the key holder. Multisigs and token voting are apt for more mature projects to reach a more distributed consensus on updates. Though in practice if the development team controls most of the voting tokens the system reverts back to a dictatorship or coalition.

These days, the trend is to outsource specific controls to particular user groups - dynamic Balancer fees via Gauntlet and MakerDAO’s Debt Ceiling Instant Access Module. These governance carve outs must be designed carefully to not enable hidden exploits.

Early smart contracts tended to take immutability in the literal sense. Changes or upgrades to contracts were impossible. This is naturally horrible if there is a bug and makes smart contract development akin to designing immutable hardware, like the Mars rovers that are out of reach to repair. In immutable contracts, new features require users to migrate contracts. In some eyes, this is a feature (we can trust the code not to change) but can also be a horrid UX bug (YAM users had to migrate their tokens twice - 🤷).

The intermediate step is having a minimal upgrade surface, such as control over a pause toggle, which is useful when bugs are discovered, or other very limited parameters.

The most flexible design is using upgradeable contracts. This is a core (proxy) contract that stores all the data and refers to a replaceable contract that actually governs all the logic. Users may not even know that the underlying contracts are updated, enabling both a seamless UX and a seamless rug.

A governance timelock is intended to give existing users breathing space to adjust to an upgrade. Given enough theoretical liquidity, timelocks enable users to leave the protocol if they are unhappy with pending changes. Given this dynamic, users ought to desire long timelocks so they can both hear of the change and better understand and react to it, but long timelocks also reduce the protocol’s agility to correct problems. MakerDao, for the longest time, rejected a timelock for this reason.

But timelocks aren’t a panacea: just because users can theoretically exit a protocol during a timelock, it doesn’t mean that there’s actually liquidity to do so. If Maker governance tries to seize all collateral in CDPs and DAI liquidity is low - good luck acquiring Dai and closing out CDPs during the timelock. And this assumes that all users are constantly monitoring the timelock for malicious behavior (hi Compounder).

As an evolution on timelocks, optimistic approval enables proposals to be quickly passed unless a veto is initiated. A veto would entail users of the protocol, i.e. individuals who use the protocol but aren’t part of governance, such as Dai and CDP holders and Uniswap LPs, to reject a proposal by governance. If the minimum number of users initiates a veto, then the timelock duration is increased to enable more users to either support or reject the veto. The result is that developers can ship quickly while leaving users with a voice to protect themselves.

• Enabling recourse - in a timelock-only world, a malicious upgrade leads to a race for the exits assuming sufficient liquidity. Now users don’t have to leave anymore.
• Fail safe - in the event of a malicious proposal, an absentee user doesn’t need to worry about losing funds (no need for watchtower-like products). Only a small number of users are required to monitor the timelock to keep everyone else safe.

Optimistic Approval essentially shifts the governance incentives, so that rug pulls are unprofitable. After an attempted rug pull, the attentive user will initiate the veto, protecting themselves and other users. The governors will be worse off since the attack will fail and users will be less inclined to participate in the protocol's future.[0]

One caveat of optimistic approval is determining which group of stakeholders should be able to initiate vetoes. In a system like MakerDAO, should both CDP owners and Dai holders have veto power or only one group? [1]

Governance must be aligned with the long-term success of a protocol. Generally, this involves having token holders lock up capital or prove that they are long-term orientated. The former manifests in staking with unbonding periods or locking tokens into the future (a la Curve). The latter manifests as tenured voting, where users who have been holding tokens for longer have more weight. Often, token locking mechanisms can be gamed with derivative products and smart contracts[2]. And tenured voting doesn’t guarantee that a token holder will continue to be a long-term one. At the point where tenured voters have more power, they may decide it is more profitable to change their behavior.

An alternative mechanism is to delay capital distribution back to governance holders (dividends / buy back and burns) into the future and conditional on stability/kpi metrics. The idea is that governance should not be rewarded for growing the protocol today, but instead rewarded tomorrow to ensure that they do a good job over time. Essentially, governance should be held responsible (and so not receive bonus payouts) if the system is no longer standing. Instead, these bonus payouts should be conditional on the system continuing to be healthy into the future. A powerful comparison: short-term incentives of bankers and politicians. DeFi gives us a chance to correct this in the governance structure itself.

Although there are enough apes and degens in the foreseeable future to ensure that even risky protocols will have capital and usage - the majority of users are much more risk-averse. GEV is one of these risks, and it is much more general than just straightforward rug pulls. Designing GEV-resistant systems will be critical in both broadening the adoption of dApps and realizing the original promises of decentralized finance. A rugless future awaits.