RedStone OEV
Hi all, I am Mike Massari, Strategic Advisor at RedStone and leading the OEV stream. Previously, I was Director of Platform and Integrations at Chainlink from 2022 to 2024. Below, please find the RedStone proposal for OEV feeds on Compound. If you have any questions please feel free to reach out.
- General Overview
RedStone is the fastest growing Modular Oracle with $10B+ Total Value Secured (TVS) across 70 chains, used by some of the most renowned protocols in the DeFi space such as Spark, Morpho, Pendle, Venus, Compound, Veda, Silo, Sommelier, 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 Lombard (LBTC), Renzo (ezETH), Ether.fi (weETH), Kelp (rsETH), Puffer (pufETH), Ethena (USDe & sUSDe) and many more. RedStone is live on 70+ chains. A non-exhaustive list of our current Partners can be found here.
-
List Existing Associations with Compound Protocol/DAO:
RedStone feeds are currently utilized by Compound on Unichain -
Explicitly list ALL of the chains that you are intending on applying for integration on (options include Ethereum mainnet, Base, Arbitrum, Unichain, Optimism, Polygon, Mantle, Scroll, Ronin, and Linea):
Unichain, Polygon, Base, Arbitrum, Optimism
Section 1: Technical Questions
1a) Technical Overview:
Components
Fastlane Infrastructure: Fastlane is purely a data source for 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. The atomicity of operations within Atlas, and the RedStone relayer itself sending the transaction to the regular mempool, ensures that the individual data feed operations cannot be re-ordered, or delayed by a third party RPC service. If all Atlas liquidations fail, the Atlas smart contracts ensure that the standard feed update is still processed in the same transaction, so Compound can fall back immediately to non‐auction liquidations.
Off-Chain Process
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 pushed, RedStone relayers immediately fall back to sending a standard feed update.
Auction Filtering: 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.
Transaction-Inclusion: The RedStone relayer itself, not a third‑party builder or liquidator, broadcasts the OEV transaction to any mempool (public or private).
On-Chain Process
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 Compound 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.
1b) Integration & Compatibility:
No changes to the data feed are required, Compound must simply use existing RedStone data feeds.
1c) 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, which should help ensure RedStone OEV does not delay liquidations even a single block (even on most L2s).
1d) Existing Price Feed Compatibility:
The RedStone OEV mechanism does not inherently require replacing Chainlink feeds entirely. The Resilient Price Oracle design pioneered by Venus Protocol could allow RedStone to act as the main oracle, providing all of the benefits of RedStone OEV, while allowing Chainlink to function as a fallback oracle in the event that the RedStone price deviates from the Chainlink price by greater than X%. Compound DAO can configure the deviation that must be upheld between RedStone and Chainlink before the price falls back to Chainlink.
1e) Auction Details:
- Connecting as a bidder is permissionless, you simply start reading from a websocket and utilize the searcher SDK to submit bids.
- RedStone auctions are uniquely settled on-chain. This provides transparency into the top X (~10) bidders in the auction, and will make it easy for the public to identify censorship or mis-behaviour from Fastlane as the auctioneer. In addition, 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 for years, maintaining a stellar reputation.
- Time-based exploitation and last-minute bid sniping is not possible as it is a sealed-bid auction.
Settling the auction on-chain has the fewest trust-assumptions, risks, and points of failure. This is the only way to achieve sufficient guarantees of value capture in highly adversarial environments, and to lower the latency of data feeds and liquidations.
-
Ensures operation ordering (i.e OEV liquidations directly preceding oracle updates) is respected without trusting anyone, even the validator. This removes the requirement for on-chain time-based fallbacks as implemented by SVR and API3, instead the data feed can always return the most recent price. This is a core principle that is required to lower the latency of liquidations.
-
Ensures that without trusting any off-chain simulation, prediction, or escrow, the auctioneer can find the truly highest paying bidder in a trustless way on-chain. This is a core principle that is required to operate permissionless OEV auctions without requiring liquidator bid escrow. As described above, any bidder can immediately connect to the auction and will have a fair chance at being included in the 5 low-reputation slots.
-
Ensures there is no uptime reliance on centralized third party mempool services, and no ability to delay the data feeds or liquidations outside of Fastlane itself.
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.
1f) Auction Timing & Block Coordination:
- Auctions are constantly being run every time the off-chain price deviates by any amount. This happens every 300ms-2s on average.
- The oracle update and the liquidation are “operations” within a single Atlas transaction. There is no possibility of re-ordering within the block, or landing in separate blocks.
1g) Timeliness of Liquidations:
The mechanism is designed such that liquidations can only occur faster than they otherwise would have, by allowing them to be triggered at any time by a low-latency pull oracle, rather than after a deviation threshold. The auction delay can be handled such that it never causes an oracle update to be delayed by a single block, even on chains with block times > 400ms, again we expect to lower this to 250ms to encompass L2s.
1h) Latency Optimization Techniques
Fastlane utilizes infrastructure and reputation mechanisms developed from years of running MEV auctions to ensure high value-capture and low latency. RedStone price relayers are co-located with the auction infrastructure to minimize latency. Solvers can also co-locate with the auction service.
1i) Auction Participation & Incentive Design:
On-chain auction settlement ensures that the auction can remain permissionless on any EVM chain regardless of the market microstructure to transaction inclusion (ETH mainnet vs. L2). Fastlane and RedStone will never compromise on permissionless participation for liquidators.
The auction has very minimal barriers to entry, only escrowing enough funds for a single transaction’s gas costs. By allowing participation without significant escrow, bidder participation should be very diverse, and dominant players cannot compound their gains into structural advantages.
After adoption of RedStone OEV, the process of executing Compound liquidations will become identical across chains. By abstracting chain-specific nuances to liquidations, such as bidding to block builders on ETH mainnet vs bidding via complex spam tactics on OP stack, this should help unite a fractured Compound searcher network across many chains into a single unified network.
1j) Cross-Chain Operations:
RedStone OEV can support any EVM chain in a maximum of a 2 week timeframe. The mechanism, performance specs, and risks of the OEV service will remain the exact same across chains. This enables Compound to quickly scale OEV across a wide array of chains without governance overhead each time.
1k) Market Support & Asset Readiness:
RedStone OEV can currently support every market on the proposed chains.
1l) Emergency Controls:
RedStone OEV uniquely enables Compound to turn OEV on/off without changing the data feed contract that the Compound 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 Compound protocol in a default state without any delays to data feeds. Compound could implement an on-chain kill-switch, similar to the one being proposed related to LST failures, to do this.
Section 2: Economic Considerations
2a) Revenue Split and Fees:
– 60 % → Compound treasury
– 20 % → RedStone
– 20 % → RedStone (in the form of delegated COMP)
Split is fixed on every market
2b) Additional Costs:
There are no additional costs.
2c) Expected Value Capture:
As RedStone OEV has not had a deployment with outside liquidators, we cannot make claims based on previous deployments. In Fastlane’s experience operating MEV auctions for multiple years, and viewing public MEV-Boost data for Compound and other similar protocols, we expect re-capture rates of ~90%.
2d) Revenue Distribution & DAO Accounting:
Currently, the revenue is captured by RedStone and then split as per the above breakdown. Value can be sent on a weekly basis to a Compound treasury address.
The revenue is currently in native tokens, although the auction can specify any asset to be used (i.e USDC or COMP). The proceeds can be easily tracked and the movement is fully transparent on-chain.
Section 3: Security and Risk Assessment
3a) Trust Assumptions:
The sole new trust assumption Compound would take on is that Fastlane upholds its SLA with RedStone regarding uptime, and fairly operating the auctioneer role. Fastlane can in no way manipulate the data. If Fastlane suffers downtime, the worst that could happen is that Compound will not capture OEV, and liquidations may at worst be delayed by 300ms. If Fastlane unfairly hosts the auction, again the worst that could happen is Compound will not capture OEV, but liquidations will occur without delay. There are clear and strong consequences for Fastlane mis-behaviour in terms of reputation, as this could cause a loss of all existing Fastlane business including operation of auction for ~70% of Polygon PoS stake, and future Fastlane endeavours in MEV auctions for Monad validators, and other Atlas customers. Operating MEV auctions is Fastlanes core business, and mis-behaviour effectively would cause the company to lose all value.
RedStone oracles nodes are operated by third-parties in a decentralized fashion.
3b) 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.
3c) Production Testing and Simulations:
A RedStone OEV alpha trial phase was conducted on the BNB and BTC data feeds of the Venus Protocol on the BNB chain from November 2, 2024 until December 5, 2024. This alpha trial notably did not include any outside liquidator bots. Liquidator bots were only operated by the RedStone and Fastlane teams during this period, so OEV re-capture rates will not reflect the re-capture that can be expected in future iterations. That being said, this alpha trial did serve as a way to stress test the Atlas system and its ability to consistently land OEV-capturing liquidations.
KPIs
Total Volume Liquidated by RedStone OEV: $157,887.14
Total OEV Captured by RedStone OEV (BNB) = 6.44
Total OEV Bid Amount: $4,325.90 (Calculated using BNB prices where applicable: $672.98, $632.15, and $717.26)
Total OEV Available: $8,649.66
Volume Missed by RedStone OEV: 65909.71
Post-Mortem of Missed Volume
No issues to the core RedStone OEV processes were detected in the trial period. The reasons for missed liquidation volume fall into two categories:
- BNB chain node issues that caused faulty simulations in the Fastlane Auctioneer and RedStone Relayer.
- Downtime or bugs in the Fastlane liquidator implementation.
Since auctions settle on-chain, simulations are not necessary and are strictly a nice-to-have. Dependencies on simulations can be removed for RedStone OEV, and liquidator bot issues will be corrected by on-boarding permissionless liquidators. Outside of these issues, no delays were caused in any liquidations during this period by the core Atlas architecture.
The fallback method functioned properly in all cases, fallback standard data feed updates were sent on-chain by the RedStone relayer after 500ms without a valid auction response from Fastlane (reduced to 300ms now). The following will explain the reasons why fallback updates occurred when in fact there was OEV available (missed OEV volume).
3d) Oracle Accuracy and Manipulation Resistance:
RedStone OEV uses the exact same feed architecture that already secures ~10bn of TVS, and that has a track record of working for the past 3 years without any incident.
3e) Failure Modes:
Liquidations cannot be delayed by RedStone OEV past 300ms in the absolute worst-case. If Fastlane infrastructure is offline or malfunctioning, RedStone relayer will deliver the price in the regular fashion after at most 300ms. This being said, at any time if issues prevent themselves, RedStone OEV uniquely can be turned off immediately by a kill-switch triggered by RedStone themselves, Gauntlet, or others.
3f) Insurance and Recourse:
For the Pilot, we won’t include an insurance buffer in order to move quickly and validate performance. For a full rollout on major Compound markets, we’re happy to set aside an insurance fund—drawn from a percentage of OEV revenue—to cover any protocol losses (e.g. under-payment bugs or wrongful liquidations) resulting from system errors or bugs
3g) Upgrade and Maintenance Security:
The Atlas related contracts are public and immutable. Fastlane would be happy to agree to alert Compound to any changes made to the off-chain architecture.
3h) Responsible Disclosure:
Responsible disclosures are currently handled through the publicly advertised Discord, X, and email channels for RedStone. RedStone and Fastlane are currently developing a bug bounty program.
3i) Security Incident Monitoring and Management:
24/7 monitoring is in place, and security incidents are reported to a shared channel with clients. This is implemented by a pager-duty system with engineers constantly on call, and being alerted to a number of potential issues or events within the system.
3j) Developer Support:
There are no code changes required to integrate the solution. RedStone documentation could be found here — Introduction | RedStone Documentation
3k) Real-time Metrics:
Real-time metrics on % of value captured relative to value available, and % of volume liquidated relative to volume available will be provided in a Dune dashboard that can be independently verified by DAO members. In addition to this, Fastlane can provide an open source script to the DAO that will present more detailed analysis of gas pricing, gas usage, auction competitiveness, and inclusion time.
Final Considerations
RedStone provides the only OEV service that actually makes the core Compound product better by enabling faster liquidations than the status-quo, with extremely minimal potential for delays. In comparison, other OEV solutions can at best execute liquidations at the same speed as the status-quo—and at worst suffer multi-block or multi-second delays.
As was stated in this article from Gauntlet on DeFi liquidations: in an environment where money markets compete aggressively in capital efficiency, the protocol with the fastest and most robust liquidation engine will face the least bad debt over the medium term, and provide the most value to users. By allowing faster liquidations without trade-offs, RedStone OEV can enable Compound to offer less conservative risk parameters—critical, as this analysis shows, to competing head-to-head with Aave. This presents Compound with an opportunity to adopt a superior OEV compared to SVR, and to gain a competitive advantage over Aave.
Finally, our vision is that to win monolithic lending it will require close relationships and alignment between the DAO’s service providers—especially the oracle. RedStone and Fastlane have driven real innovation in this space, and we’re already collaborating with WOOF! and Platonia on future advances like partial liquidations, and dynamic liquidation-penalty feeds. We believe these tools will unlock new composability and capital-efficiency gains for Compound v4 and beyond, and look forward to partnering tightly with your developers and mechanism designers to iterate faster and outcompete Aave.