Simple Summary
Proposal for the community to signal about activating a pilot program of SVR (Smart Value Recapture) oracles on Aave v3, a system created by Chainlink to recapture MEV from Aave liquidations and return it to the Aave ecosystem.
Context
Aave v3 and all previous versions use a simple, but very elegant solution to optimize the protocol for liquidations: whenever a position needs to be liquidated, the liquidator repays some amount of debt and receives the equivalent value in collateral, plus a percentage on top denominated liquidation bonus.
This liquidation bonus exists to incentivize any third party to always perform liquidations, covering any type of market/gap risk they incur during the process. It is configured as a fixed percentage, which initially sounds un-optimal, but results in very positive outcomes:
- Crypto assets (even those highly liquid) have periods of extreme volatility, so a fixed and high enough bonus makes liquidations profitable even in those scenarios.
- A fixed liquidation bonus on the base protocol almost assures strict protection of the system, given it is pessimistic: whenever a position gets liquidated, the priority is to protect the over-collateralization of the system by liquidating as soon as possible, to, in turn, protect the suppliers of liquidity, and with them, everybody else.
- Configuration of the parameter and everything surrounding it is relatively simple for risk providers, compared with more sophisticated engines based on very dynamic liquidation bonuses, for example involving auctions in the liquidity protocol itself.
- Last but not least, Aave has been on the market for several years with this mechanism, and every single time has been successful in its goal of protecting liquidity suppliers.
In summary, Aave and its liquidation bonus work, but lately a “problem” has appeared that deserves some type of optimization: MEV (Maximal Extractable Value).
Different from Ethereum back in for example 2018, currently the block creation process is way more sophisticated. During this process, multiple actors participate:
- Searchers: looking for opportunities for MEV by ordering transactions in a certain way (bundles).
- Builders: building blocks from the bundles of transactions received from searchers, or any standard user.
- Validators: validating the blockchain, including blocks.
In what affects Aave and its liquidation bonus, there is a very clear opportunity for MEV: if for example the liquidation bonus of an asset is 3%, and to perform it in the current market situation only 2% is needed for the liquidator to hedge its risk, the 1% left is potential profit that can lead to a race/auction: searchers try to detect as fast as possible the liquidation, build the transaction(bundle) and convince the builder to include it, by redirecting part of the aforementioned 1% profit.
In practice, this means that searchers try to detect price oracle updates as soon as they are submitted to the transaction pool (main “trigger” of liquidations), back-run them with a liquidation transaction, and try to be as optimal as possible to minimize their operational cost, to redirect higher amount to builders to include them in the block instead of everybody else competing.
The outcome of this game is not optimal for the underlying protocol and its users because: in the average liquidation scenario, there is pretty significant profit for an entity that doesn’t do the majority of the job: the builder. Meanwhile, searchers, the protocol users receive way less in proportion.
So, how to optimize this? During the last year, there have been multiple developments like the one proposed by Oval in this forum, trying to recapture MEV. All of them are based on somehow intercepting the price update in different layers, to only allow liquidations that leak as little MEV as possible.
This TEMP CHECK is about integrating one of those solutions, with the oracle provider itself modifying the transaction submission flow of price updates to recapture MEV: Chainlink SVR (Smart Value Recapture).
Specification
On its initial iteration, Chainlink SVR is Ethereum-only and built on top of the Flashbots MEV-Share infrastructure, following its core principle: get more granularity defining who is the entity/es benefiting the most from transaction ordering, between the originator, searchers, builders or anybody else.
In practical terms, SVR is a service “selling” via an MEV-Share auction the right to back-run a price feed update to perform any type of action, on Aave targeting the most profitable one for all actors involved: liquidations. The recapturing is the outcome of said auction: the winner is the searcher who redirects the most value to the originator (an address defined by the originator in advance) at the end of the bundle.
All details of the Chainlink SVR system can be found on their announcement post on blog.chain.link/chainlink-smart-value-recapture-svr, which will be complemented by upcoming extensive documentation, but high-level, the system works as follows:
Simple high-level overview of the system ( * ETH/USD solely for example purposes)
- The off-chain Chainlink network (DON) produces prices following the same algorithm as currently.
- When an update on-chain needs to be done, two things happen in parallel:
- The price is submitted to the “standard” price feed currently used by Aave (which we will refer to as “SVR fallback” feed in this document too).
- The same price is submitted to MEV-Share, for searchers to participate in the auction to back-run it.
- Once the auction finishes (both with or without any winner), the price is submitted on-chain to the SVR feed.
- If for any reason the price would not be submitted on-chain, the SVR feed automatically fallbacks to the SVR fallback feed after a delay, providing the same assurances as normally on Aave.
During our collaboration the last months with Chainlink designing the system, we have set the following principles/requirements:
- Similar to what we commented in our feedback on the Oval proposal back in the day, we believe a system by Chainlink is the most appropriate to move in this direction, as 1) the oracle provider is the most direct entity to manage any step on the price pre-submission stage, like the auction in this case, and 2) Chainlink is a long term partner of Aave.
- SVR should strictly re-capture an order of magnitude more value than any type of risk added to the system, mainly market/gap due to the auction or fallback delay. More data will be published from the Chainlink research team in the following weeks, but the historical analysis we had access to shows this is the case.
- Conservative approach. Even with the expertise of all parties involved and this being the first iteration of the system, the project has been running for the last year, and built on top of expertise of several years, both on the oracle and liquidity pool sides. This is due to being very careful with all design decisions and backtesting of the system, which is a total requirement to apply an engine of this nature to any part of Aave.
- From a technical perspective, SVR must be as close as possible to the currently used Chainlink feeds from all perspectives: access control, proxying mechanics, interface, and submission flow.
Additionally, it should not cause any logic changes on Aave, only potential re-parametrization of risk parameters, like the liquidation bonus. - Strong security procedures should be applied by Chainlink before any activation, including but not limited to auditing the SVR system.
FAQ
→ Why Chainlink as the provider and not others?
In something as critical as price updates, the fewer middle layers between the infrastructure doing the price aggregation (Chainlink DON for feeds used on Aave) and the protocol, the better.
Chainlink infrastructure and assumptions are battle-tested already, so it is just natural to reuse them for this.
→ What are the gas implications of the new system?
The architecture of the new SVR main price feed and the fallback use a common contract Dual Aggregator for data storage, which minimizes data reading. We don’t expect the added gas cost in terms of the call flow side from Aave to Chainlink (CALL, DELEGATECALL) to be relevant, but we will disclose the exact effect during the following weeks in this thread.
→ What are the added market/gap risks of the new system?
Mainly two:
- The delay introduced by the MEV-Share auction, which should be very minimal due to how broadly the system is integrated into the transaction order flow of Ethereum.
- In the worst-case scenario of the SVR not receiving a price update, the custom delay to fallback into the “standard” feed, which will be in the order of 3-6 Ethereum blocks.
→ Is anything else aside from liquidations affected?
All actions depending on price back-running are technically affected, but aside from liquidations, there should not be any meaningful effect on anything else.
It is important to highlight that MEV-Share only accepts back-running, not front-running, and consequently any edge “sandwiching” of transactions (e.g. involving borrowing). will not apply.
→ How SVR works in a case of multiple liquidations caused by the same price update?
SVR is agnostic to which transaction will be back-running the price update, no matter if including one or multiple liquidations. This number of liquidations is limited by the block size though, but due to pure game theory, searchers should prioritize the most profitable liquidations, as their margins will be higher. This is positive for Aave, as bigger positions being liquidated add more value to the protocol than smallers.
→ Which assets will the system be applied to?
We are still discussing with Chainlink about it, but on this pilot, only 1-3 assets will have the SVR plugged, in a very controlled manner.
The final selection depends mainly on the testing strategy, which might include some artificially created liquidations.
→ How will the SVR main <> SVR fallback delay be configured?
The initial delay will be defined on the activation proposal of the pilot, but given that Chainlink already has control on the price oracle side, and that they will run sophisticated monitoring on SVR, they will keep capabilities to adjust it within a range, similar to with Aave stewards.
→ In which asset the recaptured value will be received by the Aave DAO?
To simplify the infrastructure, and given that the Aave DAO is already exposed to it, the asset to receive the recapture value will be ETH. ETH is also a good proxy price-wise for the average case of collateral assets getting liquidated.
After the pilot, one of the objectives should be to have a more sophisticated system allowing different types of recaptured assets.
→ How much value is estimated to be recaptured?
The associated Chainlink blog post (HERE) elaborates on it, but conservative modeling indicates a minimum of 40% of all the MEV “leaked” could be recaptured, in the order of magnitude of tens of millions of dollars.
This of course depends on which assets the solution is applied, with those numbers equivalent to active SVR in all Aave assets, which is not the goal of the initial pilot.
→ How will the recaptured value be distributed?
Any type of distribution strategy on the recaptured value after the pilot period should be addressed separately, as this TEMP CHECK is related exclusively to the description of the system and its technical aspects.
For transparency, there had been discussions with Chainlink Labs for a proposal of an initial 65% Aave DAO, 35% Chainlink community ecosystem split for the first six months, starting from in-production integration. After this, a 60%, and 40% split will apply to cover all types of infrastructural costs. But any final numbers should be strictly approved by the Aave governance.
On the Aave side, it is only natural for the re-captured value to be used for the benefit of its users, for example by incentivizing the upcoming Umbrella stakers, who will bear part of the risk of the protocol, protecting its users.
→ What about other non-Ethereum networks?
Currently, the only battle-tested infrastructure for generalized auctioning of transaction order flow is Flashbot’s MEV-Share, at least for Aave’s needs.
Generalization of SVR for multiple networks will be addressed later on, once/if the pilot is successful.
Disclosures
Similar to other projects affecting oracles on Aave in the past, BGD Labs has supported Chainlink in the context of our engagement for services with the Aave DAO, exclusively because we think this is a good initiative for the Aave ecosystem from a long-term partner of the DAO.
We have absolutely no commercial relation with or any type of incentive from Chainlink Labs or anybody in the Chainlink community.
Next steps
- Wait for feedback and questions from the broad community about the system during the following days.
- After enough time in this forum, create a TEMP CHECK Snapshot for signaling to proceed with the pilot.
- If positive outcome on Snapshot, proceed to ARFC, already including the final configuration details of the integration of Aave with Chainlink SVR.