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

Thank you. We’re grateful for your support and feedback.

As Wintermute mentioned, we want to emphasize that moving beyond the TEMP CHECK to the ARFC phase indicates an opportunity for Aave DAO to allocate time and resources, including analyses from Gauntlet or Chaos Labs. Our team has conducted preliminary internal research regarding the matters raised by Wintermute. With that in mind, we’re eager to collaborate with Gauntlet, Chaos Labs, and others during the ARFC stage.

As per our conservative approach with the pilot program, we will be taking a similar approach with the Aave governance process and hope this shows our commitment to building with Aave DAO in a research-driven process. We’re here for the long haul and hope to work with Aave DAO for the foreseeable future.

1 Like

Important Mechanisms and Concepts prelude:

When a user HF drop below 1 anyone can pay back debt on behalf of said user up to a fixed % of total debt (Close Factor, in Aave that’s 50%).

When a user is liquidated, the protocol earns 10% of the liquidation bonus ( ⇒ Liquidation Protocol Fee).

They do it because they collect a liquidation bonus from the user’s collateral (this is equivalent of buying collateral with debt assets below market price.

The market price is defined by oracles (Price feed) they’re medianizer operators run by Chainlink using a mix of Onchain & Offchain sources…

Liquidation bonus are set too high on most cases, because risk parameters are not dynamic but fixed (these parameters can be changed by governance vote but it take days to go through several governance stages before completion).

Thus, the liquidation bonus needs to be large enough in 1% volatility events when they’re needed in full == we overpay 99% of the time by design to save protocol when we need the max LB to protect the protocol.

Since liquidations are permissionless (= can be done by anyone in the world) it’s a profitable & predictable on-chain action, meaning they are subject to MEV (formerly known as Miner Extractable Value, now max EV as we switched to PoS from PoW).

This result in a highly competitive market with only few actors able to “bribe” validators (via relays/builders) generating most profits.

The liquidation process can be optimised by replacing the MEV actors by a centralized actor (UMA OVAL Model) or a set of permisionned actors (old MakerDAO permissioned liquidation system)

This thread explained OEV concepts quite well. It is a viable option to consider.

This solution is profitable for the protocol but add centralization tradeoffs in the most critical piece of protocol infrastructure & bring a third-party in the core of the protocol reactor engine.

A second solution can be explored by creating several liquidation ranges replacing the fixed point “liquidation threshold” by several incremental “liquidation threshold” points placed above the regular LT, we can soften the liquidation impact on the user position, a first soft liquidation can have a lower Liquidation Bonus and a lower Close Factor, if it’s not economical to liquidate the user position, liquidators can decide to wait whether the user position HF drops into another liquidation range. with a higher LB & CF.

This creates a game theory situation; waiting in a highly competitive “winner takes all” market is increasing the odds of having a competitor “accept the deal” and liquidate the user position first, shooting the user HF above 1.

A liquidated position with a lower LB and CF impacts the user less. However, this implies that their position might start to be liquidated slightly earlier than in the current system; this is a tradeoff to consider.

This second solution inspires itself from the Curve crvUSD model but makes ranged liquidation “optional” instead of a more automatic process in the curve ecosystem. this implementation would be easier to implement than curve model in current Aave architecture & more fitting to current Aave protocol liquidation paradigm.

A third simpler solution would be to explore “dual LT mechanism”, with two LT: one “soft” and one “normal”.

The soft LT is placed higher than the normal LT and allows anyone to “pre-liquidate” a user for a reduced LB and CF, the difference between the soft LT & LB and the “normal” LT is shared back between the user and the protocol, resulting in lower overall liquidation cost for the user liquidated, and higher fee earned for protocol.

This solution is straightforward to implement (another liquidation method to call, additional risk parameters to consider in protocol), generates the same game theory environment profitable for protocol & user and have the failsafe to revert to “normal” mechanism if user HF deteriorates further to lower than **1**. This solution does not imply additional centralization or update on the oracle infrastructure.

The ACI is more favorable to this solution as it’s a balanced approach considering implementation complexity, added DAO revenue, softer impact on liquidated users & protocol decentralization.

Many other designs can be explored; we have a keen interest in these protocol optimizations at the ACI.

Regarding the overall discussion in this thread, we consider it alarming that the most critical piece of Aave protocol infrastructure has been so lightly & casually discussed.

Price feeds are how the protocol understands the fair value of collateral and why users are rightfully liquidated to protect the Aave LPs deposits.

The liquidation process is the first & main line of defense of the protocol, if liquidation are not keen to accomplish their mission, there’s simply no way for the protocol to prevent excess debt forming.

If the collateral value doesn’t increase on it’s own after this, the next line of defense is the Aave & GHO staked in the safety module.

Exceptional claims call for an exceptional burden of proof. Having the Aave delegates being influenced by a few fancy numbers and DMs is below our expectations for this DAO.

”which could have generated up to $62.2MM (Jan 2021 to Jan 2024)” is at best an overinflated optimistic statement.

During this period, we had the Celsius collapse event, the StETH depeg event, the FTX collapse, the Terra Luna collapse & the whole bear market, and more than $6B of liquidations in a few weeks.

It’s very likely that during these events, the “too high” LB was deeply needed and the only reason we didn’t end up with Billions of bad debt in the protocol. During these events that concentrated most of the liquidation volume, OVAL would have, at best, provided little to no additional DAO income revenue and, at worst, could have delayed the much-needed liquidations, resulting in potentially billions of bad debt in the protocol.

60M$ “theoretical” revenue is less attractive if the cost is billions at risk.

As we say in trading, “past performance can’t predict future outcomes”, if we ask UMA for liquidation figures in the past quarter & potential OVAL revenue, the overall figure is likely less attractive.

Secondly, as the earlier part of my answer pointed out. I invite the delegates of this DAO to be extremely vigilant against “fake dilemma” bias.

It’s not “integrate UMA or waste a $62M opportunity”; there are plenty of options to explore, and this relation is asymmetric.

Uma might potentially widely benefit from the Aave DAO, but the hard truth is that UMA is just one of many options available to the DAO; there’s zero obligation to share the DAO’s potential revenue with a third party. We can implement our own solutions.

Simply put, We, as the DAO, write the protocol rules because Aave Token Holders own the Aave protocol. We can change the protocol’s design as we see fit and think outside the box to create a new system where we win more, more often, and without any need to share.

We will cast a Nay vote to this TEMP CHECK.


The following proposal has been escalated to TEMP CHECK Snapshot.

Voting will start tomorrow. We encourage everyone to participate.


Marc, we appreciate your comments here. We find some of your suggested mechanisms interesting, however we firmly believe that auctions are the best mechanism for determining market clearing prices. Trying to price the cost of liquidating collateral without an auction will leak considerable MEV.

Specifically, we think Oval has considerable advantages over the mechanisms you’ve suggested for the following reasons:

  1. Oval perfectly prices liquidations via auction. The tiered liquidation solutions you’ve suggested create multiple fixed rate liquidation bonuses that do not adjust to the current market conditions liquidations face; this means these solutions cannot price liquidations with maximal efficiency.
  2. Oval doesn’t increase collateral requirements for users. A tiered liquidation strategy also decreases the capital efficiency of the protocol as the ‘soft liquidations’ would need to start at a higher HF than the current liquidation HF.
  3. Oval requires no changes to AAVE’s core contracts, no re-audits, and no redeployments. The mechanisms you’ve suggested would require an entirely new version of Aave to be written, audited, and deployed. These mechanisms cannot be implemented on current Aave v2 or v3 markets. In contrast, Oval is ready to deploy and compatible with all current Aave markets.
  4. Oval can be easily added or removed from any market at any time. Integrating Oval requires nothing more than changing a single smart contract address via governance. Removing Oval requires nothing more than pointing the market’s price feed back at the native Chainlink contracts. This vastly increases the safety of this piloting OEV capture.

Regarding our proposal, we cannot emphasize enough that we do not consider Oval a perfect solution. However we do think that Oval is a very safe solution that can be used to experiment with OEV capture on these two smaller isolated markets that represent just 0.1% of Aave’s TVL. We embrace and welcome innovation around OEV capture from any and all—that is the web3 ethos. However we firmly believe that Aave can massively benefit from experimenting today with OEV capture in this safe and tightly-controlled pilot program.


When perfection comes at the price of decentralization the cost is simply too high.

That is true but the tiered LT systems stays decentralized and there’s plenty of buffer room in the LTV <> LT gap to experiment with these new systems, we can also have it as an optional layer for users willing to opt-in. (slightly higher liquidation price in exchange for softer blow in case of liquidation is a deal many might consider)

that is a fair point. But each block implementing Oval is a block with the most critical piece of protocol infrastructure in the hands of an third-party. that’s simply outside of our comfort zone.


Hey Marc, I wanted to add a couple additional points to the team’s response above:

As a long time builder in this space, we certainly do not take infrastructure changes lightly! This Oval pilot program proposal has been carefully designed to minimize risks to Aave. We have responded thoroughly and publicly to all questions and comments regarding centralization and risks to Aave in the comments above and in the delegate’s call we hosted. We are a team of nerdy researchers and builders that loves nothing more than publicly discussing our design and its tradeoffs.

Following your post, ACI promoted this TEMP CHECK proposal to a Snapshot vote; we didn’t ask for this and received no communication about this move. From our perspective this vote seems premature as we could benefit from additional discussion with the community. However, we’ll be online all weekend to answer any additional questions from the delegates during the Snapshot voting period.

I’d further emphasize that this is a TEMP CHECK vote to gauge DAO interest in the Oval concept. Quoting the Aave framework: “TEMP CHECKs serve as “temperature checks” to gauge community sentiment on a proposal or topic. They do not necessitate service provider involvement or a high level of precision or technicality.”

From my perspective, this proposal does seem to have captured positive community interest. I have no expectations that passing this stage will mean this proposal will pass the ARFC stage and be fully implemented. However, I do feel like it will be a missed opportunity for Aave if this proposal does not get to the next stage where Aave’s service providers (Chaos and Gauntlet) will respond with their analysis of Oval and its architecture. I believe this analysis will be extremely useful for Aave as it considers its future OEV capture strategy. (And since Chaos and Gauntlet are already contracted by Aave to perform this analysis at the ARFC stage, Aave would get this analysis for “free” if this vote passes).

Lastly, regardless of the outcome of this vote, I want to be clear how excited UMA is to continue to build with Aave. We have been blown away by the interest that Oval has generated, and we are truly grateful for the comments offered here by you and others. UMA will continue to innovate on the Oval design, and we will continue to engage the Aave community for their thoughts and feedback regardless of how this vote goes. LFG.


Hey Marc and delegates:

Given that the voting process has been initiated, we’ll be hosting a Twitter Space before the end of this week to discuss any final thoughts around OEV, Oval, and our proposal.

We want to invite all delegates and stakeholders to join this call. @MarcZeller given your concerns, we’d especially like you to join and we’re more than happy to schedule this around the times you’d be able to attend (we’ll reach out on Telegram to try to find a time that works).

We’ll post details of this call here on the forums.


Gm! I’m Ugur, Strategy Lead at API3. I wanted to provide my perspective on the discussion, as we are building in a similar direction to UMA (and have been name dropped). Before I do, I’d like to clarify that we don’t see ourselves in direct competition with UMA regarding AAVE. Our current solution design would require an oracle change, which the AAVE DAO participants have expressed as an undesired topic.

Regarding MEV solutions, the goal should be to improve user experience. Many solutions currently available for regular users recapture and return most of the MEV available (such as mev-share or mevblocker). Even though Oval is a dApp solution, we should not misunderstand where the money is coming from. The marketing implies it’s “free money,” but it actually comes from AAVE Protocol users’ pockets.

This proposal does not outline how the money should be returned to the users to make the AAVE Protocol more cost-efficient for all users. Instead, it proposes capturing all OEV and distributing it to the AAVE Treasury, UMA (and its partners), and Chainlink. In my opinion, this split misses the purpose of an MEV/OEV solution. The general goal should be to minimize OEV where possible and recapture and return it where it’s not.

This proposal is presenting a solution that would theoretically be capable of recapturing most of the money that users are being overcharged, but it simply redistributes it from one benefactor (liquidators and block builders) to others (AAVE Treasury, Chainlink, UMA). The currently proposed split wouldn’t even allow the AAVE DAO to decide later on to give the majority back to its users. They are merely being promised 50% of the recaptured OEV here.

Overall, I appreciate the innovation happening in the space, but this proposal does not change the status quo for AAVE users. It merely redirects to whom they are losing their money to.


Thanks Ugur. Appreciate your thoughtful comment here. The UMA team has a lot of respect for API3 and your designs—you guys were the inventors of OEV!

Regarding OEV revenue distribution: in full transparency, I think this is a tricky topic. I believe this revenue should mainly go to Aave DAO where tokenholders can choose how to distribute it (they can rebate user liquidation costs; they can rebate gas fees; they can buy and burn $AAVE tokens, etc). But I also believe that the infrastructure providers that provide accurate price feeds (Chainlink) and the OEV capture infrastructure (Oval) deserve some share too, otherwise the mechanism will be unsustainable.

That said, in this proposal we suggested all the revenue from this pilot program be used to fund Aave OEV research. If this pilot were implemented, all revenue would go to a multisig controlled by the Aave DAO.

In my view, this pilot program should be focused on experimenting with OEV capture in a tightly controlled way (aka these two smaller isolated markets). The revenue generated from this pilot will be small. After the DAO gains experience with Oval and OEV capture, then I believe there should be a much deeper conversation of where the revenue should go and how it should be used. The Aave DAO should be the key stakeholder in this discussion, as it is “their” OEV that is being captured. However the timing of this discussion really only makes sense if the Aave DAO chooses use Oval in larger markets; for now, Aave gets all the revenue in this pilot, and I believe Aave should be solely focused on evaluating the Oval technology at this pilot stage.


Saucy block is supportive of this proposal for the following three reasons:

  1. This pilot program is small-scale and risk manageable, and Oval considers it a valuable product to experiment with in pursuit of acquiring OEV.

  2. This proposal is the TEMP CHECK Stage, and it is anticipated that risk team(@ChaosLabs and @Gauntlet ) will submit scenario analysis results in the ARFC Stage. We deems it appropriate to assess concerns regarding 1~3 block delay after these results are submitted.

  3. Aave has already delegated a part of the crucial role of the Oracle to chainlink. Rejecting UMA solely based on it being a third party does not seem to be a sound judgment.

Two questions regarding @UMA

  1. Does integration of Oval increase the likelihood of delayed inclusion of liquidation transactions in the Block?

  2. In implementating this pilot program, is there consideration for providing a certain amount of collateral.

*The members of the Titania Research team helped me understand this proposal. Thank you for much, Titania Research.

Our earlier response to LBS answers this question, and we’ve quoted it below for your ease.

Thank you for your support, @SaucyBlock, and feel free to join our Twitter Space once we confirm the timings.


Oval Audit

You can find our Audit report by Open Zeppelin for Oval here.


Great discussion!

I’d think that just because about 90% of all Ethereum blocks are built by builders connected to Flashbots MEV-Share does not mean that there is a 90% probability that they will ultimately be included.

I was curious about that is there really a high 90% probability of being included in the block?


Few things.

I don’t see any added value to going to the Twitter space. This is not a beauty contest or a belly dance competition.

This proposal had 14 days of discussion, almost 3x the average discussion time in this DAO, to allow everyone and their uncle to present their opinion fairly, ask questions & give ample opportunity to UMA to answer them everything that needed to be said about this proposal has already been said.

Now is the time to vote and decide if this proposal goes to the next stage that will involve specialized service providers or not.

As a service provider providing the universal Skywards service, my vote & opinion are 100% irrelevant regarding this proposal implementation.

We posted this topic; we escalated this proposal to a snapshot after all major delegates and governance actors had time to expose their opinions & UMA could answer them. And if this proposal goes to the ARFC stage and beyond, we’ll provide the excellent service upon which we built our reputation.

Thanks for the question @vita

At present, ~90% of all validators run MEV-Boost, therefore ~90% of validators (proposers) are connected to a builder that supports MEV-Share. Assuming a competitive bid is placed that warrants inclusion, each Oval update & searcher backrun bundle has a 90% chance of being included within the same block as the Chainlink price update.


Thanks Marc. We’ll still be hosting the Twitter Space tomorrow, and if you can make it we’d love to hear your deeper thoughts. We appreciate ACI’s support via the skyward process and encourage all delegates to participate in the TEMP CHECK vote on Snapshot.

1 Like

Thanks for the reply!

  • Even if ~90% of all validators are currently running MEV-Boost and ~90% of validators (proposers) are connected to builders that support MEV-Share, that does not necessarily mean 90% inclusion.
  • What this theory means is that if you connect with 90% of the builders, your bundle will be included in the 90% case, even if those builders are not searchers who can create the most valuable bundles.Since block space is limited, I think it is possible that the most valuable tx or bundle could be included in close to 90% of the cases, but since I don’t think this case is a higher tx or bundle than a sophisticated searcher, I think it is less than 90%.

  • Certainly competitive bidding increases returns to users and protocol, but does it decrease the likelihood of inclusion? Because the profits that used to go to searchers, builders, and proposers are now returned to users, does this not make liquidation transaction relatively unattractive to them. This also means that the risk of liquidation may contribute to the generation of bad debts.


Gm, Ashar here another API3 lurker, I want to respect Oval’s proposal and will try to stray not too far from the topic at hand since I’ve heard some whispers that people don’t seem to be too pleased with what our stance is in this proposal so let me try and clear the room.

In the interest of AAVE delegates, I’ll try to be as objective as possible. First, to address some of the points MarcZeller made regarding Oval being a compromise to decentralization are valid, in the same notion we need to realize is that the industry as a whole is rapidly moving towards capital efficiency in the form of intent-based solutions (UniswapX, Cowswap etc). At some point, protocol developers need to realize that we will not have better execution ( ltv, lb etc) as long as oracles continue to update the way they are. Some of the suggestions Zeller has made like creating several liquidation ranges are interesting and we can discuss the pros and cons of it at length but in the context of this discussion, it is irrelevant because it would require the development and upgrade of the AAVE protocol. An upgrade that will take time and fragment liquidity further. AAVE v2 still has 2 billion dollars and up until recently v3 was below v2 in terms of TVL. Furthermore, liquidity would flow outwards to other protocols that offer better execution over time if the current status quo is maintained (albiet this will take a while)

Second, if the oracle has not vertically integrated OEV recapture into the stack, Oval’s architecture ( and similar solutions that delay) is the only way to recapture OEV. Being vertically integrated to flashbots is a plus because they can bring the delay down to 1 block and be included in 90% of the blocks. I suggest that the Oval team bring it down to 1 block, even if it means 10% of the OEV is not captured. This would be a good compromise between decentralization and execution.

Third, regarding Zeller’s comment regarding OEV captured figures being less attractive now compared to 2-3 years ago is a little disingenuous. OEV is a function of the TVL of the protocol, if the TVL figures have dropped 80% from 2022 then OEV would also reflect that. The expectation here should be that if AAVE were to go back to 2022 figures then we could “potentially” recapture 60Million in OEV and potentially more overtime. Having said this, Oval’s marketing has been pretty dodgy when it comes to conveying the numbers properly and it has contributed in this lack of trust towards their proposal, in particular, I am referring to the Revenue distribution. In no scenario should Oval take a %50 cut of the captured OEV, this moves away from better execution to just going back to the status quo.

Fourth, Oval should have gotten all the relevant parties aligned ( CL being the biggest ) before deciding to put forward this proposal because as it stands they have alienated all the parties involved in what could have been a great product showcase.


This is Kydo from Native Labs.

I think this proposal is excellent for Aave, and I suggest that we should consider exploring the OEV design space with Uma and Flashbots. These two organizations have been pioneers in oracle and MEV respectively. The markets where this pilot program will be implemented are also relatively safe due to their size and volume.

However, there are areas in the proposal that could benefit from further refinement. I would appreciate a more detailed integration plan, including the necessary changes for the Aave protocol to adopt Oval. What is the scope of these changes? Additionally, I would like to see a plan for transitioning this pilot program to an extended pilot program, with defined success criteria and subsequent steps. Establishing clear roadmaps that we all agree on could save us substantial time in future discussions.

I want to thank the Oval team for presenting this proposal and @ACI for progressing it to a temporary check.


I’d like to stress the point that you are proposing to inject a third party node into the critical path of AAVE’s liquidation process, which seems extremely risky. Is the node a black box? What if the node goes down? What if the node has a bug? What if the node colludes with someone? Anything wrong at all can be catastrophic to AAVE. Not to mention the additional risks associated with FB.

To what extent should we maximize profit? It’s all about risk vs reward. At some point you have to ask: why not just have the DAO run its own liquidation and capture everything?