Simple summary

Proposal for the community to pre-approve the final activation/configuration of SVR (Smart Value Recapture) oracles on a sub-set of Aave v3 Core Ethereum assets, a system created by Chainlink to recapture MEV from Aave liquidations and return it to the Aave ecosystem.

Context

As described in the TEMP CHECK stage, this proposal seeks the community’s approval to integrate Chainlink’s SVR v1 system. Extensive details about its rationale and specifications can be found on Snapshot and the associated governance forum.

This ARFC delves more into the proposed initial configuration details of the initial phase (Phase 1).

Specification

To recap, the architecture of the new Chainlink SVR feeds to be connected to Aave is as follows:

In the integration side of Aave, there are two major components to take into account:

• SVR Feed. This will be the one plugged into the Aave Oracle smart contracts (with the necessary CAPO adapters on top if applicable), receiving the OEV-recapturing price on-chain.
• Fallback feed. This is a mirror of the “standard” price feeds currently plugged into Aave, without OEV recapture. The SVR Feed has a configurable delay fallback in seconds: as both SVR and Fallback feeds get submitted to their respective mempools in parallel, whenever the OEV doesn’t reflect on-chain for more than the delay fallback seconds but the Fallback does, the price reading is routed to the Fallback feed.

The fallback mechanism is completely fundamental security-wise, as it gives one important assurance: on average, the price availability of the overall system will be equal to or superior to the current feeds, but even in the worst-case scenario, the maximum delay to read from a “standard” Chainlink feed will be of the configured delay fallback seconds.

Initial assets configuration: controlled approach

Even considering that the technology (Chainlink, Flashbots) is battle-tested, and the protection mechanisms embedded into SVR like the fallback, we believe the rollout of feeds should be progressive, only enabling a very limited subset of assets on v3 Core Ethereum during the first month or so.

From our discussions with Chainlink, we think the following principles for choosing the initial assets are reasonable:

• The assets consuming the feeds should have a meaningful volume of historic liquidation.
• The majority of liquidations happening on positions consuming the chosen feeds should be due to those feeds, and not due to other assets. E.g. in positions using AAVE as collateral and borrowing USDC, the majority of liquidations happen due to the AAVE/USD price feed updates on the collateral side, as the USDC/USD feed barely changes.
• In this first activation batch, major assets size-wise should be avoided: ETH, wstETH, WBTC, weETH.
• Ideally, we plug in production feeds that will affect assets correlated with major ones, but smaller in size. Both tBTC and WBTC use the hood of the same BTC/USD feed, but the first is ~$82m in size versus the second ~$3b.

With the previous principles in mind, and also taking into account the extensive testing/simulations performed by Chainlink in their infrastructure during the previous couple of months, the recommendation is to enable the following SVR feeds:

• BTC/USD affecting exclusively LBTC and tBTC.
• AAVE/USD.
• LINK/USD.

Other configurations: fallback delay and its nuances

When choosing specific values per asset for a fallback delay, there are different points of consideration:

• The fallback delay is a mechanism that will not be used on the “happy” path: when the Chainlink DON submits prices to the Flashbots auction, historical analysis shows that the majority of price updates (and so liquidations) are included in the next block, and close to 100% in the range of 1-2 blocks. That means that price reading being redirected to the “public” feed will only happen if a fallback delay is configured to less than 2 blocks (in seconds), or in very edge scenarios when auction participants don’t show up for more than 2 blocks, even if economically sound.
• Aside from the auction aforementioned average auction speed of 0-2 blocks, configuring too low (e.g. 2 blocks) the fallback delay opens to an edge, but theoretically existing censorship vector: it could be profitable for a builder with control to build the +2 block from next on the public mempool to censor the price update on the 2 blocks on the Flashbots auction, to wait for their to-be-mined block on the public mempool. Again, this vector is very theoretical but technically exists whenever the fallback delay is very short. Any increase in the fallback delay configuration makes the censorship vector exponentially more expensive, as the cost of “capturing” multiple blocks in a row gets increasingly more expensive,
• Aave is configured very conservatively risk-wise, which means that the difference of processing a liquidation in the same block of price update versus some blocks after doesn’t put the system at all at risk. This will not really be the case on the average scenario of the price being included into the block via Flashbots, as it will precisely incentivise as fast as possible inclusion, but it is a consideration to not configure the fallback delay too tigh, avoiding any type of censorship attack, even if very theoretical.

Considering the previous rationale, and also using historical analysis from Chainlink showing that there will be no loss on the risk profile of the protocol, the recommendation is to set the fallback delay on BTC/USD, AAVE/USD and LINK/USD to 5 blocks. The Aave DAO via its risk provider will reserve executive power over modifying this parameter by communicating to Chainlink.

Extra protection: SvrOracleSteward

Given the criticality of the infrastructure activation, and to be even extra cautious, we also propose to include a new steward smart contract: the SvrOracleSteward.

The SvrOracleSteward allows for the Aave Protocol Guardian to replace, on the Aave Oracle side, a feed (e.g. CAPO) consuming one the new SVR by exclusively one used before the SVR replacement. This way, even in the very unexpected worst-case scenario of the new SVR simply not being functional or having a really major issue, the Aave Protocol Guardian could immediately swap back to the standard price feeds currently used in production.

We don’t expect this mechanism to be used anyhow, but we think it is reasonable as an extra line of defense when enabling a pretty innovative system like SVR v1 Chainlink.

OEV-recaptured recipient

When using systems like Flashbots for a case like this of SVR, it is necessary to define an address to receive the native currency (e.g. ETH) recapture. Ideally, the Aave DAO would have full control over this address, but in practice, as the Chainlink DON is the entity factually building the transaction and submitting it to Flashbots, they have control over configuring it or changing it.

The Aave protocol already has a RevenueSplitter smart contract to be used as OEV beneficiary, for any non-100%/0% split between Aave and Chainlink. But given that using it or not is a purely operational consideration (as still Chainlink can change it unilaterally), we will coordinate with them to decide whats the most reasonable venue.

In any scenario, the final recipient of the OEV fees should be the Aave Collector, and we consider mandatory that distribution to it happens minimum once a week, no matter if via RevenueSplitter or via transfer from the Chainlink side.

Aave/Chainlink fee split terms

Similar to any other terms of the Aave <> Chainlink SVR partnership, it is outside of the scope of this ARFC to define the percentage of a split between Aave and Chainlink on the OEV recapture, as we (BGD) are technical service providers, and the community should vote on the configuration separately from those. We will abide by any decision approved by the DAO via ARFC, configuring any technical component accordingly.