RFP 18 - Demystification of Cross-Domain Signal MEV

Researcher: unassigned


Cross-domain MEV in general is under-researched. Cross-domain signaling MEV, in particular within cross-domain swaps, is even more poorly understood. Thus, the present research aims to qualify and quantify this form of cross-domain signaling MEV, using this information to contribute suggestions for how IBC-enabled protocols can enhance pre-execution privacy.

Background & Problem Statement


Core background concepts/definitions are as follows:

Cross-Domain MEV

Maximal Extractable Value (MEV) is a concept that has emerged within blockchain ecosystems, representing the maximum value that can be extracted from ordering, censoring and/or inserting transactions into a block. Initially identified in the context of Ethereum, MEV has broader implications across multiple domains. The advent of cross-domain MEV extends this concept across different blockchains, tapping into the potential for arbitrage, front-running, and other extractable value opportunities not just within a single blockchain, but across multiple blockchains simultaneously.

Cross-domain MEV arises in scenarios where transactions across different blockchains (domains) can be sequenced in a way that maximizes value extraction. This could involve, for example, exploiting price discrepancies for the same asset across decentralized exchanges on different domains, or coordinating complex transaction sequences that span multiple networks to achieve a particular financial strategy. The cross-domain aspect significantly expands the MEV landscape by introducing a multi-layered complexity and a broader set of opportunities for value extraction, necessitating advanced strategies and infrastructure for its realization.

Cross-Domain Signal MEV

Cross-domain Signal MEV is a specific type of MEV that can be extracted by leveraging information signals originating from other domains. For instance, when an asset undergoes a drastic price change in one domain, it potentially propagates to other domains, providing an opportunity to front-run the change by buying or selling the underlying asset in another domain. This strategy falls under the umbrella of cross-domain arbitrage.

Another form of cross-domain Signal MEV can originate from cross-domain swaps. For example, if a user sends a transaction to “bridge USDT from Ethereum to Osmosis and swap for OSMO tokens,” a sophisticated agent could sandwich the order using a multi-block MEV strategy: first buying OSMO tokens and then selling them after the user’s transaction is executed. While the first type of MEV strategies has been studied extensively, the latter lacks rigorous study.


The Inter-Blockchain Communication (IBC) Protocol represents a great opportunity for advancing cross-chain interoperability. Not only is the IBC protocol cost- and time-efficient compared to many other bridges, but also it is trustless. Most popular bridges like Wormhole are trusted, meaning users must put their faith into a third party to uphold the security of the bridge and facilitate asset transfers. In contrast, IBC is trustless, as it uses cryptographic techniques (instead of a trusted third party) to ensure bridge security and reliability. As a result, users only need to trust in publicly visible code when transferring over IBC.

Composable has developed infrastructure that connects the IBC to the Cosmos Hub, Cosmos SDK chains, Polkadot and Kusama parachains, Ethereum (in testnet) and Solana (soon), with additional chains being added in the future. This means that these ecosystems and the protocols residing there are able to seamlessly interoperate in a trust-minimized, non-custodial manner.

Problem Statement

The problem here is that cross-domain signal MEV (specifically originating from cross-domain swaps) is understudied. Therefore, this research aims to demystify cross-domain sandwich strategies across various bridges and Inter-Blockchain Communication (IBC) protocols, such as IBC.fun or centralized bridges such as Axelar.

Thus, the questions that this research aims to address are as follows:

  • Are sophisticated agents exploiting cross-domain sandwich strategies?
  • How prevalent are these strategies across different bridges and IBC protocols?
  • What are the expected returns, risks, and impacts on users?

Plan & Deliverables

Expected outputs/deliverables are as follows:

  • A formal description and analysis of cross-domain sandwich strategies
  • Suggestions for IBC-based protocols to improve pre-execution privacy

The plan for achieving this output is outlined below:

Experiment 1: Describe Existing Cross-Domain Sandwich Strategies

In experiment 1, we will formalize our strategy and methodology for the remaining experiments. Specifically, we will provide a comprehensive and formal description of cross-domain sandwich strategies, including expected returns and associated risks. Then, we will develop a rigorous methodology for identifying addresses that may be involved in these strategies.

Experiment 2: Develop Open-Source Tools and Create Dataset

In the second experiment, we will develop and release open-source code for identifying addresses involved in cross-domain sandwich strategies. If such strategies are actively being used, we will create a detailed dataset to demystify them by:

  • Clustering similar strategies together,
  • Computing profits and user losses, and
  • Assessing risks associated with these strategies.

Experiment 3: Simulation & Analysis

If no existing strategies are identified in experiment 2, we will hold experiment 3 to conduct simulations using “test” assets to evaluate how these strategies would function in practice. We will analyze the simulation results to explain the potential mechanics, profitability, and risks of cross-domain sandwich strategies. This experiment may not be necessary depending upon the extent of findings in experiment 2.

Experiment 4: Improve the IBC for Pre-Execution Privacy

In the final experiment, we will leverage the results from the prior experiments to propose enhancements to IBC protocols that would improve pre-execution privacy and minimize information leakage, reducing the potential for cross-domain sandwich MEV extraction.


How to Participate

If you’re a researcher who believes that you would be a good fit to contribute to any of the Composable RFPs, please reach out to Composable’s Lead Research Associate, Sydney Sweck, at sydney@composable.finance. In the email, be sure to include:

  • The RFP number(s) you’d like to contribute to
  • Your relevant background experience
  • How you think you could contribute to the research