Mechanism Description

How does Oval Actually work?

Each time a price update creates a meaningful change in a downstream integration (price update that makes a liquidation possible, for example), a transaction can be sent to make the newest price available to the integration via the destination adapter. This bundle is sent to an Oval node by searchers looking to extract OEV.

Permissioned auction unlockers

Only permissioned addresses can send a transaction to unlock the newest price. The permissioning is restricted via the integration controller canUnlock method. This requirement is an artifact of using MEV-Share as the backrunning auction mechanism. When an MEV-Share transaction is submitted it is up to the submitter (the “user” who is backrun) to specify two main things: a) the kickback address and b) the kickback percentage. Oval is designed to kickback the rewards to the integrating protocol. The current MEV-Share implementation provides no way to verify (a) or (b) onchain and so there is no ability to enforce that the kickback parameters are set correctly. To simplify this problem, Oval introduces a set of trusted actors who call the unlockLatestValue method on the Oval contract. These actors are called Oval nodes. This makes the latest value from the source oracle available for consumption. It is up to the Oval nodes to set the parameters of (a) and (b) correctly. While using permissioned actors is not entirely ideal, they cannot modify the prices nor significantly delay them, so they cannot harm the onchain operations of the protocols that receive prices via Oval. UMA is doing active research to implement Oval as a SUAVE app and remove these trust assumptions. These trust assumptions and the implications are described in detail here.

Parallel auctions

Oval can support distinct parallel auctions for separate integration contracts. For example, assume the ETH/USD price is updated, resulting in a liquidation in both Compound and Aave. Oval will enable each of these updates to run simultaneously to correctly attribute the OEV extracted by each integration. Without this property, the OEV from Aave and Compound would be muddled, making it impossible (or very difficult) to correctly distribute the OEV to the protocol that created it.

This property is one of the main reasons that each integration has their own associated Oval contract deployment. This means each Oval deployment only needs to worry about a single integration, which greatly simplifies the system.

Controlling when to release what price

Oval works by controlling when to make the newest price available. It does this by tracking the last time unlockLatestValue was called. The following casework is used to determine what price to return, where lockWindow can be customized for each Oval deployment:

• If unlockLatestValue has been called within the last lockWindow seconds then return the most recent price as of the unlockLatestValue call.

• If unlockLatestValue has not been called in the last lockWindow seconds, then return the most recent source value that is at least lockWindow seconds old.

This casework amounts to providing a time buffer around a new source update for the Oval node to call unlockLatestValue.

This introduces two clear failure modes that need to be considered: a) what happens if MEV-Share breaks or b) what happens if no Oval node calls unlockLatestValue. Both amount to the same failure mode: a small delay in liveness of updating the system and MEV going entirely to the block builder, as it does today.

In the happy path, the call to unlockLatestValue can happen within the same block (or subsequent block) of the oracle update and so should not cause a significant (if any) delay. In the unhappy path a price will be, at maximum, lockWindow delayed from being released to a downstream consumer.