RPIP-58: Mev Penalty Guardrail

Governance
1

This is the official discussion thread for Draft RPIP: Mev Penalty Guardrail. Some prior discussion has taken place on Discord. This RPIP is targeted at the next smart contract upgrade (Saturn 1).

This idea originally came from my oDAO research that the GMC funded last year and wasn’t picked up for Houston. The goal is to limit oDAO power to an appropriate level and massively reduce the trust assumption for node operators.

I’d love to get useful feedback. No sentiment poll for now to allow for pDAO input first.

Edit: Merged RPIP here.

10 Likes
2

This work has been criminally neglected. I’m so glad to see progress on getting these guardrails implemented.

3

If the Oracle DAO gets compromised they can upgrade contracts and steal all funds. But there will be a 7 day delay during which you can exit.

However, there’s no delay or limit for applying penalties. A compromised Oracle DAO could penalize all ETH in hours/days. With this proposal the damage is limited to 2% per week.

oDAO doesn’t need to collude to become compromised. A supply chain attack on Smart Node could compromise oDAO nodes.

I think it makes sense to have this guard rail and I support this.

4 Likes
4

The 2,500 threshold is well reasoned and I can find no issues with the draft. The MEV Penalty Guardrail fulfills an important missing piece in protecting operators and the protocol from adverse behavior.

5

With the combination of forced exits and delegate upgrades likely coming with Saturn, along with the existing penalty system - this guardrail is frankly a critical peice to keeping the trust assumptions placed in the ODAO contstrained. I heartily support this proposal and would like to see it in Saturn along with everything else.

1 Like
6

Sentiment poll:

RPIP: Mev Penalty Guardrail
  • Support moving to vote; this is great
  • Support moving to vote; this is good enough
  • Abstain
  • Oppose
0 voters
7

Awesome. Limiting oDAO power is a good first step.

Ideal is removing oDAO duties and eventually the oDAO itself.

2 Likes
8

This assumes that it is the oDAO that penalises and that the trust model is full trust.

There is a small chance that this could be implemented using a state proof - in which case it changes the trust model and the guardrail is not necessary. That said, it relies heavily on how penalties are detected and whether a state proof can/should detect the amount of stealing.

If we remain with a full trust model then I think the a guardrail is sensible.