Title: [TEMP CHECK] OEV Exploration Framework
Author: Areta
Date: 2024-04-04
Summary
This proposal seeks to create a framework for Aave DAO to begin the exploration and design of solutions that capture Oracle Extractable Value (OEV) for the benefit of the Aave protocol and are fit-for-purpose for the specific requirements of the Aave protocol.
We would like to thank Bobby Bola from UMA for his collaboration and thoughts on the proposal. We would also like to thank @EzR3aL, Certora, @noturhandle, @eboado, @MarcZeller, @0xJChen, Halcyon Price from Chaos Labs, and Will and Roger from Chainlink for reading through the proposal and providing their feedback.
Motivation
Aave DAO should consider investing resources and time to explore OEV solutions and build its own roadmap and strategy for capturing OEV, which is a Pandora’s Box that has been now opened, and that Aave DAO should benefit from. This initial OEV research looks for ways to return value to Aave DAO.
As seen with the discussion around the Oval proposal by UMA which kick-started the discussion around OEV, there was a lot of interest within the DAO to understand how Aave can potentially benefit from OEV capture. However, the primary feedback to the Oval proposal consisted of the following elements:
- The revenue estimates required more analysis from the Aave community and contributors.
- Oval is a ‘generic’ solution which proves the benefit of OEV capture but may not be applicable for Aave’s needs.
- Given the criticality of OEV, multiple teams should be involved in the development to build such a solution for Aave and there should be a formal framework in place for Aave DAO to review the teams involved and select the most appropriate members for Aave’s purposes.
- Furthermore, there are other possible ways to capture OEV as example, @MarcZeller proposed various solutions in his response on the Oval thread that could be explored further.
- The question of how Aave DAO should distribute captured OEV is up for debate - whether it should go only to the DAO, infrastructure providers, AAVE token holders, other stakeholders, or combinations of these groups.
To that end, this proposal aims to create a structured process via which Aave DAO can tackle all of the above issues identified in the Oval discussion and craft a bespoke OEV capture solution for the Aave protocol.
Specification
- What is OEV?
- OEV Exploration Framework
- Timelines
- Cost
- Next Steps
What is OEV?
Aave incentivizes third parties to liquidate Aave debt positions that have become distressed through a liquidation bonus. These liquidations generate enough profit that MEV searchers compete to liquidate transactions immediately after Chainlink price feed updates.
The current MEV tooling landscape lacks a common mechanism to capture this kind of MEV, called Oracle Extractable Value (OEV). Instead, the majority of the value eventually flows down the supply chain to block builders and validators. It starts when searchers bid to backrun the oracle update by placing their transaction immediately after the update, enabling them to perform the profitable liquidation. These auctions are competitive, so a searcher bids the majority of their profit to have their bundle included, thus ending up passing the majority of the value down the supply chain.
In particular, when a price update catalyzes a liquidation, a significant chunk of risk-free profit is turned into MEV. This MEV from Aave liquidations, OEV, has benefited searchers, block builders and validators, but not Aave protocol or its users.
Aave DAO should aim to capture this OEV.
OEV Exploration Framework
This framework will consist of the following components:
- Creation of OEV Working Group
- Discovery Phase
a. Requirements definition
b. Implementation timeline definition
c. KPI definition
d. Research Submission Window
e. OEV Solution Analysis
f. RFP Definition - Solution Submission Window
- Solution Review & Discussion Window
- Solution Selection
- Ongoing Monitoring & Engagement during Development and Implementation Phase
Creation of OEV Working Group
There are several reasons why it is important to create a working group that guides Aave DAO’s research into OEV and selects an appropriate solution:
- Security is at the heart of the Aave protocol and it is what has distinguished Aave as one of the flagship DeFi protocols. These high standards have been maintained by Aave DAO historically trusting a core set of contributors to manage Aave’s infrastructure and keep a close eye on any changes to the protocol that will impact its security. It is crucial to involve BGD Labs in any discussions related to OEV and Aave’s ultimate selection of an OEV capture solution.
- Liquidations are a critical part of Aave’s infrastructure and security and any changes to Aave’s liquidation mechanism must be well thought out and deliberated upon by experts who are keenly familiar with the Aave protocol and its mechanisms.
- This is a deeply technical solution which requires inputs from a number of experts, including those well-versed in MEV/OEV, risk service providers like Chaos Labs, and security experts like Certora.
- It will take time to research OEV and review and select the appropriate solution for Aave. The process will involve liaising with external stakeholders (e.g., oracle providers like Chainlink who will be critical during the requirements gathering and phase, but may want to propose a solution themselves, and the Aave treasury managers to define how to distribute any captured revenue across stakeholders). Therefore, it is important to have an entity managing the operational aspect of the working group and ensure that timelines and deliverables are adhered to.
We propose a 5-member working group that will be elected by the community. We believe the working group must have the below 5 team profiles:
- Aave Security Team: BGD Labs [set member]
- Security Service Provider: Certora [subject to governance / open election]
- Risk Service Provider: Chaos Labs [subject to governance / open election]
- MEV Expert [subject to governance / open election]
- Operational Manager [subject to governance / open election]
While we have suggested parties that we deem skilled for the job, we believe that the election of the profiles for the OEV Working Group should be subject to governance (apart from BGD Labs). As such, applications for the OEV working group should be solicited on another forum post that we will create based on feedback from the community to this proposal, and the election of the OEV Working group should occur via a single Snapshot vote.
The election will consist of a 7-day submission period for the interested applicants, with a Snapshot vote determining the members of the working group.
We welcome feedback from the community on the definition of these roles and whether other types of profiles are required.
Discovery Phase
Once the OEV Working Group has been elected by governance, the Discovery Phase will commence for a period of 3 months (12 weeks) and constitute the following elements:
- Requirements Definition
- Implementation Timeline Definition
- KPI Definition
- Research Submission Window
- OEV Solution Analysis
- RFP Definition
The timelines presented in the below breakdown are tentative estimates and are subject to change based on input from the community.
See details below.
1. Requirements Definition
Given the bespoke nature of the solution that needs to be crafted, the OEV Working Group will define the requirements for the solution, e.g., cross-chain, no centralisation, etc.
Note: Steps 1-4 will be conducted in parallel over a 4-week period.
2. Implementation Timeline Definition
The OEV Working Group will define the phases for the solution to be rolled out (i.e., OEV Analysis, PoC, pilot, MVP), and the time that each phase will take place for.
3. KPI Definition
The OEV Working Group will define the KPIs that the proposed solution must meet in each of the phases defined in the implementation timeline (PoC, pilot, MVP, etc.).
4. Research Submission Window
Current OEV solution providers can submit their solutions to the DAO to be analyzed by the OEV Working Group. This will assist Aave DAO in designing their RFP in future steps.
5. OEV Solution Analysis
The OEV working group will have a 4-week period to analyze the OEV solutions and present their findings to the DAO. These findings will be used to help inform the DAO and the OEV working group to define the RFP.
The aim of this window is to understand the current solutions in the market to inform the RFP definition phase below.
6. RFP Definition
Next, the OEV Working Group will define an RFP that will be sent out to various solution providers to submit their OEV solutions to the Working Group. The RFP will be defined over a 4-week period.
Solution Review & Selection Phase
Solution Submission Window
Interested applicants can submit OEV capture solutions to the Working Group over a period of 4 weeks. This window is subject to change depending on input from the community and based on feedback from the OEV Working Group.
Solution Review & Discussion Window
The OEV Working Group will review solutions and engage in discussions with applicants over a period of 4 weeks. This window is subject to change depending on input from the community and based on feedback from the OEV Working Group.
This stage will include an analysis of the revenue potential that Aave DAO can realise from each presented solution. The OEV Working Group will conduct a high-level analysis of the revenue Aave DAO could stand to make from implementing an OEV capture solution and will recommend options for distributing this revenue across the various stakeholders.
Solution Selection
The OEV Working Group will select the most appropriate solution, and will make public their rationale for doing so. The selected solution provider will be ratified via the governance process.
Development and Implementation Phase
Ongoing Monitoring & Engagement during Development and Implementation Phase
The OEV Working Group will maintain oversight of the solution provider and will aid them during the solution development and implementation phase. The Working Group will ensure that the solution delivery is tracking to timelines and will update the community regularly on progress.
Timelines
Each working group member serves a term of two quarters (6 months). At the end of each term, the effectiveness and impact of the working group will be reviewed by Aave governance. The initial term commences at the start of the Discovery Phase and ends with the Solution Selection & Ratification phase; it also includes a 2-week buffer phase for a total of 24 weeks.
Please see below for a more detailed view of the timeline. The suggested times serve as rough guidelines for the concrete activities discussed and can, to some extent, be conducted simultaneously to meet the 6-month deadline.
| Time | Activity | Notes |
|---|---|---|
| 2 weeks | Discussion Period | This proposal will be discussed for a period of 2 weeks and community feedback will be obtained and implemented. |
| 3 weeks | OEV Exploration Framework Governance Process | This proposal will be escalated to the Snapshot phase, then the ARFC phase, and then the AIP phase. |
| 1 week | OEV Working Group Applications | A forum post will be created where applications can be submitted for the team profiles. The forum post will be locked after the 1 week period. |
| 2 weeks | OEV Working Group Selection via Governance Process | Selection via ARFC and AIP. |
| 12 weeks | Discovery Phase | |
| 4 weeks | Solution Submission Window | |
| 4 weeks | Solution Review & Discussion Window | |
| 2 weeks | Solution Selection & Ratification | |
| Ongoing | Monitoring & Engagement | The budget requirement for this phase will be lower as the team required will be leaner, and is not included as part of this proposal. |
The above timelines are subject to change based on community feedback.
Cost
Each applicant to the OEV Working Group will submit a cost for their services as part of their application. This will enable the community to weigh the applicant’s cost along with their expertise as part of the election process.
Next Steps
- If consensus is reached on this [TEMP CHECK], escalate this proposal to the Snapshot stage.
- If the Snapshot outcome is YAE, this proposal will be escalated to ARFC stage.
- Publication of a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage.
- If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.
- Once this AIP is enforced, a forum post will be created to solicit applications for the OEV Working Group.
- The selection of the OEV Working Group will occur via governance (ARFC and AIP).