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…