Most Governance Contracts Have an Upcoming Vulnerability We Should All Pay Attention To – Don’t Freak Out, Yet

HodlX Guest Post  Submit Your Post

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.

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.

The vulnerability today

One thing we focused on while hunting was MMEV (multi-block maximum extractable value).

A concept based on MEV, an 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 one block in the past at the time of voting.

The one-block delay problem

We’ll start with the one-block delay that is generally used today.

The one-block delay poses an immediate threat to protocols. It allows a user who can take advantage of MMEV to do the following.

• Purchase all liquid tokens on DEXs
• Record their vote
• Sell the tokens on the next block

The only spent cost for a user to vote with all tokens on DEXs would be exchange fees. The detailed steps are as follows.

• Validator sees that they have two 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 one-block votingDelay.
• They buy every token possible on DEXs – even with large slippage – on startBlock.
• On startBlock+1, they sell the purchased tokens back to DEXs, 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 DEXs 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 cost spent is the same as if you could vote with flash loans.

You need money to make money

The caveats today are that you must have the following.

• 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 $20 million.

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.

An individual today trying to take advantage of MMEV would do so for the following purposes.

• Manipulating TWAPs to shutdown Compound’s price feeds for a bit
• Starting a proposal on Maker that they want many extra votes on
• Trying to manipulate DEXs for off-chain aggregators – and finally, Chainlink to return
  bad data

It’s important to keep in mind that 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 two 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 one-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 may 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 the affected protocol’s governance? Likely.

A possible precaution

A precaution for now would be to have some sort of locking on your governance/voting token.

GvTokens and veTokens are generally not vulnerable to this.

Some protocols like Maker, for example, 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.

Robert Forster is the CEO of Ease.org, a novel coverage protocol. He has written active security bots, lived off bug bounties and paid millions to white-hats. Robert and his team have dedicated the last few years of their lives to Ethereum security.

Featured Image: Shutterstock/KumaSora/WindAwake