Summary
Type: RFP Response Assessment
Timeline: From 2025-06-09 To 2025-06-16
Scope
The submission for assessment was received in the context of the Request for Proposal (RFP): Oracle Extractable Value (OEV) Solution for Compound Protocol issued on the Compound Forum. The assessment focused on the information submitted by the RedStone team regarding the proposed OEV solution and its potential integration into the Compound Protocol.
The assessment did not include a code review of the RedStone infrastructure.
Introduction
The RFP clearly outlines the motivation behind seeking an OEV vendor for the Compound Protocol. The assessment investigated the information provided by the RedStone team within their submission and evaluated the proposed solution for any security concerns within the context of intended integrations with Comet Markets.
Vendor Overview
Vendor Information
Vendor Name: RedStone
Auction Mechanism: Off-chain Order Flow Auction (OFA)
Compound Compatibility: FULL
Architecture
When RedStone oracles reflect a price update which creates an OEV opportunity, this price is delivered to Fastlane, which then hosts an OEV auction. Searchers joining the auction are split into two different reputation groups (low and high reputation). For each auction, ten bids are aggregated (the top 5 bids from each group) and the transactions from the bidders are then ordered for on-chain settlement and included in the transaction payload.
Crucially, this transaction includes the call to update the on-chain price feed with the new price. The RedStone relayer then broadcasts the transaction to a public or private mempool. It should be noted that the bidder needs to place in escrow the amount necessary to cover the gas costs of the successfully executed transaction. By bundling the oracle update transaction together with the searchers’ transactions, the RedStone OEV solution can recapture the value that would otherwise be lost to MEV.
Trust Assumptions
These following trust assumptions were highlighted in the RedStone submission:
Fastlane: RedStone has a service-level agreement with Fastlane. As such, the Compound Protocol would need to trust that Fastlane would honor this agreement and fairly operate as the Auctioneer.
RedStone Relayer: The RedStone relayer is (together with the Fastlane dappController) responsible for transmitting the transaction payload containing the price update.
It is noted that the transaction data can also, after a short delay, be pushed on-chain permissionlessly should both Fastlane and RedStone fail to do so.
Auctions
The off-chain component of the auction is hosted on Fastlane and is triggered when the price supplied by the Restone oracle changes. The bidders are divided into high- and low-reputation groups, each containing five bidders. The top five bids from each group are collected and returned. Bidders must provide enough funds in escrow to cover the successful execution of their transaction.
The auction result must be reported back to the RedStone relayer within 300ms, otherwise the price update will be pushed on-chain. If the auction result is successfully returned to RedStone, the transaction is relayed to any public or private mempool. At this point, the bids are executed in order on-chain using the Atlas smart contract framework. The transactions from each searcher are executed within a try/catch pattern, and the sender of the transaction is refunded the gas cost of that specific execution.
Governance Model
The on-chain OEV component which a Comet Market will integrate with is not upgradeable. For the off-chain components it is noted that Fastlane would alert the DAO in the case of changes.
Historical Performance
RedStone’s OEV solution was used in an alpha test in late 2024 on the BNB network. The trial was limited to the BNB and BTC price feeds used by the Venus protocol. However, issues were reported regarding missed OEV opportunities. These issues are noted to have been caused by BNB chain node issues, as well as a faulty liquidator implementation (used only for testing). Fallback methods functioned normally during the issues encountered during the trial.
The RedStone OEV solution is currently live on Berachain and BNB chain, with deployment on HyperVM being in progress.
Audits
The on-chain components of the system have been audited and are available in the supplied audit repository at commit 5b07082.
Key Differentiators
When considering the RedStone OEV solution, there are several key considerations to keep in mind. The solution proposed does not add latency to the existing liquidation logic. In addition, searcher participation is not constrained by the size of the escrow because the escrow is limited to the gas cost required for the liquidation transaction to execute.
The off-chain nature of the OFA hosted by Fastlane means that gas costs are limited to the execution of the price update and executed backrun transactions which attempt to capture value (gas costs are paid regardless if the transaction was successful). The Atlas execution abstraction framework allows the system to emulate a trusted execution environment for price updates and value capture.
The mechanism design also allows for RedStone’s OEV solution to be implemented into a resilient price oracle design, while still keeping current Chainlink feeds as fallbacks. This provides some flexibility should the DAO wish to retain Chainlink oracles as a fallback.
Requested Security and Risk Assessment Responses Checklist
The following table evaluates each of the specific responses given by the OEV vendor to the questions related to security/risk assessment requested by the Compound Governance Working Group.
| Data Required (Question) | Supplied | Comment |
|---|---|---|
| a) Trust Assumptions | ||
| i) List new trust assumptions Compound would take on | Yes | |
| ii) Identify actors Compound needs to trust | Yes | Fastlane |
| iii) Outline potential issues and consequences | Yes | |
| iv) Clarify who operates oracle nodes (team/third parties/decentralized) | Yes | |
| v) Describe the consequences and mitigations for component misbehavior | Yes | |
| b) Audits | ||
| i) Provide links/summaries of completed audits | Yes | |
| ii) Indicate if any parts are closed-source/proprietary | Yes | Off-chain components are closed source |
| iii) Explain assurance methods for security | Yes | |
| c) Production Testing and Simulations | ||
| i) Detail how product testing has occurred | Yes | |
| ii) Specify if tested in major market volatility or only simulations | Yes | Alpha trial conducted |
| iii) Provide post-mortem analyses and transparency examples | Yes | |
| iv) Describe issues encountered (if any) and resolution processes | Yes | |
| d) Oracle Accuracy and Manipulation Resistance | ||
| i) Explain mechanisms ensuring oracle price accuracy | Yes | Refer to RedStone Feed architecture |
| ii) Detail protection against malicious price manipulation | Yes | |
| e) Failure Modes | ||
| i) Thoroughly describe worst-case scenarios | Yes | |
| ii) Explain auction failure handling | Yes | |
| iii) Specify risk periods without liquidation capability | Yes | |
| iv) Walk through the hypothetical “nightmare scenario” and mitigation | No | |
| f) Insurance and Recourse | ||
| i) Confirm availability of insurance or recourse | Yes | Not for pilot. For full rollout, it would need to be negotiated |
| ii) Specify willingness to establish insurance fund | Yes | |
| iii) Explain compensation process for incorrect liquidations/bad debt | Yes | |
| iv) Indicate if revenue allocation for insurance is proposed | Yes | No set percentage |
| g) Upgrade and Maintenance Security | ||
| i) Explain governance for upgrades | Yes | Non-upgradeable |
| ii) Describe controls around contract/system updates | Yes | N/A to on-chain components |
| iii) Provide details on communication protocols for changes | Yes | |
| h) Responsible Disclosure | ||
| i) Confirm the existence of a responsible disclosure program | Yes | In-progress |
| ii) Provide links or descriptions for bug bounties/guidelines | No | |
| iii) Describe the internal disclosure process if no formal links are available | Yes | |
| i) Security Incident Monitoring and Management | ||
| i) Provide security incident management protocol | Yes | |
| ii) Explain incident communication with clients | Yes | |
| iii) Describe continuous monitoring practices | Yes | |
| j) Developer Support | ||
| i) Provide developer documentation and best practices links | Yes | |
| ii) Confirm developer support availability | Yes | |
| iii) Specify support for the provided format | Yes | |
| iv) Provide contact details for proposal inquiries | Yes | |
| k) Real-time Metrics | ||
| i) Confirm provision of real-time metrics on liquidations/OEV | Yes | |
| ii) Explain data sourcing methodology and metric calculation | Yes | |
| iii) Detail verification processes for DAO members | Yes | |
| iv) Clarify DAO metrics sharing approach | Yes |
Conclusion
The reviewed submission supplied the information required as per the RFP issued on the Compound Forum. The RedStone OEV solution can be integrated into the Compound v3 Comet Markets without making any changes to the protocol contracts. An additional trust assumption regarding the Fastlane auctioneer has been highlighted in the supplied document.
The assessment highlighted key areas of consideration, which relate to the low latency achievable by this solution, as well as the low barrier to participation for searchers due to the low escrow requirement. However, it is also noted that an alpha trial conducted on the BNB network in late 2024 revealed issues related to integrations with supporting infrastructure. The DAO may also wish to explore implementing a resilient oracle design using this OEV mechanism.
No technical barriers were identified that could preclude integrating the RedStone OEV solution into a Comet Market on any supporting chain.
We would like to thank the RedStone team for their submission and their responses to our questions.