Summary
This proposal suggests the utilisation the OEV Network to recapture OEV currently being lost by Venus (in the form of overpaid liquidation bonuses) by changing the ResilientOracle configuration for the biggest markets on BNB Chain to the following:
- BTC - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- ETH - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- BNB - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- wbETH - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- USDT - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- USDC - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- FDUSD -{primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- CAKE - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
Currently Venus charges a flat 10% liquidation penalty from users upon liquidation, of which half is retained as protocol revenue and half paid out to searchers performing the liquidation. The currently utilised oracle solutions of Venus treat each oracle update as if it has equal value, being completely unaware of the potential value leakage of dApps that utilise them. However, API3 differs since it has an oracle solution with a vertically integrated MEV recapture mechanism that allows searchers to compete for oracle updates that have significant value and for that value to accrue back to Venus.
Similar auctions on Ethereum and research on the subject matter suggest that up to 99.9% of the available revenue is given up in such auctions. Winning searchers receive signed data from the oracle nodes, allowing them to update the price feeds that Venus utilises in a tamper-proof way and perform consequent actions exclusively (e.g. the liquidations) by utilising the signed data and transferring the winning bid amount. The revenue from this is gathered on the API3Server.sol contract and can be withdrawn in a permissionless way by a beneficiary address appointed by Venus at any time. Since deployment, Venus has lost over $71 Million to searchers through paid out liquidation bonuses, which amounts to a monthly average of $1.6 Million.
These are funds that could be utilised in various ways to further build out a competitive advantage against other lending protocols by incorporating new revenue streams that could flow into mechanisms like e.g. a buyback and burn program for XVS, additional yield for specific markets or to further bolster the protocol reserves.
Rationale
What do oracles have to do with Venus?
Lending Protocols rely on oracles for determining the price of assets for the majority of their functionality. One of the core components that is enabled through oracle transactions is the determination whether a user position is liquidable. It is paramount that positions get liquidated reliably in order to protect the lending protocol from incurring bad debt. In order to ensure this, lending protocols offer up a percentage of the liquidable userâs collateral at a discount to the liquidator as incentivization (âliquidation bonusâ). This percentage differs from protocol to protocol and in Venusâ case the user is being charged a liquidation penalty of 10%, of which half goes to the liquidator. This means that if a $100.000 user position is liquidable there is an available reward for liquidators of $5.000. If the position is $1.000.000, the reward equals $50.000, etc.
Liquidators are being overpaid
Liquidations are very lucrative and there is aggressive competition for them. It is API3âs belief that protocols like Venus are leaking enormous amounts of value which could be substantially retained. In a Monoceros report (called âThe MEV Bookâ) liquidations on Ethereum were analysed and it was determined that liquidators regularly give up 99.9% of the available reward to block builders in order to get their transaction included first. The competition around liquidations and the availability for a market where this competition can take place, forces liquidators/searchers to give up the majority of the reward. This transaction shows one of the biggest liquidations on AAVE v3 this year (January 2024):
The user position was liquidated for $4.2 Million with an available liquidation bonus of $141,477.45. $141,416.50 of this (99.9%) were used as a bribe to block builders in order to allow the liquidator to walk away with $60.95 in profits.
Examples like these prove repeatedly that, given a competitive marketplace, nearly all available revenue will be given away and liquidations will be performed for a fraction of the reward that lending protocols are handing out today.
The biggest liquidation on Venus this year isnât that far off from the one on AAVE. On April 13th there was a liquidation for nearly $3.5 Million. The total liquidation penalty for this was $350,000 of which $175,000 went to the Venus treasury (in the form of 2.6375 BTC at the time) and $175,000 went to the liquidator.
You donât have to pay liquidators that much to perform liquidations.
Oracles and their privileged position for liquidations
As oracles determine when a liquidation is possible by updating the respective price on-chain, they theoretically have first rights to said liquidations. Oracle updates could be bundled with liquidation calls, which would mean that âexternalâ liquidators couldnât even compete for any liquidations, since the oracle project would âcatch them allâ.
A core issue with this approach is that this inevitably leads to the centralisation of liquidations. If the oracle project is guaranteed to win when they perform these liquidations, why should others even bother to look? This means that if the oracle project would ever fail there wouldnât be sufficient competition for liquidations, which would lead to lending protocols incurring bad debt due to missed liquidations. As such, oracle projects have not taken advantage of their privileged position due to the aforementioned risks.
But what if you could utilise the privileged position of oracles in a way where things remain decentralised, open and permissionless for everyone? Enter API3 and the OEV Network.
What is API3 & OEV Network?
API3 is a leading blockchain oracle that provides price feeds. API3 operates in push-oracle architecture quite similar to oracle infrastructure which Venus is already utilising. Currently over 170 price feeds are available on 37 EVM-compatible networks.
A core differentiator for API3 is the API3 Market. It is a developer-focused interactive market that lets users permissionlessly deploy data feeds in an instant. Most of API3âs partners only approach us after having activated feeds themselves for e.g. co-marketing activities or the utilisation of potential chain grants for oracle services. Through close relationships with most chains, we can support any feed for free for partners on most networks.
The below video is an example of how quickly e.g. USDT/USD can be spun up on a chain such as Polygon and be ready for use (~1 Minute). Our innovative market and fully automated infrastructure allows our partners to quickly spin up new markets without having to go through business development hurdles & technical pipelines while waiting endlessly for their oracle partner to spin up desired markets. In fact, the majority of people might not even want to have meetings every time and simply get things going immediately. Itâs a competitive world out there and having the opportunity to spin up new markets near instantly is a core differentiator that many of API3s partners appreciate.
Another difference compared to other oracle solutions is that API3 exclusively relies on first-party oracles. In a first-party architecture, the data provider and the oracle are one and the same entity. Other solutions that Venus currently relies on are typically referred to as âthird-partyâ oracles. In that architecture the oracle node operators arenât the entities producing the data that they are providing on-chain. In most cases, third-party solutions donât provide the ability to verifiably prove where data originates from.
API3âs first-party architecture simplifies the process for traditional API providers to get their data on-chain. The highly reputable data providers that API3 partners with continuously update data on-chain using cryptographically signed data, offering a transparent and verifiable way for developers to use off-chain data.
In a nutshell: With the legacy oracles that Venus relies on you get data served by someone in the middle that âsupposedlyâ gets it from businesses such as Coingecko, Kaiko and others, whereas you get the same data directly and verifiably by multiple data providers like Coingecko through API3s Infrastructure.
Nowadays, there are numerous oracle projects that, in one way or another, all provide you with the same thing: Prices for assets that you want to integrate.
There isnât a lot of other value that these oracles are adding apart from providing this service, and while security methods and availability of assets and networks of different projects can be debated at length, the result for Venus remains the same:
Another oracle that gives you the same service.
For this specific reason, API3 spent the last year conducting research in the area of âOracle Extractable Valueâ (OEV) and built a system that allows the recapturing of value that dApps are leaking away due to oracle updates. The launch of the solution, a Rollup called OEV Network, was recently announced. OEV Network allows anyone to compete for oracle updates with value and perform price updates bundled together with the action they want to perform.
In the specific case for Venus, OEV Network allows liquidators to compete for oracle updates that would allow them to perform liquidations. Since weâve established that oracle prices determine when a user gets liquidated, winning the right to update the oracle to a specific price also gives the exclusive rights to a liquidation. OEV Network takes the competition for liquidations that currently happens on the block level and moves it to the oracle level, meaning that instead of competing to get your transaction included first, liquidators now compete for the oracle update transaction that allows for the liquidation.The proceeds from these auctions are then programmatically returned to dApp utilising the oracle. This makes API3 the only oracle project to do more than simply provide prices. Itâs an oracle with a built-in MEV solution that pays you for using it.
OEV Network: The Nitty Gritty
The above graphic shows how Venus would be utilising API3 Oracles together with auctions over OEV Network. At the heart of the service are first-party oracles that maintain price feeds (âBase Feedâ) on the respective chain according to heartbeat & deviation thresholds. These base feeds have an in-built delay (30 seconds), while the same oracles sell âreal-timeâ data over auctions on OEV Network.
Each dApp reads prices on the destination chain over a âproxyâ (see Venus BNB/USD) that is specific to them. This proxy follows the underlying base feed, but can also be updated through cryptographically signed data that was won in auctions on OEV Network. Since the base feed has a slight delay and OEV Network sells real-time data, liquidators can gain an advantage by obtaining the most recent price information over OEV Network.
When winning a bid on OEV Network, liquidators can utilise this price information to update a dApp specific âoevproxyâ (e.g. Venus BNB/USD) and perform consequent actions like liquidations exclusively for a period of time. The price update is only executable when the amount that was bid is transferred to the dAppâs control, which means that liquidators can only make use of this competitive advantage if they pay Venus in the process.
In summary, instead of waiting for oracles to update and then racing to become the first person to perform the liquidation, liquidators will now compete for oracle transactions and bundle them together with the liquidation while paying Venus for the right to do so. By adopting API3 & OEV Network, Venus has the opportunity to utilise âan oracle that pays themâ by recapturing value that has been needlessly leaking away.
The Numbers
Congratulations, you made it this far. This is a very technical and some might say âboringâ topic, so why should you even care? I mean, how big of an opportunity could this possibly be? Well, believe me when I say, if this wasnât a significant number, we wouldnât be boring you with such a lengthy write-up.
Since inception Venus has already paid out over $71 Million to liquidators, amounting to a monthly average of roughly $1.6 Million.
Just in 2024 alone over $6.2 Million were already paid out to liquidators which comes close to a monthly average of $900K.
By utilising the OEV Network, Venus enables the emergence of a competitive market for liquidations on their platform that returns value to them. Referring to similar order-flow auction designs on Ethereum mainnet and liquidator behaviour on them, Venus can expect to recuperate most of what they are paying out for liquidation incentives today.
This new income stream would allow Venus to experiment in numerous ways to attract capital or improve protocol performance. One potential usage for these funds could be a buyback and burn mechanism for the XVS token, which would immediately introduce deflationary aspects to the tokenomics. If in fact, an OEV recapturing solution would have been available to Venus since inception, and if the proceeds would have been used to buy back and burn XVS every month, a total of 6,471,500 XVS would have been burned to date. This represents nearly 40% of the current circulating supply and over 20% of the total supply of the XVS token that could have been removed from circulation entirely.
A recent analysis of âOracle Extractable Valueâ by Decentralised.co goes into the value loss that lending protocols such as AAVE are experiencing and presents how solutions such as OEV Network could recapture significant amounts of this value. Similarly a recent report of Delphi goes into the principles of OEV, different approaches to it and how OEV Network stands out.
The Proposal
With this proposal, API3 suggests to change the ResilientOracle configuration for the biggest markets on BNB-Chain to recapture OEV to the following:
- BTC - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- ETH - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- BNB - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- wbETH - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- USDT - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- USDC - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- FDUSD -{primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
- CAKE - {primary: API3, pivot: Redstone, fallback: Chainlink} with a 7.5% tolerance
This configuration allows for oracle auctions to commence over the OEV Network, as API3 is consumed as the primary oracle. The stated tolerance gives enough leeway to make sure that winning bidders will be able to perform oracle transactions that will guarantee them liquidation execution (within the tolerance), while also maintaining protection for Venus from sudden volatility spikes in short timeframes by falling back to either Chainlink or Redstone through the resilient oracle setup if the move is significant enough (and an update isnât performed through the OEV Network).
Conclusion
Current oracle solutions that Venus relies on are blind to the value that their updates create and are a leading cause for having lost over $71 Million in value to liquidators. This is value that was extracted from Venus users and ultimately TVL that had the potential to be retained within the protocol or potential protocol revenue. By utilising the OEV Network, Venus has the opportunity to recapture most of this value and continue to further set itself apart from competitors.
Useful Links:
API3 Data Feeds (dAPIs) Documentation
OEV Network Presentation at ETHZurich
Commonly Asked Questions:
What happens if the OEV Network is down?
In the unlikely event that the OEV Network is down the first-party oracles still maintain the base feeds on the respective destination chain. Liquidations can simply occur in the same fashion they do now on Venus with the liquidation bonus being paid out to the liquidator without recapturing anything. API3 is highly incentivized to keep OEV Network up and running as the fee that liquidators are being charged is the only means of monetization. API3 does not earn any revenue by running the base oracles and is thoroughly incentivized to enable a reliable experience with OEV Network.
Isnât the 30 second delay on the base feeds risky?
All dApps that utilise API3 oracles have been subject to this delay since several months and what we can say is that prices are updated immediately when it matters most (e.g. when liquidations are possible). Since âreal-timeâ data is available over OEV Network, liquidators update price feeds near instantly when an opportunity arises, oftentimes even significantly quicker than traditional oracle solutions would be doing themselves. However, incorporating a new oracle design, specifically one with an in-built delay isnât risk free and we donât want to make any such claim.
If the OEV Network is down Venus would be subject to a 30 second delay on the base feed. If liquidators wouldnât update prices quickly enough during e.g. big price movements, Venus would also be subject to the 30 second delay that the base feeds operate on. However, we believe that Venusâ design choices when it comes to oracles puts them into a unique position that significantly reduces and contains the potential here.
The resilient oracle approach with the suggested configuration of {primary:api3, pivot:Redstone, fallback:chainlink} with a 7.5% tolerance would ensure that, in the unlikely case that API3 data isnât updated fast enough in e.g. a major market downturn, Chainlink or Redstone prices would be consumed. This means that through the resilient oracle, Venus is in the unique position of utilising an OEV solution while being subjected to a fraction of the risk that other protocols would be taking on. As such, we believe that the opportunity that the recapturing of OEV presents for Venus is well worth it.
Can prices be updated with malicious data?
OEV Network is only able to auction off updates from the oracles that are also maintaining the base feed. The âoevproxyâ on the respective chain can only be updated with cryptographically signed data from the first-party oracles run by data providers themselves, which means that the majority of them would need to be compromised.
What can realistically be recaptured?
How much is being recaptured is solely dependent on liquidator activity and competition on OEV Network. OEV Network gives liquidators that utilise it a competitive edge over those that donât. Since competition is already occurring between liquidators naturally, they will be highly incentivized to utilise any tool that can potentially give them an advantage. While recapturing all of the lost value cannot be guaranteed, trends from similar order-flow auction models and behaviour on them indicate that auctions have the biggest potential to maximise retained value through the competition that arises on them.
Is it hard for current liquidators to integrate?
Not at all. Itâs additional RPC calls to OEV Network and the inclusion of the oracle update within their bundle. We have guides and example scripts available for liquidators to build upon.
Is the integration for Venus complicated?
Itâs as simple as reading a new price feed. The already written and available adapters for oracles can be used and pointed towards Venus âoevproxyâ for each utilised price feed. API3 would deploy the necessary proxies in collaboration with the Venus Technical Teams.
How is Venus being paid?
Payments are made directly to the API3 data feed contract called API3Server.sol. Each dApp has a specific proxy (e.g. Venus BTC/USD) with a whitelisted wallet that is allowed to withdraw proceeds attached to their specific proxy on API3Server.sol. When deploying proxies the wallet is simply one of the parameters included in the deployment, which allows it to withdraw OEV proceeds whenever it wants and do so permissionlessly.
Why only on BNB-Chain?
The BNB-Chain deployment offers the biggest opportunity for recapturing currently. However, OEV Network isnât limited to any specific chain and works on all current Venus Market deployments. The integration can be extended to other networks once feasibility has been proven on BNB Chain.
