Full Disclosure: The intent of this piece is not to pass judgment or take sides. The goal is to spread awareness of governance-related exploits, and explore potential solutions.
“Code is Law.” Thus spoke Lawrence Lessig in the midst of the internet bubble. So it was, is, and, presumably, always will be.
The phrase has remained a mantra of developers for decades; but, as news of exploits rises daily, it grows harder to sit idly in rose-colored lenses. For a community that calls itself web3, it feels harshly ironic to have taken a web2 mantra as a necessary condition for existence.
Devotion for the expression is rooted in the right place. The ethos of cryptocurrency, which is focused on decentralization, fair access, and security, is impossible without rigidly expressed conditions. Yet, the phrase is simultaneously twisted by a more nefarious audience that uses it to justify questionable actions. In doing so, they’re robbing law of its ‘natural’ meaning: that there are, in fact, moral truths applicable to everyone- namely life, liberty, and property.
Crypto still fails in its protection of property. Law is fundamentally designed for the protection of the sovereign individual, including their wealth. So, the claim that bad code is grounds for asset seizure fundamentally misconstrues the aim of law, and certainly shouldn’t serve as a justification for destructive behavior. Considering code to be law in these instances is the equivalent of claiming ‘might is right’.
Almost every single one of the largest hacks in DeFi history have come over the last six months. Yes, some of this is due to the recent influx of users and money into the space. This brings relative inexperience, and lots of money, which attracts bad actors. Yet, we would also hope that industry maturity would rise over time, leading to a decreased number of hacks at a larger monetary scale. This has not been the case.
Over the last few days alone, mega-cap names like Aave and Fantom have fallen subject to exploits, or governance-token issues. Extending the lens to a two week view includes other notable names- Beanstalk, Rari, Stake/Convex drama, and more. Issues with code and audits will always remain, but making fundamental changes to tokenomics can significantly improve the investor experience. That is, at least until a new issue arises, and the paradigm has to be shifted once more.
To contextualize the current state of tokenomics, as well as their limitations, I spoke to a number of ecosystem builders, investors, and consumers. From there, we progressed discussion to potential solutions to prevent common existing issues. I tried to remain focused not on the underlying code that caused problems, but on how changes to tokenomics moving forward could solve them.
Without re-writing too much history (see, Rekt), Beanstalk suffered a major governance exploit on 4/17. From launch, Beanstalk has been governed via on-chain governance. The ability to deposit assets, receive stalk, and immediately participate in governance has been in place since launch. It was this functionality that was ultimately exploited. After proposing two innocuous governance updates (BIPs), the attacker borrowed $1bn of value from Aave, and used it to acquire a supermajority of the governance token. They withdrew all LP tokens, and made off with all the non-Beanstalk assets.
I had a chance to sit down with the Beanstalk founders (all anonymously named Publius, but doxxed post-hack). We spoke at length about the situation leading up to the hack and the path forward. A few things to note that I took away from the conversation:
- Beanstalk was audited. If it was audited more, it would’ve likely been caught. At the same time, it’s likely that there are still uncaught latent issues in Beanstalk (and many other protocols, as we’ve seen time and time again).
- Doing on-chain governance in a truly decentralized fashion is not trivial. Computer security is a cat-and-mouse game between hackers and protocols, with protocols being on the hook for 100% of funds. That is not sustainable.
- While their analysis was largely accurate, Auditing firm Omniscia said that the code exploited fell outside the scope of their original audit. This was taken as fact in the court of public opinion, but was, in fact, untrue. The post was later deleted.
Ultimately, Beanstalk’s specific problems boiled down to three major factors. First, code being executed via on-chain governance should always be audited for malicious intent. Second, contracts for the LP could have been included in the multi-sig wallet. Finally, the protocol was insufficiently protected from flash-loan attacks.
That said, writing off the attack as idiosyncratic is foolish. To execute, the hacker had to borrow an astounding $1bn. Furthermore, the decision to have funds owned by the smart-contract, rather than the multi-sig, was intentional, in an attempt to actually commit to decentralized governance. If decentralization genuinely remains an end goal of crypto, this problem will have to be addressed at some point. A system isn’t resistant to attack if you need a flyswatter to deflect the system from every malicious advance.
The majority of the codebase was fully audited, and the team had publicly committed to not pushing unaudited code during their cooldown, catching up from an un-audited launch.
The widely accepted solution for flash loan resistance is simply to acquire assets at a scale that it becomes impossible to acquire a supermajority of tokens. This is unwise. With government sponsored illicit operations on the rise, assuming that scale protects from damage is likely false.
So, what are the lessons from Beanstalk for resistant systems and new protocols?
- A flyswatter approach can be incredibly useful in the early stages. Decentralization shouldn’t be seen as binary. Rather, it can be something that a protocol achieves gradually as it captures TVL and scales.
- How can governance avoid unanimous control, but allow itself to evolve? Once you go down the road of immutability, you can’t go back. That’s a very tough line to walk.
- In Beanstalk, token governance had complete control- even Vitalik notes this is untenable.
Post-Beanstalk, there are clear issues with token governance voting. Over the last six months, ve-Tokenomics have rapidly grown in popularity, largely due to their ability to incentivize long-term incentivized thinking by giving tokens power, scaled linearly by the amount of time remaining until their unlock (not the amount of time they were originally locked for). This helps prevent bad actors from capturing majority vote share, and incentivizes governance in the best interest of the protocol’s long-term success.
At the same time, there is a clear opportunity cost for locking your capital up for 4 years. To this end, there is a clear need for meta-governance protocols. Convex was the first to successfully deploy, and it has yet to be imitated properly. A protocol willing to commit to safely and permanently locking tokens may effectively become the subject of acquisition given sufficient scale. Convex has gradually become the overlord of Curve through its majority governance control.
This approach has been successful because it’s fundamentally symbiotic, with dev teams closely aligned. A more vampiric strategy would allow for short-term extraction of value, but ultimately leave the host protocol worse than when they started. For this reason, Curve has adopted a whitelist of just three protocols – Yearn, Convex, and Stake DAO.
These protocols create a wrapper for the CRV token. Using Convex as an example, cvxCRV is the seigniorage component of the CRV token. cvxCRV is liquid and freely tradable, allowing users to buy or sell fractions of Curve yield. Governance is non-transferable, and can only be allocated via bribes in the wrapping protocol. This creates a layer of safety against flash-loan attacks, as governance cannot be immediately purchased on the secondary market.
This abstraction is a key part of Curve’s current functionality. It’s also the primary reason for much of the argumentation around a recent proposal to whitelist liquid lockers for Stake DAO. Proponents argued that whitelisting lockers would provide much needed liquidity to certain pools, reduce centralization of voting power in Convex, and allow end-users more flexibility in voting. Detractors, including a whale that gave comments for this piece, noted that creating voting token liquidity effectively bypasses the Curve Whitelist functionality, and increased susceptibility to MEV and flashloan governance attacks. The proposal eventually passed, with the addition of Time-Weighted Average Voting Power (TWAVP). This allows for liquidity of voting assets, but prevents them from being amassed in scale immediately.
The current meltdown on Fantom has also caused me to fundamentally question the viability of keeping time-locked governance tokens illiquid. In case you’ve missed it, a whale locked up $80mn of liquidity for four years on Solidly and Deus to game emissions. They also deposited ~$40mn of FTM in SCREAM, and borrowed against that position. After Andre left (in part because of frustration due to this) and the market drew down, the whale was left with an extremely unhealthy lending position.
Fantom users and protocols were left with two options – either bail out the whale, or allow a $40mn liquidation to occur with only $32mn of on-chain liquidity. Deus sent $2mn, which the whale used to pay down their debt, but was insufficient to staunch FTM’s bleeding over the past week.
I’m going to pause here to quickly summarize takeaways:
- Liquid wrapping protocols, like Convex, are viable if they are symbiotic with the host protocol.
- Even symbiotic relationships represent a level of risk for host protocol, as they abstract majority governance into a separate entity over which they have no control.
- Illiquidity of time-locked governance tokens is also a huge threat. Finding a way to enable secondary token liquidity, while mitigating flash-loan / MEV vulnerability is key.
Right now, there are two options for decentralized on-chain governance. First, execution / smart contract risk can be put behind a multi-sig, which requires trust on good-faith execution. This sacrifices decentralization, and is fundamentally antithetical to the goal of a DAO. Alternatively, you can hope that your protocol amasses TVL to the point that it becomes financially impossible to acquire a majority stake. However, a project’s success simultaneously increases its risk, as it becomes a bigger honeypot.
As it stands, ve-Tokens are the most effective option on the market for aligning party interests. However, given liquidity on the secondary market of tokens, and the ability through flash loans to acquire large amounts of cash and simultaneously execute, scale becomes untenable. Convex accomplishes this by splitting out the governance and yield generating aspects of the token, but ideally, we’d have a liquid solution for both that doesn’t centralize governance power outside of the founding protocol.
One of the strategies brainstormed was using a CRV-esque timelock, but with the addition of a max balaceOf() function. This would allow wrapper protocols to create secondary liquid markets around both governance and seigniorage, but would prevent any one wrapper from amassing a majority stake in governance. Alternatively, it would prevent a large amount of MEV risk, as coordinating flash loans across multiple wallets becomes significantly more difficult. If the founding protocol isn’t averse to having governance centralized in a host protocol, TWAVP presents a good alternative to ensure MEV/loan risk is minimized.
Ultimately, the answer (like very few are) is probably not binary. As an early proposition, a tiered strategy would probably be appropriate:
- For early stage projects (low TVL, minimal honeypot risk) with known teams- a multisig allows for quickest execution, but places a reduced priority on decentralized governance.
- Middle stage projects begin the transition to decentralized governance, but keep governance and smart contracts under control of the multi-sig, to remove MEV/Flash Loan risk
- More mature projects transition to coin voting. Depending on the goals of the project, it may never remove execution from the smart contract (to minimize risk). Projects focused on decentralization as a primary objective, use
At any stage, TWAVP and maxBalanceOf() can be used to reduce risk from a majority token holder attack. In any case, I’d like to see more tokenomic development increasing the fundamental security of protocols.
This report is not investment or trading advice. Please conduct your own research before making any investment decisions. Past performance of an asset is not indicative of future results. The Author may be holding the cryptocurrencies or using the strategies mentioned in this report.