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.
