Don’t freak out. Yet.
Let me start by saying don’t freak out. This vulnerability allows users to gain more votes than they should have, but it likely won’t result in full governance takeovers alone yet and only becomes a real pain with upcoming advancements.
We’ve contacted many protocols to warn them about this problem. Some have paid out bounties (namely ENS and PoolTogether) and others apparently did not care because it hasn’t occurred in the wild. Yet.
The point of this article is to bring attention to what will become a problem before it is a problem. We believe talking about it publicly won’t cause any harm and will spur communities to upgrade their governance more so than private reports.
Background
I’m the director at Ease (ease.org), a novel coverage protocol. We’ve dedicated the last few years of our lives to Ethereum security. We have a lot of skin in the DeFi security game. I’ve got tattoos commemorating whitehats to back that up.
In line with @armorfi's mission to protect DeFi users, I personally launched the Founders Bounty early this year on @immunefi to reward whitehat hackers who found critical bugs anywhere in DeFi with $ARMOR and a tattoo. Here are some of 2021’s whitehats at a glance (of my thigh): pic.twitter.com/GibY8UsZwv
— Robert M.C. Forster (@RobertMCForster) December 28, 2021
I’ve written active security bots, lived off bug bounties, and paid millions to whitehats. We’ve ran coverage protocols and the largest DeFi underwriting pool. And we’ve spent thousands of hours researching risk in DeFi to learn how to create the best ways we can protect users from DeFi hacks and scams.
At Ease, we’ve recently been working on extending our runway through bug bounties. In a month and a half, we made a bit over $80k from bounties on Curve, GMX, ENS, Frax, and PoolTogether.
Bragging to pretend we’re smart aside, we do know DeFi security and its history.
The Vulnerability Today
One thing we focused on while hunting was Multi-block Maximum Extractable Value: MMEV.
MMEV is when validators know they have full control over multiple blocks in a row, and can therefore do things that would previously be extremely risky, such as manipulate a token price in one block and correct it in the next. It’s a concept that’s become much easier with PoS, and we figured there was potential for widespread bugs involving it.
Although TWAPs are the biggest weakness –that we’ve found so far– brought on by MMEV, there are more. The most widespread weakness is what this article is about: MMEV in the Compound Governor models.
- Many governance contracts rely on counting a user’s votes at a specific block.
- This check is always done on a block before the vote is cast to avoid flash loan attacks and voting with the same tokens on multiple addresses.
- Additionally, governance contracts have a “delay” for how long after a proposal is submitted its voting begins.
- Once a vote begins, the amount a user may vote with is their balance on the start block (which must be at least 1 block in the past at the time of voting).
The 1-block delay problem
We’ll start with the 1-block delay that is used by many protocols today.
The 1-block delay poses an immediate threat to protocols. It allows a user that can take advantage of MMEV to:
- purchase all liquid tokens on dexes,
- record their vote, and then
- sell the tokens on the next block.
The only spent cost for a user to vote with all tokens on dexes would be exchange fees.
The detailed steps are as follows:
- Validator sees that they have 2 blocks in a row.
- They open a proposal (must have enough tokens to do so) on the block before the first “owned” block. The start block is set to block.number+1 because the governor contract has a 1 block votingDelay.
- They buy every token possible on dexes–even with large slippage–on startBlock.
- On startBlock+1, they sell the purchased tokens back to dexes, ending up only paying exchange fees. Because of MMEV there is no risk they lose anything to arb bots.
- They vote on the proposal with every token that was for sale on dexes at any time during the proposal (possibly in the last second).
Without MMEV this is incredibly risky because an arbitrage bot will almost surely stop you from being able to sell back the tokens used to vote at any reasonable price. With MMEV there’s no risk and the only spent cost is the same as if you could vote with flash loans.
You need $ to make $
The caveats today are that you must have:
- adequate validators to execute this attack,
- the capital to initially purchase tokens.
An amount of validators to execute in a timely manner would cost upwards of $20M. This may sound like a lot of money, but bad actors have continued to gain more and more capital to execute attacks like this.
Not to mention someone taking advantage of MMEV may not be trying to pass a malicious proposal at all but rather just an average user who wants to amplify their vote on a certain proposal. It has the exact same effects that flash loans have had on voting in the past.
It’s important to keep in mind that if an individual today is trying to take advantage of MMEV for things such as:
- manipulating TWAPs to shutdown Compound’s price feeds for a bit,
- starting a proposal on Maker that they want many extra votes on, or
- trying to manipulate dexes for off-chain aggregators and finally Chainlink to return bad data,
they can do all of these in one block rather than needing to wait a couple months to have the chance at each.
The Vulnerability Tomorrow
The previously mentioned validator requirement may disappear in the future. A few years ago, many protocols did not accept bounties regarding (single-block) MEV because it was unlikely a miner would sacrifice their reputation to take advantage of it. Once protocols like Flashbots came about, that all changed.
The same may happen here. If MEV protocols like Flashbots begin to incorporate multi-block MEV, suddenly the cost of validators is eliminated and the likelihood that you can control 2 blocks in a row on any specific block skyrockets.
This advancement then makes governance with a large voting delay more vulnerable. Because a user still only needs to hold the voting tokens over a 1 block timespan. You can simply wait to see whether the starting block of a proposal and the one before it are able to be MMEV’d.
Anyone in their right mind who is willing to pay a bit for a proposal to pass and does not want the other side to do it should take advantage of MMEV to get all dex votes on their side.
Severity
The severity of this problem doesn’t come from the damages themselves, but from the criticality of the contracts it damages.
- Will someone be able to fully take over governance by exploiting MMEV? Likely not. People can still vote against them and often there are further measures to stop malicious proposals from getting passed.
- Will someone be able to take advantage of code to gain a huge voting advantage for cheap? Absolutely.
- Will that advantage be the tipping point in a crucial matter? Maybe.
- Will such action erode confidence in your protocol’s governance? Likely.
Recommendation
Our recommendation would be to have some sort of locking on your governance/voting token.
For example, gvTokens and veTokens are generally not vulnerable to this. Maker would also not be vulnerable if they increase the required time a user has locked tokens to higher than 32 blocks.
A longer delay on voting being started is helpful for now but will not be if in the future most blocks are able to be MMEV’d. Each protocol has its own requirements though and must fix this in the way they deem best.
Conclusion
The point of this article isn’t to say the sky is falling. The point of this article is to make sure our ecosystem is as safe as it can be. With flash loans and MEV, teams ignored upcoming advancements which potentially made their fairly safe contracts suddenly easily exploited.
Multi-block MEV is something that should be focused on now so it is never a problem in the future.
