[TEMP CHECK] Integrate Oval for the BAL & SNX Ethereum V3 Markets

[UMA]

For a liquidation transaction not to be included, the block needs to be full and the lowest tipping transaction in the block needs to be higher than the tip for the liquidation transaction. This is unlikely in practice as the vast majority of transactions do not pay a significant builder tip while typical liquidations pay orders of magnitude more than what is needed for inclusion.

It is also worth mentioning that even though the percentage of the payment going to the builder decreases with Oval, the amount the builder receives is still proportional to the searcher’s payment. This means that, just like before, the larger the liquidation, the larger the incentive for the builder to include the transaction. Searcher payments are high today because they are competing with one another, not because inclusion is that expensive.

[UMA]

@kydo Thank you for your support for our TEMP CHECK proposal. We will incorporate your comments comments if this is passed on to ARFC.

@Table Thanks for sharing your concerns.

The offchain Oval Node is only relied upon for liquidations within the configurable lock window time period from the latest Chainlink price. After that short time period, liquidations proceed without any reliance on the Oval Node. This fallback is coded into the onchain smart contract.

The Oval Node code is public. If the node is down or has a bug, liquidations will proceed after the lock window. If the node is malicious, the only thing it can do is capture the MEV that Aave does not currently capture. Aave DAO can choose to remove Oval at any time.

[lbsblockchain]

This proposal has generated a LOT of healthy discussion and it is undeniable that there is a lot of benefit in Aave exploring solutions to tackle OEV going forward. I’d also like to commend the UMA team, especially @hal2001 and Bobby for endlessly engaging with and explaining the various facets of the Oval solution to me.

In my opinion, for a topic as sensitive as OEV, which will impact a core part of the Aave protocol (liquidations) from a risk and security perspective, I believe a more comprehensive framework and program is needed to find the most appropriate solution for Aave. While I think that the Oval solution has significant merit, the security implications have just not been explored enough and there has been no comparison with any other solutions - for example, the ones proposed by @MarcZeller above. Even if Oval may win out against those solutions, I feel it is important for a DAO as large and mature as Aave that a proper, streamlined process is implemented which allows Oval to win out on its own merits rather than by virtue of being the first solution presented, even if it may end up being the best solution at the end of the day.

As such, it would be better to structure and run a comprehensive framework and program to craft an OEV solution that is most suited to Aave’s requirements (e.g., cross-chain, completely decentralised, etc.). The program should include all of Aave’s key stakeholders (e.g., BGD Labs, ACI, Gauntlet, Chaos Labs, etc.) along with providers who have built or expressed an interest in building solutions to tackle OEV (UMA, Chainlink, etc.). While passing this TEMP CHECK would enable Oval to be analysed by Chaos Labs and Gauntlet, it may be better to not conduct this assessment in a silo with specific requirements attached (e.g., the suitability of deploying Oval on the BAL/SNX markets). Rather, it would be better to allow multiple solutions to be presented, qualified out, and judged in comparison with each other.

On the other hand, given how this proposal has opened up a critical topic for Aave and the clear effort the UMA team has put into designing Oval, along with the clear merits of their solution, it would be extremely unfair to vote this TEMP CHECK down.

Therefore, I will ABSTAIN on this proposal but look forward to working together with all Aave stakeholders and the UMA team to craft an OEV solution that is closely aligned to the Aave protocol’s unique requirements.

[Nandy.eth]

This proposal is part of the hardest to vote in.

After evaluations, I will support (edit: out of voting window ) it yet on it current shape. There are good pros and the tested market correspond to me to an acceptable spot. Yet I will not support a generalisation of this “strategy” without result on 3 to 4 black swans in the space of security Aave needs to improve to stay at top but it must be aware as @MarcZeller said that optimisation don’t introduce an under-estimate risk for the protocol.

[ACI]

After Snapshot monitoring, the following TEMP CHECK Snapshot has ended, with both Quorum and NAY as winning option, with 429K votes.

Therefore, the TEMP CHECK Snapshot has not passed.

[hal2001]

Hey all, I’m the founder of UMA and my team wrote this original proposal.

Although this proposal didn’t pass, I want to thank to everyone who engaged in our discussions about Oval. Your enthusiasm, insightful questions, and feedback have been very valuable. This comments in this discussion emphasize that OEV capture is an important topic for Aave DAO, and we are excited to see where this goes.

From UMA’s perspective, this is the start—not the end—of our collaboration with Aave. We’re keen on helping Aave explore OEV capture solutions with all the relevant stakeholders. Whether it’s through Oval, OEV, or any other related concepts, our team is here to share our insights, foster discussions, and collaborate on developing solutions that benefit the whole DeFi ecosystem.

Thank you once again to everyone who has contributed to the conversation.