[MIP-3] Mendi Finance to Continue Using API3 for ezETH Price Data and Benefit from OEV

[dav3]

Authors: dav333, gio6015

Title: Mendi Finance to Continue Using API3 for ezETH Price Data and Benefit from OEV

Type: Mendi Improvement Proposal

---

Abstract

Mendi Finance currently uses API3’s exchange rate feed as a price source for Renzo Protocol’s ezETH/ETH liquid staking derivative (LSD). This proposal wants to incentivize Mendi to continue using the ezETH/ETH dAPI (data feed). In continuing to use the API3 ezETH feed, Mendi will be able to benefit from using data feeds that recapture OEV, where it can be used for the benefit of Mendi - for example, the returned value can be used to improve Mendi staking APY, improving lending rates, or reducing effective liquidation costs. It is suggested that the OEV generated in this initial use case be returned to Mendi stakers to improve staking APY, and prove as a demonstration of the potential value that OEV can bring.

In addition, API3 is growing into a recognisable brand ($500m TVS) synonymous with a new MEV recapture strategy for dApps and their users and can be leaned on to grow Mendi’s market presence.

Snapshot Vote: Snapshot

Proposal Summary

We propose that Mendi continue to use the API3’s exchange rate feed for ezETH. MIP-2 includes switching to Chainlink as an oracle provider for ezETH. This proposal is simply requesting to not switch oracles from API3 to Chainlink, and instead to use ezETH to demonstrate the benefits of OEV data feeds to Mendi.

The OEV generated by this single pair will be returned to the Mendi stakers to improve APY for staking.

Motivation

The efficiency of Mendi can be increased by recapturing value that is being overpaid to third-parties for performing liquidations. It has been proven that liquidations can be so competitive that liquidators are willing to give up over 99.9% of the available revenue. By integrating an oracle solution with an built-in MEV recapture mechanism, Mendi will be able to set itself apart from competitors by generating additional revenue that other protocols are simply leaking away.

Mendi already uses API3’s ezETH price feed on Linea, which makes it the perfect pair to use to demonstrate the value that OEV could bring to Mendi if other data feeds are switched to API3 in future. Technical load will be absolutely minimal to implement this proposal, simply reading from a different proxy contract for the ezETH feed and supplying an address that will be able to withdraw the accumulated OEV from the new proxy contract.

API3’s data feeds (dAPIs) secure over $500m TVS with exchange rate feeds like the ezETH feed are used by a number of dapps, including Init Capital, Lendle, and Pac Finance across 16+ EVM networks, with over 161+ price feeds. Thus, API3 is well positioned for any Mendi chain expansion or concentration plans within and across Linea.

Technical considerations

Mendi is already using the ezETH/ETH exchange rate feed. API3 will deploy a proxy contract to read this feed from that accumulates OEV, and allows Mendi to withdraw it. Mendi would simply need to provide a beneficiary address that is permitted to withdraw the OEV.

As ezETH is an exchange rate feed, it gives the ratio of ETH:ezETH. The underlying price of ETH is still needed to return a dollar value. API3 maintains an ETH/USD price feed on Linea that will be used to supply the price of ETH in USD as well to maximise OEV opportunities. Note that this proposal does not suggest switching from the existing ETH/USD provider for any other markets

Expected Timeline - OPTIONAL

• Governance Vote: {date} (Starts at the posting of the proposal)
• Designation of a beneficiary address: Within 1w of the proposal passing (suggested)
• Switching to OEV proxies: Within 1w of the beneficiary address being created the API3 integration team will share the addresses to read from (suggested)

Designation of a beneficiary address and proxy deployment timelines are flexible for API3, and API3 will work to whatever timelines best suit the Mendi core team, and provide all necessary assistance

Key factors to consider with the proposal

This proposal involves no technical changes, and will improve the APY given to protocol stakers, as well as acting as a proof of the value that using OEV enabled data feeds can bring.

Using API3’s ezETH price feed opens up the potential for Mendi to easily integrate many other LSD price feeds in future, as liquidity for them is bridged to Linea. Examples of the feeds that could be made available instantly for Mendi to use can be seen here.

Conflict of Interest

The authors of this proposal are both contributors to API3 DAO, and Mendi stakers looking to contribute to the newly formed Mendi DAO.

Next Steps

1. Provide a beneficiary address able to withdraw the accumulated OEV from a proxy contract
2. API3 will then deploy proxy contracts for ETH/USD and ezETH/ETH
3. Switch to reading both feeds from the new proxies to determine ezETH/USD
4. Once OEV has been accumulated, the Mendi Core team will be able to withdraw it from the proxy using the beneficiary address, and use it to increase APY paid to stakers

[dav3]

(Copying over the more detailed post from the RFC thread about differences between API3 and Chainlink)

Firstly - the Similarities

API3 is a decentralized push oracle, like Chainlink. It is designed to keep prices updated in a decentralized way on the chains that the users operate on. In recognition of the fact that a lot of battle tested code expects push oracles, API3 has been designed to be a direct replacement for Chainlink, and API3’s data feeds (we call them dAPIs, but I’ll call them data feeds to avoid confusion) can even be read from the Chainlink adapters Mendi use, further saving code changes.

Differences

API3 is designed to push prices to chain in a different way to Chainlink. Where Chainlink relies on third parties to query (unspecified) APIs, and push the results to chain, API3 has a first party architecture. This means that the data sources transparently and verifiably push data to every supported chain chain, using oracles they operate themselves. Data sources supporting each feed can be viewed and verified on market.api3.org

As well as transparent data sourcing, first-party feeds have a security advantage over third-party, as there is no middle layer between source and chain that can potentially misreport. Using highly reputable data providers, and having them directly post prices to chains for aggregation, also links their real world reputation to the quality of data they provide in a way that having data posted by third parties cannot - any attempt to misreport would be much more visible than the data providers used by Chainlink. API3 also aggregates between the data providers on-chain to provide a decentralised value that can be safely used by dapps. Detailed information on how data feeds are constructed is also available in the documentation.

Both API3 and Chainlink differ from Pyth and Redstone. With these native “pull” oracles, if you require your feeds in a push format, you are required to introduce or run a price-pusher. This introduces off-chain centralization as dapps often operate these feeds from a single pusher, which would cause stale feeds if it failed - in comparison to the decentralised update process native push oracles have.

Oracle Extractable Value

API3’s data feeds are designed to allow dapps to recapture value that the protocol would otherwise have leaked through MEV. Chainlink has no current plans for this. API3’s approach to enabling OEV extraction involves allowing searchers (entities who trigger liquidations to earn the liquidation incentives) to bid for the right to trigger an earlier data feed update than those based on some kind of set deviation. 90% of the winning bid value is then returned to a proxy contract that Mendi controls, and will be able to withdraw from trustlessly.

Triggering earlier updates is beneficial because of how push oracles update. Updates are triggered based on both deviation and time based triggers. Deviation-based updates happen when the off-chain price is more than a certain % different to the on-chain price, and time-based updates happen periodically even if there is no change to off-chain pricing. Therefore there are frequent situations where the on-chain price can lag the off-chain price, forcing searchers who would trigger liquidations to either wait for more price movement to initiate a deviation based update, or wait until a time based update is scheduled.

With API3’s solution, the winning bidder in in these auctions is able to bundle the liquidation transaction with this (more current) data feed update, allowing them to gain priority for liquidations and win the incentives - but also improving the data feed quality for the dapp, with theoretically infinite granularity.

Protocols recapturing Oracle Extractable Value will be able to outcompete rivals through redirecting this revenue where they feel it will be most beneficial. For example, if this recapture is to be given back to the liquidated borrowers, it effectively reduces the liquidation penalty from 5%, down to ~1%, providing a meaningful advantage against anyone not using it, and encouraging new borrowers to participate. If the revenue was all directed towards protocol stakers, APY could be improved instead.

Should all Mendi’s data feeds be switched to API3, the recapture as it stands would be roughly $50k/year. A potential increase of TVL by 100x in a bull market would see a corresponding increase in OEV. We use the following metrics to estimate this value:

• A common approximation for liquidations on lending markets is approximately 5% of TVL annually
• Mendi’s liquidation incentive is 5%, so the total potential liquidation incentives to be recouped = 5% x 5% of TVL annually
• API3 can return up to 90% of this to Mendi, assuming healthy competition for liquidations exists. API3 actively works with searcher networks to ensure this is the case, although it is entirely possible that values may be lower initially (we use 90% of 90% in the table below to partly reflect this). 10% of the OEV is shared between API3 and the data providers on each data feed, which helps incentivize them long term to grow.
• Therefore 0.05 x 0.05 x 0.9 x TVL is the approximate maximum annual OEV that would be forsaken by choosing another oracle solution

The approximate breakdown can be demonstrated here (at current TVS - a 10x in TVS sees a corresponding increase in OEV revenue as well).

TVL	$25,000,000
Estimated % of TVS Liquidated Annually	5.00%
Annual Amount Liquidated	$1,250,000
Liquidation Incentive	5%
Total Incentive	$62,500
Searcher Auction Bid %	90.00%
OEV Generated	$56,250
dApp Portion (90%)	$50,625
Amount to Data Providers (5%)	$2,813
Amount to API3 (5%)	$2,813

As noted, there is no integration work required other than calling a new proxy address and providing a beneficiary address to which you can withdraw the proceeds. The same base feed you are using is still in effect, and this is simply an additional layer of redundancy on top. There has been a lot of interest in OEV, and becoming an early user will help drive adoption and interest in Mendi, as well as improve the experience for Mendi’s users

[Mendi_Core_Team]

As the proposal is likely to pass, our opinion as the Mendi Core Team is that this provides an excellent opportunity to be a first adopter of the OEV architecture built by API3.

The architecture and security of API3, the team’s dedication to transparency provides an oracle that can be used by Mendi Finance. Due to API3 being a new entrant we will continuously monitor the solution and the performance to fulfill due diligence obligations (as with any other solutions).

OEV captured value:

Dominant strategy is leveraging ezETH holding with further ezETH mints. This is a less liquidation heavy strategy, so the benchmark estimations might be a bit higher then what we will observe in practice. As Mendi still captures value this i just a question of the accurate range, which is dependent on market conditions, strategies.

On other markets we believe the OEV can be higher in the future, being an early adopter gives us a good base to observe and potentially expand markets where we can utilize OEV.

Security

The easy implementation of the market means that we don’t see any barriers that would require any steps from the core team to implement the proposal. With constant monitoring of oracle solutions we hope to make steps towards simplifying the oracle architecture.

Liquidators are encouraged to capture the value, and even if they don’t adopt the OEV in their processes there is no prevention of liquidations, as the price feed still gets updated.

One drawback that we observed, is that compared to other API3 feeds the data providers are not as decentralized.
Which leads us to the only crucial question: Will other providers beside Notary adopt the price feed to provide more redundancy?
We directly talked with Dave about this question, and he told us that Ankr and Blast API will start providing ezETH feed in a week. This is satisfying for Mendi, and as we observe more providers behind other markets on API3 website, I am sure other providers will also adopt the feed.

[dav3]

Thanks for this - I would like to elaborate for the curious on why the LSD/LST feeds are less decentralised at the moment than the other market feeds. These are bridged exchange rate feeds, which use the ratio that assets can be exchanged for (for example the number of ezETH you get if you restake one ETH with Renzo). Exchange rate feeds differ from the traditional crypto price feeds. Traditional feeds use market price across various exchanges/dexes, which tend to be more easily manipulated for LSD tokens, especially in the early stages of their adoption where liquidity can be low on L2s. Exchange rate feeds are read directly from the staking contract on ETH Mainnet, so there can only ever be one source. Launching with a single provider that we knew to bridge this reliably was seen to be an acceptable compromise, allowing us to support new assets rapidly while we built to decentralise. While a separate entity from API3, Nodary is operated by API3’s technical lead, and has been supporting all of our data feeds across 18 chains for over a year now without any issues.

We have been onboarding additional providers for these exchange rate feeds, and will be live with them very soon as mentioned to add valuable redundancy. The underlying asset price feed used to calculate the $ value of ezETH from the exchange rate (in this case ETH/USD) uses 7 verifiably different data providers, and all of our other crypto price feeds are also available with this configuration.

Any of Mendi’s liquidators wanting assistance with OEV are encouraged to reach out - either to me or in the API3 discord, and our developer relations team will make sure you are familiar with how to use it

[blockbagel]

@Mendi_Core_Team

One drawback that we observed, is that compared to other API3 feeds the data providers are not as decentralized.
Which leads us to the only crucial question: Will other providers beside Notary adopt the price feed to provide more redundancy?
We directly talked with Dave about this question, and he told us that Ankr and Blast API will start providing ezETH feed in a week. This is satisfying for Mendi, and as we observe more providers behind other markets on API3 website, I am sure other providers will also adopt the feed.

Appreciate the response. I am in favor of this proposal.