Hi everyone!
My name is Alex Watts and I am the founder and CEO of FastLane. We’ve been working on OEV together with RedStone for the last year. I saw some misconceptions here about Chainlink SVR vs RedStone OEV and I wanted to point them out.
The fundamental difference between Chainlink SVR and RedStone OEV is that Chainlink sends two transactions: [tx(oracle update), tx(liquidation)] via an MEV bundle, whereas RedStone sends a single transaction: tx(metatx(oracleupdate), [metatx(liquidation)]). There is a significant difference between the levels of trust, centralization, and (most importantly) liveness risk that these two models have, which I believe is important for the Compound governance team to understand when evaluating the solutions.
Chainlink SVR fundamentally trusts the Flashbots relay to keep the oracle update and liquidation bundled together. Unfortunately, the Flashbots relay, itself, trusts block builders (titan builder, beaverbuilder, etc) and then the block relay (ultrasound, bloxroute, etc) to keep those transactions bundled together. The reason why the SVR solution only works on Ethereum Mainnet is because these trusted actors only exist on Ethereum Mainnet.
RedStone OEV, on the other hand, fundamentally assumes that all of the actors in the MEV supply chain are adversarial and dishonest. This assumption is also why the RedStone OEV solution works on all EVM networks - not just Ethereum Mainnet. Where the Chainlink solution has multiple, cascading liveness and trust dependencies, the RedStone OEV solution has none. It accomplishes this by bundling the liquidations with the oracle update inside of a single transaction. The technical term is ‘meta transactions.’ The logic for the atomicity of the liquidations and oracle updates is handled on chain via a trustless, immutable smart contract.
Importantly, this means that FastLane is not working with RedStone as an infrastructure dependency in the same way that Flashbots is working with Chainlink, which is why this sentence is incorrect:
RedStone is RedStone’s relayer. FastLane will send RedStone the liquidation operations, which RedStone takes and includes in the transaction that updates their oracle price. If FastLane goes down then RedStone’s oracle updates are not affected. Importantly, this means that RedStone can easily send transactions to the public mempool or use any relay without disrupting the value recapture by OEV.
In other words, the flow is:
FastLane → RedStone → (all relays + mempool) → proposer
And because FastLane is not in the ‘hot path’ in between the oracle network and the validator, if FastLane goes down then there is no impact on the oracle updates. This is because FastLane primarily operates as a smart contract company, and smart contracts cannot be taken offline. Our infrastructure is simply a way of getting the liquidation operations (meta txs) to the oracle - our solution was explicitly designed not to require any custom transaction relay because those relays are liveness risks that are not appropriate for security-focused lending protocols.
Meanwhile, with chainlink SVR, the flow is:
Chainlink → Flashbots Relay → (permissioned builder) → (permissioned relay) → proposer
The fundamental difference is that Chainlink’s solution depends on third parties to handle the OEV in between the oracle and the blockchain, which adds trust assumptions and dependencies to the hot path, while RedStone’s solution is a combination of gathering liquidations upstream and then settling them on-chain via immutable smart contract auction settlement logic (FastLane’s MEV entrypoint smart contract, ATLAS). Note that the downside of RedStone’s approach is that because it uses trustless smart contract logic instead of trusted intermediaries to handle the auction, it does use more gas, and while that gas cost is paid for in full by the liquidators, that increased gas cost does have an impact on how high the liquidation bids are.
In summary, Chainlink SVR’s solution maintains “atomicity” between the oracle update and the liquidation by trusting multiple parties in the MEV supply chain to behave. RedStone’s atomicity is enforced by just creating a single transaction that uses an immutable on-chain smart contract and assumes the MEV supply chain to be adversarial. If compound is comfortable with adding multiple third party trust assumptions in between itself and its oracle updates, then doing so could lead to marginally higher OEV revenue by virtue of the reduced liquidation gas cost. However, if compound prioritizes decentralization and trustlessness, then it’s clear to me that it would choose the solution that uses immutable smart contract logic rather than trusting handshake deals with block builders and relays.