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

Governance Proposals
1

Authors: dav333, gio6015

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

Type: Request for comments

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
3 Likes
2

The timeline section is incomplete - this is temporary, until we know when the vote will be able to go up. Look forward to any comments/questions

3

Everything that brings value to protocol and users, and it doesn’t affect security is valid. I’m in favor of the proposal!

3 Likes
4

I think Oracles are a crucial question for any lending protocol. We also observed some inefficencies with the current oracle setup and are very interested to see the community’s opinion on API3, and also in a wider spectrum.

Currently Mendi relies on 3 Oracles, Pyth, Chainlink and API3.

I am personally in favor of long-term unifying around one oracle service. This can decrease protocol risks, as with multiple oracles if any of them fail on any market it has a global effect on all the markets within the protocol. Even with one oracle securing markets, oracles can and have failed in the past, but I am leaning towards removing the risk of having multiple oracles securing different markets is the right move long-term.

I also think that oracles are such a crucial feature in the current set up, that this is an area that the core team (or at a later stage of the DAO the security council, which I see as the same role, but with external members) needs to have a hands on approach for security purposes. (This is not meant against API3 at all, its a general observation as we observed inefficiencies with other large oracles on market that can endanger the protocol long-term. )

API3s OEV architecture is a unique idea and it can bring benefit to the protocol and to the liquidators, which is beneficial to remove bad debt from the protocol. This is very crucial for long-term protocol health, as we are experiencing large volatility on the market.

Having API3 on the market enabled us to list ezETH more securely than competitors who are using (afaik they might have upgraded since then) ETH feeds on ezETH. As long as ezETH and EigenLayer functions correctly that is okay, but if there is an issue API3 provides real price feeds behind ezETH market.

Chainlink should have listed ezETH for launch, but they missed this, and API3 was ready so it was a no-brainer to go with them. This feed is still not live on Chainlink.

With any provider there is also a question to see how would lending protocol users (current and potential) would view the lending protocol. For this reason I also encouraged the API3 team to move ahead with an RFC, where we can have a better and verified overview of users perspective. I am looking forward to see how the conversation develops around this topic, and I hope many people will participate in this discussion.

What would be also interesting to expand upon for the community is the underlying architecture behind API3 feeds and the differentiation compared to competitors.

2 Likes
5

Appreciate the comments - I agree it’s worth expanding on API3, the differences between Chainlink and API3, and how switching all feeds from Chainlink to API3 in future would benefit Mendi.

Firstly - the Similarities :slightly_smiling_face:

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

1600×900 219 KB

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

1 Like
6

As this RFC has now passed I’ll create another post for the MIP - thanks for your comments everyone