Trust Assumptions
The Oval system has a number of trust points.
Last updated
Was this helpful?
The Oval system has a number of trust points.
Last updated
Was this helpful?
The system has three points of trust to consider:
Protocols trust the Oval nodes to process bundles and set refund instructions correctly.
Oval trusts the Flashbots MEV-Share system not to unbundle or leak MEV from backruns.
Oval and MEV-Share trust that block builders will respect MEV-Share's building rules.
If the trusted actors become malicious they can do two things: 1) use incorrect refund preferences in the MEV-Share bundle submission, enabling them to steal the OEV for a given update or 2) censor/delay the call to unlockLatestValue, thereby slowing down the updates of the protocol.
Importantly, neither 1 nor 2 is likely to damage or disrupt the operation of most protocols that rely on a supported source oracle. The protocol would lose revenue (that goes to builders today) and there may be a small slowdown in price updates.
Problem 2 can be mitigated somewhat by having multiple independent Oval nodes operating as part of the unlockers set. The downside of this approach is that it increases the risk of problem 1 as there are now more actors who can steal the MEV. For example if Alice, Bob, and Charlie are all part of the unlockers set for a given integration any one of these actors could steal the OEV from the integration.
Finally, if these actors do become malicious, they can be removed from the list. Given that each integration has their own Oval deployment the permissions to remove actors from the unlockers could be governed by that protocol's governance process.
The MEV-Share node is trusted to not leak the unlockLatestValue transaction sent by the Oval node or steal the MEV by backrunning the update with different refund preferences. In both cases, the OEV would be stolen.
MEV-Share is also trusted to abide by the settings defined by the permissioned actor. In theory, the MEV-Share node could change the preferences defined by the caller, causing OEV to be stolen.
Lastly, the MEV-Share node is trusted to send the correct backrun payload along with the unlockLatestValue to the selected block builder(s).
MEV-Share misbehaving is very similar to the permissioned actor misbehaving: lost revenue and . If this were to happen, Oval could be disabled by governance and replaced with a passthrough.
Once the builder receives a bundle containing the unlockLatestValue and the associated backrun transaction from MEV-Share, they are trusted to not separate the transactions, as this would allow them to steal the OEV for themselves.
The Oval node chooses what builders they want to enable when forwarding the bundle to MEV-Share. If a builder is found to be behaving badly, the permissioned actor can remove that builder from the list, depriving them of future revenue.