Additional revenue stream for Venus from liquidations

Venus Governance Venus - Governance Proposals
1

Introduction

RedStone is the fastest growing Modular Oracle with $8B+ Total Value Secured (TVS) across 100+ chains, used by some of the most renowned protocols in the DeFi space such as Venus, Spark, Morpho, Pendle, Compound, Silo, Gearbox and many others. Apart from delivering blue chip assets price feeds, we specialize in yield-bearing collateral for lending markets, closely cooperating with protocols like Securitize (as the official oracle for BlackRock BUIDL, Apollo ACRED, VanEck VBILL), Lombard (LBTC), Renzo (ezETH), Ether.fi (weETH), Kelp (rsETH), Puffer (pufETH), Ethena (USDe & sUSDe) and many more. A non-exhaustive list of our current Partners can be found here.

RedStone feeds are currently utilized by Venus on Unichain for all markets and the BNB chain for BNB and BTC. RedStone proposes upgrading existing Venus data feeds on Unichain and BNB Chain with OEV services to grow Venus’ competitive edge over other lending markets on both of these ecosystems.

RedStone OEV is a service that not only provides the Venus DAO with higher value-capture, but it also makes the core Venus product more secure and robust by enabling faster liquidations than the status-quo. By allowing faster liquidations without trade-offs, RedStone OEV can enable Venus to offer more competitive risk parameters, and provide better experiences for Venus users in the form of higher yield, and greater protections from bad debt.

Technical Components

Fastlane Infrastructure: Fastlane has operated MEV auctions for the majority of the top validators on Polygon PoS including Coinbase, Binance, Figment, and over 70% of Polygon PoS stake, maintaining a stellar reputation. Fastlane is purely a data source for RedStone OEV, RedStone relayers themselves can generate and propagate Atlas transactions that can be sent to any public or private mempool.

Atlas: Atlas is a multicall or ERC-4337-like smart contract framework for customizing auctions that settle on-chain using a try/catch loop of many bidders. Notably, Atlas enables single atomic transactions that contain both a data feed update, and OEV-capturing liquidations. If all Atlas liquidations fail, the Atlas smart contracts ensure that the standard feed update is still processed in the same transaction, so Venus can fall back immediately to non‐auction liquidations.

Auction Trigger: RedStone OEV enables “push” data feeds to also respond to liquidator-triggered data feed updates coming from a low latency pull oracle. These OEV-triggered data feed updates occur between deviation thresholds and heartbeats. Each time the price changes off-chain in the RedStone pull oracle, this price is delivered to Fastlane, and an OEV auction is hosted.

Auction Operator: A single operator—Fastlane Labs, a long‑term RedStone partner—runs the 200ms off‑chain auction; if Fastlane fails to respond back to RedStone within 300ms from the new off-chain price being delivered, RedStone relayers immediately fall back to sending a standard feed update.

Auction Details: Connecting as a bidder is permissionless, you simply start reading from a websocket and utilize the SDK to submit bids. Every OEV bidder is split into two tiers; a high-reputation tier, and a low-reputation tier. Any new bidder who joins will be immediately placed into the low-reputation tier. The top 5 bidders from each reputation tier (10 bidders in total) are selected for on-chain auction settlement. These top 10 bidders are then aggregated together and ordered by bid amount regardless of their reputation. This ensures a high bidding but low reputation solver can be ordered first, and has a fair shot at winning the auction.

Auction Settlement: RedStone OEV auctions are uniquely settled on-chain (i.e the winning bidder is determined on-chain) using the Atlas smart contract framework. Atlas executes multiple liquidator operations on-chain in a try/catch loop immediately and atomically, ordered by their bid amount.

  • If a solver fails to pay its bid within the allocated gas, their actions (liquidation) are reverted and the next solver in line is tried.

  • The gas cost of a solver operation is subtracted from the solver’s escrowed balance regardless of whether they fail or succeed, and is paid to the transaction sender.

  • A successful solver must pay the gas cost of the entire transaction minus the gas costs incurred by any failed solvers.

  • The Atlas contract enforces per-operation gas limits, preventing one malicious liquidator from jeopardizing other liquidators, or the standard data feed update.

  • To be considered eligible for inclusion in the array of Atlas SolverOperations, a solver must only “escrow” funds in advance to cover gas costs. This escrowed balance is used to atomically repay the upfront gas costs of the transaction back to the oracle operator who sent it.

  • If all Atlas liquidation attempts fail, the data feed update will still be processed by Atlas, and available to Venus without delay.

Value Accrual: Value is distributed on-chain atomically at the end of every Atlas transaction to two parties: RedStone, Fastlane. The value flow can be clearly followed on-chain, and the fee splits are configurable parameters on-chain. The value is gathered by RedStone in a multisig, and distributed monthly to the Venus DAO.

Integration
No changes to the data feed or code are required. Venus must simply keep using existing RedStone data feeds.

Fallback and Resilience
Auctions may begin anytime the off-chain RedStone price changes. If 300ms has passed since the RedStone off-chain price change without any valid auction result response from Fastlane (this encompasses both no bids and infrastructure outage), the price is posted normally by RedStone. Liquidations using the standard bonus can then occur immediately, backrunning the RedStone update. Note that we plan to reduce the fallback time from 300ms to 200ms in the near term, with the goal of ensuring RedStone OEV cannot delay liquidations.

Fastlane can in no way manipulate the data. If Fastlane suffers downtime, in the worst case scenario, Venus will not capture OEV and liquidations will happen as previously, after the 300ms delay, until OEV is turned off by RedStone. If Fastlane unfairly hosts the auction, again the worst that could happen is Venus will not capture OEV, but liquidations will occur without delay.

This results in RedStone OEV having the easiest to understand risk-profile—it’s simply the SLA between RedStone and Fastlane—and the best “worst-case” scenario thanks to our 300ms low-latency auction window and instant fallback to a vanilla price push. These properties make RedStone OEV the most resilient auction to adversarial behaviour; the single most important property for time-sensitive operations such as liquidations.

Emergency Controls
RedStone OEV uniquely enables Venus to turn OEV on/off without changing the data feed contract that the Venus protocol utilizes. RedStone is in control of turning off the OEV mechanism, and the ability to trigger RedStone to do this can be implemented in any way deemed best. At any time, a risk management service provider or risk council can alert RedStone, and OEV can be turned off immediately, leaving Venus protocol in a default state without any delays to data feeds.

Economic Considerations

The market standard for OEV division lands around 60-70% going to the protocol. Given the long-lasting relationship between Venus and RedStone, we suggest a competitive split of 20/80 from proceeds, the larger part going to Venus. It’s entirely up to Venus’ discretion to decide where and when the gathered funds to be sent out.

Audits
A comprehensive audit of the v1.5 Atlas smart contract framework was completed by Certora, with another audit completed by Spearbit for some recent changes in v1.6 atlas/audits/Atlas v1.5 - Certora.pdf at main ¡ FastLane-Labs/atlas ¡ GitHub, atlas/audits/Atlas v1.6 - Spearbit.pdf at main ¡ FastLane-Labs/atlas ¡ GitHub. The off-chain architecture is closed source, but as we stated earlier, the auction settles on-chain in a transparent fashion that would allow any party to audit the auction behaviour very thoroughly.

Conclusion
Integration is beneficial for Venus’ sustainability. It doesn’t require any code changes or action by Venus, providing a unique competitive advantage in the Unichain and BNB Chain ecosystem. RedStone, as a long-standing Venus partner, is committed to further growing its ecosystem.

1 Like
2

We appreciate RedStone continued support of the Venus ecosystem and recognize the potential of this OEV integration to enhance protocol efficiency, capture value for the DAO, and improve liquidation responsiveness.

:white_check_mark: We are in favor of this proposal and recommend it for approval.

However, given the sensitive nature and concentration of TVL on the BNB Chain, we strongly encourage starting with a pilot on Unichain or Ethereum. This controlled rollout would allow us to evaluate real-world performance, monitor auction behavior, and validate technical reliability under live conditions, without exposing core markets to potential risk.

Pending positive outcomes from the pilot, we would support a broader deployment to BNB Chain in a phased and informed manner.

1 Like
3

Fully support the integration of RedStone’s OEV solution into Venus.
Capturing MEV from liquidations and turning it into a direct revenue stream for the protocol is a smart move — especially if it can be done securely and without disrupting existing liquidators.

1 Like