Relayer Extractable Value (REV)
Cross-chain transactions are susceptible to a new type of MEV
note: this is a repost/revision of a blog post i wrote in september of last year on medium. im migrating it to my substack with revisions and updates.
over the past year, we’ve seen the unveiling of new chains and L2s, rollup frameworks, and Rollups-as-a-Service solutions. we now know that one thing is certain: the future will have an ever-increasing number of chains.
as this accelerates, the role of cross-chain interoperability protocols (e.g., IBC, Wormhole, etc.) becomes more and more critical.
in practice, interoperability protocols are just an agreement for two chains to speak to each other in a structured and cryptographically verifiable way (e.g., “mint X tokens to Y”).
the less sexy part of cross-chain is relayers, off-chain entities that monitor chains for protocol-specific messages and deliver them to destination chains. without them, interop protocols would not be able to function.
relayers are truly the unsung heroes of interoperability.
sadly, while relayers are instrumental in enabling cross-chain communication, they can be costly to operate and maintain–especially at scale. historically, running relayers has been either under-incentivised or not incentivised at all, resulting in few entities willing to take on the role.
often, the responsibility of running relayers falls on interop protocols’ core teams, protocol foundations, or third-party entities that receive grants to manage them. running relayers is generally seen as a loss leader for other parts of an entity’s business (e.g., marketing for a wallet, delegation leads for validators).
REV as relayer monetisation
since it has historically not been possible to run a relayer profitably, a new opportunity for value capture has emerged for relayers in the cross-chain transaction process. we can call this opportunity Relayer Extractable Value (REV).
we define REV as “the maximum value that a relayer can extract from being a privileged actor in the cross-chain transaction flow”.
relayers not only have visibility into the incoming messages onto a destination chain, they also have the ability to choose when to submit a transaction for execution. said differently, relayers have the privileged role of being a “transaction initiator” on the destination chain.
as such, relayers can order the transactions into a bundle before delivering it into the destination chain. in this worldview, relayers shift from being “dumb” entities that naively move messages to an intelligent combined relayer-searcher entity.
as the multi-chain ecosystem matures and continues to proliferate, the importance of REV will grow, becoming an increasingly relevant opportunity for relayers. at Catalyst, we believe that–much like the concept of Maximum Extractable Value (MEV) broadly–REV must be comprehensively understood, measured, and distributed within the REV supply chain.
just as existing MEV solutions are designed to minimise “malicious MEV”, similar considerations should be applied to REV that could be harmful to end-users.
it’s important to note that, while REV can be seen as a subset of cross-domain MEV as a whole, its scope is much more narrow.
cross-domain MEV are MEV opportunities that span multiple domains. a popular example is arbitrage of asset prices across two chains. to date, cross-domain MEV research has focused on how to extract cross-domain MEV–whether through holding inventory on two chains to perform the stat arb, or being a validator for both chains every N blocks.
in contrast, REV focuses purely on cross-chain transactions–i.e., transactions that require a relayer to pass messages between domains (e.g., bridging, cross-chain liquidity networks, cross-chain DEXes, cross-chain lending).
The REV supply chain
before diving into the details of REV, let’s go over the domains involved in cross-chain interactions and the key actors associated in each.
three domains:
origin chain: the chain where the cross-chain message originated.
cross-chain communication protocol: the protocol where the cross-chain message is communicated.
destination chain: The chain for which the cross-chain message is destined.
The origin chain
the origin chain is subject to the MEV supply chain that we all know and love. Uusers have intents and submit transactions to the mempool via their wallet of choice. searchers combine transactions into bundles that are then submitted (alongside bids) to validators for inclusion, where validators are incentivised to choose the bundles with the highest bids. For Ethereum and other PBS-employing blockchains, a builder entity can sit between the searchers and validators.
currently, any cross-chain transaction must first be executed on the origin chain before being queued up and relayed to the destination chain via the interoperability protocol (e.g., message is placed into an “Outbox” contract of the interoperability protocol before being picked up by a relayer).
as a result, cross-chain transactions may be subject to vanilla MEV extraction on the origin chain, even before the cross-chain communication begins. this MEV opportunity is outside of the scope of this post.
The interoperability protocol
here, the messages are en route to the destination chain–with relayers carrying messages from one domain to another.
interoperability protocols may have their own MEV mitigation mechanisms. IBC has the concept of “ordered channels” where packets have a canonical ordering. LayerZero also has enforced ordering baked into its protocol. some protocols are looking into the implementation of threshold encryption in order to obfuscate the contents of a message.
with that said, the majority of protocols do not have payload encryption nor canonical ordering and therefore messages can be seen and re-ordered by relayers as they see fit.
The destination chain
finally, the messages are delivered to the mempool of the destination chain (plus gas to execute them–supplied by the relayer).
a savvy relayer will order the messages into a bundle before delivering it into the mempool, such that there is no additional MEV to be extracted.
if that doesn’t take place, then the MEV supply chain mirrors that of the origin chain (e.g., searchers, builders, validators, etc.). however, in the context of REV and the existence of informed relayers, that should rarely happen–as the arriving bundle should have no additional MEV to be extracted.
as such, the domains can be simplified to the origin chain MEV supply chain, and then the cross-chain MEV supply chain. said differently, relayers are a subset of searchers in the destination chain’s MEV supply chain.
now, let’s examine a few illustrative examples of REV in the real world.
Relayer Sandwiching Users
user wants to swap 1 ETH from OP Mainnet for MATIC on Polygon PoS via Catalyst.
user initiates a cross-chain swap with specified parameters, including a slippage tolerance.
relayer picks up the user’s OP Mainnet message to deliver to Polygon PoS, seeing their desired swap and slippage tolerance.
before delivering the user’s message onto the target chain, the relayer submits a bundle of transactions, sandwiching the user’s incoming transaction.
this tactic involves front-running the user’s swap until the slippage tolerance is reached, after which the relayer backruns the swap as well.
Just-In-Time Liquidity Providing (JIT LPing)
Alice is a big money spender and wants to swap 100 ETH from OP Mainnet for MATIC on Polygon PoS via Catalyst.
relayer picks up her OP Mainnet message to deliver to Polygon PoS and sees her large incoming swap.
by leveraging flash loans, Relayer can quickly deposit a large amount of ETH and MATIC into the relevant Catalyst vaults–effectively becoming a significant LP for this incoming high-value swap.
relayer delivers Alice’s message onto Polygon PoS, and earns an outsized portion of the pool’s liquidity fees.
afterwards, Relayer withdraws its assets and returns the flash loan, having made risk-free money from Alice’s swap.
recall that steps 3–5 can all be bundled into one block on the destination chain.
Withholding Messages for Ransom
although relayers can’t alter the contents of a cross-chain message, they may hold the power to withhold message delivery, exploiting the urgency of certain transactions and thus extracting additional value.
user holds a collateral on a lending protocol on Arbitrum, but has bridged the debt to Scroll.
markets have shifted and now the user faces potential liquidation of their assets on Arbitrum.
user wants to bridge back to Arbitrum in order to top up their collateral position and stave off liquidation.
the time-sensitive nature of the transaction may also force them to offer higher fees for faster relaying.
seeing this, relayers can opt to withhold the relaying of the message, forcing the user to keep increasing their fees in order for the message to be relayed.
Designing Systems to Capture REV
at Catalyst, we believe in the notion of “sovereign MEV”. this entails capturing the MEV generated within a system and having the ability to distribute it for the benefit of the system (e.g., through funding public goods, rewarding liquidity providers).
eventually, we envision capturing the REV that is generated in cross-chain swaps on Catalyst.
relayers essentially play the privileged role of a “transaction initiator” on the destination chain. in order to effectively capture REV, a temporary monopoly can be created (with enforced principles like timely delivery) and given to a relayer in order to relay and execute the cross-chain message.
three potential approaches emerge:
Relayer Order Flow Auction (ROFA): OFA for the “right to relay”.
relayers bid for the exclusive right to relay cross-chain transactions. this can be for all swaps within a specified timeframe or simply for each swap. this auction-based system ensures that the most competitive relayers gain the privilege of relaying.
here’s how the ROFA would work:
auction setup: at the start of each auction cycle, a set of cross-chain transactions that are ready to be relayed is identified. these transactions could include swaps, transfers, or any other cross-chain message.
bidding: relayers who wish to participate in the auction submit their bids. these bids represent the fee that the relayer is willing to pay in exchange for the right to relay specific transaction(s).
auction period: the auction runs for a predetermined period of time, during which relayers have the opportunity to submit their bids. this ensures that there is enough time for relayers to analyse the available transactions and simulate how much REV that they can extract, thus informing their bid amount.
bid evaluation: at the end of the auction period, the bids are evaluated based on a set of criteria, including bid amount and other factors. the winning bid is the one that aligns best with the transaction’s requirements while offering competitive terms.
transaction submission: the relayer with the winning bid is granted the temporary monopoly to order and submit the specific transaction(s) alongside any bundle of transactions that they choose to include with it. they are responsible for ensuring that the transaction is submitted within the agreed-upon timeframe and parameters.
value distribution: the fee paid by the winning relayer is captured by the system. afterwards, it may be distributed among various stakeholders, which could include liquidity providers, validators, protocol governance, etc.
this happens in Connext, where a “sequencer” entity decides which “routers” can execute the swap. multiple routers send bids to the Connext sequencer, where routers are bidding to execute one specific transaction and charging the least amount of fee to the end user.
by allowing relayers to participate in an auction, the mechanism promotes fair competition where relayers have the opportunity to submit bids based on their capabilities and resources.
with that said, ROFA introduces a centralisation vector if the bidding process consistently favours a single entity that can extract the most REV.
if one relayer wins most of the bids, it could lead to a de facto monopoly over the submission of cross-chain transactions. This forms a positive feedback loop where other relayers are discouraged from participating in the auction because a dominant entity can always outbid them.
Leader Selection Mechanism: top-down selection of relayer
drawing inspiration from leader selection in blockchain networks, where validators are temporarily entrusted to generate new blocks, a similar concept can be applied to relayers.
there could be a relayer leader selection mechanism that decides which relayer can submit a batch of transactions. in this option, the selection mechanism will capture a predetermined portion of the REV with the relayer getting the remaining.
this approach allows the system to regulate the frequency and timing of relays, which is relevant in scenarios where timing is critical–such as capturing arbitrage. it also can more evenly distribute value capture among various relayers over time, preventing a single entity from continuously monopolising value extraction like in ROFA.
however, it’s important to implement this leader selection mechanism in a transparent manner. the selection process should involve fair criteria, such as a merit-based system that considers a relayer’s performance and reputation. the selection process needs to be accessible to all relayers so that the system can prevent centralisation.
Relayer-Searcher Separation (RSS): keeping relayers decentralised
this design optimises for keeping relayers decentralised and to not be subjected to the centralisation vectors of ROFA and relayer leader selection.
like PBS, we could call this RSS (Relayer-Searcher Separation) where relayers are chosen in a round-robin selection mechanism in a predetermined cadence (e.g., via Tendermint).
in parallel, bundles are being solicited from searchers who are compiling the best execution of relayer order flow in order to maximise value extraction–alongside their bids. relayers then would sign commitments with the highest paying searchers, confirming their agreement to include the specified bundles.
this offloads the searcher workload to other entities–allowing relayers to remain “dumb” and therefore decentralised. relayers will only focus on naively relaying messages, as directed by the top-paying searcher.
however, it’s important to note that relayer cannot guarantee inclusion on the destination for searchers–which we’ll go into more detail on how to address in the next section. this proposal only works if relayers can guarantee bundle inclusion in order to incentivise searcher participation.
Additional Considerations in Designing an REV System
this is a preliminary glimpse into (and also a gross oversimplification of) the world of REV. by discussing REV out in the open, we hope that additional open discussions are stimulated to not only increase our understanding of REV but also inspire deeper explorations into its mechanisms and the potential design of systems to harness its benefits and mitigate its drawbacks.
with that in mind, we turn our attention to additional considerations that warrant research to further our comprehension of REV:
Enforcement Mechanisms
a critical aspect of any REV framework is ensuring that winning relayers actually submit the relayed transactions. without proper enforcement, the temporary monopoly granted to relayers might not translate into actual message submission.
a robust relayer system should incentivise and enforce timely submission. cross-chain transactions are oftentimes time-sensitive, and thus demand quick relaying.
one option is to penalise relayers (via bonding and slashing, or proof-of-governance style removal from an allowlist) who fail to submit transactions. another option is to incentivise submission from relayers–such as a conditional payment mechanism in which relayers are only paid after a message is delivered within a specified time period.
catalyst is actively working on an incentive scheme that showcases the power of conditional payments, encouraging timely transaction submission while ensuring a fair compensation structure for relayers.
Guaranteed Transaction Inclusion
since oftentimes relayers are not the block proposer/validator of the destination chain, they don’t have guaranteed assurance that their bundle will be included into the destination chain block.
as such, there is no foolproof mechanism to ensure timely inclusion of cross-chain messages (and thus no guarantee that they will capture the MEV).
to make matters worse, validators can see relayer bundles in the mempool and frontrun them by including their own bundle with the relayed messages. as a result, they can steal REV at will.
some options to guarantee relayer bundle inclusion:
make validators responsible for relaying. in the relayer leader selection approach, relayers should only be validators/block proposers on the destination chain. a validator is selected to relay messages for its incoming slot. this is conceptually very similar to cross-chain MEV in an Interchain Scheduler.
separate relayers and validators. to prevent increasing validator overhead, we can also choose PBS-type mechanisms like mev-boost in which relayers can directly communicate with the destination chain validator/block proposer. in this model, relayers continue to act as searchers that submit bundles to block builders (or just straight to a validator/block proposer in a mev-geth type implementation). this way, validators remain “dumb” to the contents of a block and leave the block building to other entities.
force inclusion during consensus. using ABCI++ or creating a Protocol-Owned Builder module to enforce relayer bundle inclusion. in this case, a relayer “lane” is created within a block that guarantees messages will be included as they were ordered by the relayer. this only works in the context of Cosmos SDK chains.
with all that said, block space doesn’t appear to be competitive for most chains/domains outside of Ethereum and some select others, so it’s possible that relayers’ bundles will be naively included without these aforementioned mechanisms in place.
Permissioned vs. Permissionless Relayer Systems
in a permissioned setting, permissioned relayers hold much more power. they control the timing of delivering messages to the destination chain, which in turn determines when swaps and transactions execute. as a result, permissioned relayers gain the ability to front-run transactions and capture value through optimal timing and execution.
this closely resembles the role of solver networks, where solvers front liquidity on behalf of users. because solvers are fronting the liquidity and know precisely when the transaction will execute, they are in a better position to extract MEV.
due to the public nature of the origin blockchain, anyone with the necessary tools and knowledge can identify and act upon cross-chain MEV opportunities. in a permissionless setting, relayers need to heavily compete with one another to deliver a message as optimally as possible (e.g., fast, cheap, etc.), thus making the timing of the execution of a cross-chain message less predictable. as a result, relayers now operate without these exclusive privileges.
that being said, although certain relayer systems are designed to be permissionless, in practice there is a scarcity in active relayers.
this is even more pronounced particularly for specific routes — especially those involving less commonly used chains. as a result, permissionless systems may yield the same amount of relayers as permissioned ones.
Handling Non-REV Generating Transactions
balancing the treatment of REV-generating transactions with those that don’t generate any is essential for user fairness. defining requirements for relayers to include all transactions within a specified timeframe prevents non-REV generating users from being dismissed by relayers.
another way to combat this is through self-relaying. this concept is similar to the notion of forced inclusion for roll-ups onto settlement layers. incorporating no-code or easily accessible options for users to self-relay messages can ensure message inclusion and exemplify user sovereignty (e.g., a wallet plug-in for self relay).
Native Cross-Domain MEV Solutions
exploring solutions like SUAVE that address cross-domain intents presents opportunities for relayers to act as solvers. in this world, relayers can also play roles as block builders, proposers, or validators in both origin and destination chains that contribute to the seamless execution of cross-chain transactions.
Looking Forward
throughout this intro to REV, we dove into the supply chain of cross-chain transactions, relayers’ pivotal roles in it, and the extractable opportunities that emerge from their access to privileged information.
by shedding light on the mechanisms and potential solutions to REV, we hope to foster further discussions on this little-known topic. we want to collaborate with the broader crypto community to design systems that harness REV’s value generation while addressing and mitigating its harmful effects.
as the crypto space continues to expand with new chains and cross-chain transactions become more and more complicated, the importance of creating robust and thoughtful relayer systems becomes increasingly apparent.
balancing economic incentives, minimising malicious actions, and fostering a decentralised and resilient network of relayers are just some of the challenges we face going forward. let’s work together to refine our understanding of REV and to craft solutions that enhance the integrity and fairness in our cross-chain economies.
Acknowledgements
thank you to Vaibhav from Socket, the Skip team (Mag) and the IBC team (Susannah & Charly) for many conversations on this niche topic.
Resources
Order Flow Auction Design Space