> For the complete documentation index, see [llms.txt](https://newsandwich.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://newsandwich.gitbook.io/docs/new-sandwich-report/the-walls-have-ears-unveiling-cross-chain-sandwich-attacks-in-defi.md). # The Walls Have Ears: Unveiling Cross-Chain Sandwich Attacks in DeFi Chuanlei Li†, Zhicheng Sun†, Jing Xin Yuu†, Xuechao Wang† † The Hong Kong University of Science and Technology (Guangzhou) Email: {cli839,zsun277,jxyuu971}@connect.hkust-gz.edu.cn, ### Abstract Cross-chain interoperability is a core component of modern blockchain infrastructure, enabling seamless asset transfers and composable applications across multiple blockchain ecosystems. However, the transparency of cross-chain messages can inadvertently expose sensitive transaction information, creating opportunities for adversaries to exploit value through manipulation or front-running strategies. In this work, we investigate cross-chain sandwich attacks targeting liquidity pool-based cross-chain bridge protocols. We uncover a critical vulnerability where attackers can exploit events emitted on the source chain to learn transaction details on the destination chain before they appear in the destination chain mempool. This information advantage allows attackers to strategically place front-running and back-running transactions, ensuring that their front-running transactions always precede those of existing MEV bots monitoring the mempool of the destination chain. Moreover, current sandwich-attack defenses are ineffective against this new cross-chain variant. To quantify this threat, we conduct an empirical study using two months (August 10 to October 10, 2025) of cross-chain transaction data from the Symbiosis protocol and a tailored heuristic detection model. Our analysis identifies attacks that collectively garnered over 5.27 million USD in profit, equivalent to 1.28% of the total bridged volume. ## 1. Introduction Decentralized Finance (DeFi) has emerged as one of the most transformative innovations in the blockchain ecosystem, fundamentally reshaping financial intermediation. The DeFi market has experienced exponential growth, with the total value locked (TVL) across protocols exceeding 145 billion USD as of November 3, 2025 [\[1\]](#references). At the heart of this ecosystem are decentralized exchanges (DEXs), which enable users to trade digital assets directly on-chain without intermediaries. Unlike traditional order-book exchanges, DEXs rely on Automated Market-Making (AMM) mechanisms, where smart contracts autonomously determine exchange rates based on liquidity pool reserves [\[2\]](#references). Every trade, price update, and liquidity adjustment is immutably recorded on the blockchain, ensuring transparency, verifiability, and trustless execution for all participants. In traditional financial markets, access to transaction information has long been monetized. For example, institutional traders engage in high-frequency trading by minimizing latency to profit from microsecond-level price movements. A similar phenomenon has emerged in DeFi, where participants exploit informational advantages embedded in pending or on-chain transactions to extract profit, a practice broadly known as Maximum Extractable Value (MEV) [\[3\]](#references). Common MEV strategies include liquidation, arbitrage, and sandwich attacks: * In liquidation, an actor monitors DeFi lending protocols and profitably liquidates positions approaching their collateral thresholds [\[4\]](#references). * Arbitrage opportunities arise when price discrepancies exist across exchanges or liquidity pools, allowing traders to buy low and sell high and restoring price equilibrium. * In sandwich attacks [\[5\]](#references), an attacker observes a victim’s pending transaction in the mempool and strategically places one transaction before it (front-running) and another after it (back-running). By manipulating transaction ordering via gas fees, the attacker inflates the asset price before the victim’s swap and reverses the trade afterward, extracting a guaranteed profit at the victim’s expense. Several defense mechanisms have been proposed to mitigate sandwich attacks. Proposer-Builder Separation (PBS) mitigates the concentration of MEV by decoupling block construction from block proposal: competitive builders assemble candidate blocks, while validators merely propose them to the network [\[6\]](#references), [\[7\]](#references). Another line of defense involves encrypted mempools [\[8\]](#references), [\[9\]](#references), [\[10\]](#references), where transactions remain encrypted during block construction. Miners or validators build blocks using ciphertexts, and a designated committee later decrypts the included transactions once the block is finalized, thereby preventing pre-execution visibility and front-running. Furthermore, several works introduce fair transaction ordering at the consensus layer [\[11\]](#references), [\[12\]](#references), ensuring that users’ transactions are ordered according to predefined fairness principles rather than miners’ discretion. While front-running and sandwich attacks have been extensively examined in single-chain DEXs, the rise of cross-chain interoperability introduces a new dimension to these threats. As the DeFi ecosystem expands beyond individual blockchains, users increasingly engage in asset exchanges across multiple chains, relying on cross-chain bridges to facilitate these transfers [\[13\]](#references), [\[14\]](#references). Such systems enable interoperability by transmitting messages or tokens between heterogeneous blockchain networks, typically through trusted relayers or bridge operators responsible for observing and forwarding cross-chain events [\[15\]](#references). However, this process inherently exposes transaction metadata to the public: in EVM-based chains, relayers monitor events emitted by smart contracts, while in UTXO-based chains, they parse newly confirmed transaction outputs. Because these observations occur before the corresponding transactions appear in the destination chain’s mempool, adversaries monitoring the same on-chain events can gain early access to transaction details. This information advantage enables attackers to anticipate and exploit upcoming swaps on the destination chain, paving the way for cross-chain sandwich attacks that are invisible to existing MEV defenses. In this paper, we reveal how cross-chain sandwich attacks can be performed on liquidity pool-based bridge protocols. In these protocols, the source chain emits detailed cross-chain swap information, while the destination chain executes the corresponding token swap from a local liquidity pool and sends the output tokens to the user. An attacker continuously monitors specific events emitted by cross-chain protocols to learn about forthcoming cross-chain swap transactions on the destination chain. Once a profitable opportunity is detected, the attacker submits a front-running transaction to the corresponding liquidity pool on the destination chain and subsequently places a back-running transaction once the victim’s transaction appears on-chain or in the mempool, thereby completing the sandwich attack. Crucially, the attacker acquires the necessary information before the cross-chain transaction appears in any destination-chain context, giving them a temporal advantage over ordinary single-chain sandwich attackers. Moreover, this early access renders most previously proposed mitigations against single-chain sandwich attacks ineffective, as the attacker does not need to wait for the victim’s transaction to be visible in the destination chain’s mempool. We provide an example of a cross-chain sandwich attack identified on Ethereum Mainnet: * [0x9d5f...d548](https://etherscan.io/tx/0x9d5f874f8fde164a45cc758611424c6e91e60ed98f265f1a6ed1f11b5482d548) * [0xef06...2d7a](https://etherscan.io/tx/0xef068c4ae7e56a54a72432887dc9faa6ea2f7ce9606d8ddc758c975970692d7a) * [0xe16b...82c0](https://etherscan.io/tx/0xe16b2360053139b1d2991c26380529007ddd20ca6bb8d5ec59076bb4853282c0) * [0xc07d...2b8f](https://etherscan.io/tx/0xc07da1dea2dba2baf985e2f774342f3ebdec551d40905bf9400646e04f612b8f) * [0xe2a1...86de](https://etherscan.io/tx/0xe2a1c948e86bdc4785bf3fee56218a16d823ccbd56662c0d1d490249a94986de) In this example, the cross-chain attacker achieved a significantly higher profit rate of 21.4%, compared to just 0.8% for existing MEV bots. We begin by presenting a theoretical framework for analyzing cross-chain sandwich attacks. Since the attack dynamics depend on several stochastic parameters, we extract their empirical distributions from real-world data and verify that the observed values closely match our theoretical assumptions. Next, we examine historical cross-chain transaction data to identify concrete instances of such attacks. We collect two months of transaction records from the Symbiosis protocol [\[16\]](#references) from August 10 to October 10, 2025 and apply our heuristic detection algorithm to systematically locate cross-chain sandwich behaviors. Our analysis reveals that these attacks generated a total profit of approximately 5.27 million USD, representing 1.28% of the total bridged volume during the observation period. By contrast, conventional single-chain sandwich attacks in the same dataset yielded only 6,109 USD in profit. Furthermore, we found that cross-chain sandwich attacks have the greatest impact on the BSC network. Among the transactions in our dataset, those targeting BSC as the destination chain generated the highest profits, with the BUSD↔WBNB pool being the most frequently attacked. Finally, we discuss potential countermeasures and outline design principles aimed at mitigating this emerging class of cross-chain threats. ### Contributions * We identify a previously unrecognized cross-chain sandwich attack that exploits information advantage in cross-chain protocols. By accessing transaction details before they appear on the destination chain, the attacker can consistently outperform existing MEV bots in transaction-ordering competitions, effectively bypassing all known single-chain defenses. * We conduct a large-scale empirical study using two months of cross-chain transaction data, revealing that attackers extracted approximately 5.27 million USD in profit through such attacks, equivalent to 1.28% of the total bridged volume. * To foster further research, we construct and release the first large-scale [dataset](https://zenodo.org/records/17562882) of cross-chain sandwich attacks, providing an empirical foundation for future work on cross-chain MEV and security analysis. ## 2. Background In the following, we provide relevant background on DEXs, sandwich attacks, and cross-chain interoperability. ### 2.1. Decentralized Exchange Unlike centralized exchanges (CEXs), which require users to deposit funds and trust a centralized entity to manage order books and execute trades, decentralized exchanges (DEXs) allow users to trade cryptocurrencies directly from their personal wallets without the need for an intermediary. DEXs employ Automated Market Makers (AMMs) instead of traditional order books. In this model, liquidity providers (LPs) supply assets to liquidity pools that contain at least two tokens. The price of a token is then determined algorithmically based on the asset ratio in the pool, according to rules defined in an immutable and transparent smart contract. A classic AMM model is the Constant Product Market Maker (CPMM), used in Uniswap V2 [\[17\]](#references). It is also the model leveraged in Uniswap V3 when the price does not cross a tick, which is the case for almost all trades. For the reserves $x$ and $y$ in the liquidity pool, their quantities always satisfy: $$ x \times y = k $$ We consider that a user aims to swap $\Delta x$ of token X to token Y in a liquidity pool with transaction fee $f \in (0, 1)$. The reserves follow: $$ (x + (1 - f)\Delta x)(y - \Delta y) = x \times y $$ An increase in reserve $x$ leads to a decrease in $\Delta y$. This implies that large transactions can cause price deviations, a phenomenon known as slippage. A slippage tolerance $s \in (0, 1)$ represents the difference between the expected output $\Delta y$ and actual execution output $\Delta y'$, where: $$ \Delta y' \geq (1 - s)\Delta y $$ If the actual execution amount falls below the minimum acceptable value, the transaction is reverted. ### 2.2. Sandwich Attack Slippage tolerance creates an opportunity for predatory traders to perform strategies that extract value. The attack exploits the public nature of the mempool, which contains unconfirmed transactions broadcast to the network. Attackers monitor the mempool to identify profitable pending transactions targeting specific liquidity pools. They then bid higher gas fees to get miners to include a same-direction transaction before the victim’s transaction. The front-running transaction raises the token price, so the victim receives fewer tokens than expected. Next, the attacker submits an opposite-direction transaction with a slightly lower gas fee, ensuring it is placed immediately after the victim’s transaction. Finally, the attacker trades the overpriced token back and captures the profit. Consider a pool with reserves $(x\_0, y\_0)$ for tokens X and Y and a transaction fee rate $f \in (0, 1)$. At time $t\_0$, the attacker identifies a victim transaction $T\_v$. $T\_v$ aims to exchange $\Delta x\_v$ X for Y with slippage tolerance $s \in (0, 1)$. If the attacker executes a front-running transaction $T\_{A1}$ to input $\Delta x\_{A1}$ X in the pool, the pool reserves update. The victim transaction then executes. If its output satisfies: $$ \Delta y\_v \geq (1 - s)\Delta y $$ the execution succeeds; otherwise, it is reverted and the sandwich attack fails. According to the theorem proved by Heimbach et al. [\[18\]](#references), the attacker’s profit-maximizing optimal input amount $\Delta x\_{A1}$ is the value satisfying: $$ \Delta y\_v = (1 - s)\Delta y $$ To retrieve the profit, the attacker places the back-running transaction $T\_{A2}$ closely following $T\_v$. Let $G\_c$ be the total gas cost for $T\_{A1}$ and $T\_{A2}$. The profit $P$ of this sandwich attack is: $$ P = \Delta x\_{A2} - \Delta x\_{A1} - G\_c $$ ### 2.3. Cross-Chain Interoperability Cross-chain interoperability refers to the ability of distinct blockchain networks to reliably transfer or exchange data and assets, enabling seamless interaction among otherwise isolated systems. It has become a foundational component of modern multi-chain ecosystems, allowing users and applications to move liquidity, coordinate state, and compose protocols across heterogeneous chains. One early interoperability approach is the Lock-and-Mint model [\[19\]](#references): assets are locked on the source chain, and an equivalent amount of wrapped tokens is minted on the destination chain, ensuring the original assets cannot be double-spent. The reverse process, Burn-and-Unlock [\[20\]](#references), burns wrapped tokens on the destination chain and unlocks corresponding assets on the source chain, keeping the total supply consistent across chains. Another widely studied interoperability mechanism is the cross-chain atomic swap, which guarantees that a cross-chain token swap between two parties either executes fully on both chains or does not occur at all. Atomicity is enforced through Hashed Time-Locked Contracts (HTLCs) [\[21\]](#references), [\[22\]](#references), which coordinate conditional execution across chains with cryptographic timeouts. While these mechanisms support basic asset transfers, they fall short when applications require sending arbitrary data across chains. As cross-chain use cases expand, general-purpose cross-chain messaging protocols have become essential, offering greater flexibility and a significantly improved user experience. Such protocols allow applications to transmit structured messages rather than only wrapped tokens, enabling richer interactions across heterogeneous chains. Several notable designs exist: * Chainlink’s Cross-Chain Interoperability Protocol (CCIP) [\[23\]](#references) provides a generalized messaging framework built atop decentralized oracle networks and a risk-management layer. * Cosmos IBC [\[24\]](#references) uses on-chain light clients so that two blockchains can mutually verify each other’s state through Merkle commitments, avoiding trusted intermediaries altogether. We define a cross-chain messaging protocol as follows. **Definition 1 (Cross-Chain Messaging Protocol).** Source chain $S$, destination chain $D$, relayers $R$, users $U$, and contract $C$ engage in this protocol to transfer messages across different chains. The contracts $C$ are deployed on multiple chains. The cross-chain messaging protocol (CCMP) has the following sub-protocols: $$ CCMP = (COMMIT, MONITOR, CONSENSUS, EXECUTE) $$ * **COMMIT**$(S, C, U, R) \rightarrow m$: $U$ sends a request to contract $C$ on $S$, including the data they want to transfer. $C$ generates the message $m$ after encoding the data and emits $m$ to relayers $R$. * **VERIFY**$(m, R) \rightarrow (0, 1)$: This protocol is executed by every relayer in $R$. After receiving $m$, they verify its validity. If $m$ is valid, it outputs 1. * **CONSENSUS**$(m, R, D) \rightarrow l$: All relayers participate in the consensus to determine the validity of $m$. If the majority considers $m$ valid, a leader $l$ is selected to perform the EXECUTE protocol. * **EXECUTE**$(l, m, D, C, U) \rightarrow out$: The leader $l$ parses the message $m$ and gets the data from $U$. Then $l$ calls $C$ to sign the transaction corresponding to the data. At last, the user can verify the cross-chain message by checking the transaction execution result. To support decentralization, many cross-chain messaging protocols rely on events emitted by smart contracts to serve as message $m$, which permissionless relayers then observe and forward. Because these events are publicly visible and cross-chain execution introduces inherent delays, adversaries can access sensitive transaction information well before it is executed on the destination chain. This early visibility creates a predictable window for MEV extraction. Among all known MEV strategies, sandwich attacks are particularly harmful because they directly degrade user execution quality through price manipulation. As the pioneering work to study MEV in cross-chain settings, we focus specifically on cross-chain sandwich attacks, which arise in messaging protocols that integrate liquidity-pool swaps on the destination chain. In these systems, attackers can observe the emitted event on the source chain and predict the exact swap that will soon occur on the destination chain, well before the transaction reaches the local mempool. This advance knowledge allows attackers to reliably construct profitable sandwich transactions, a behavior that we have observed in the wild. ### Notation | Symbol | Description | | -------------------------------- | ---------------------------------------------------------------------------------------------- | | A | Attacker that performs cross-chain sandwich attack | | B | Attacker that performs single-chain sandwich attack | | $f$ | Swap fee rate of the pool which is in $(0, 1)$ | | $T\_s$ | Start transaction on the source chain | | $T\_v$ | Victim’s transaction on the destination chain | | $\pi$ | Representing symbols A1, A2, v, B1, B2 or numbers 1...n | | $s\_\pi$ | Slippage tolerance of $T\_\pi$ which is in $(0, 1)$ | | $N\_\pi$ | Block number of transaction $T\_\pi$ | | $T\_{A1}$ | Front-running transaction from A | | $T\_{A2}$ | Back-running transaction from A | | $T\_{B1}$ | Front-running transaction from B | | $T\_{B2}$ | Back-running transaction from B | | $(x\_0, y\_0)$ | Reserves of token X and Y before $T\_{A1}$ | | $(x\_\pi, y\_\pi)$ | Reserves of token X and Y after $T\_\pi$ | | $(\Delta x\_\pi, \Delta y\_\pi)$ | Amounts of token X and Y exchanged in $T\_\pi$ | | $p$ | Probability that A does not incur a loss after the execution of $T\_v$ with noisy transactions | | $q$ | Probability that there are no noisy transactions between $T\_{A1}$ and $T\_v$ | | $\theta$ | Percentage that A expects to extract from $T\_v$ | Prominent cross-chain messaging protocols with integrated liquidity-pool swaps include ThorSwap [\[25\]](#references), deBridge [\[26\]](#references), and Symbiosis [\[16\]](#references), which have processed total cross-chain volumes of 114.15 billion, 17.5 billion, and 6.4 billion USD respectively. Such scale underscores the importance of analyzing and mitigating these emerging cross-chain threats. ## 3. Cross-Chain Sandwich Attack In this section, we present a realistic model of cross-chain sandwich attacks. The model includes all possible transaction orderings, including cases of no attack, single-chain sandwich attacks only, and cross-chain sandwich attacks, both in isolation and when coexisting with a single-chain sandwich attack. The attacker A monitors events on the source chain in CCMP protocols. For each observed transaction, A locally executes the computations used in a single-chain sandwich attack. We assume that if transaction $T\_v$ is profitable, A will immediately place $T\_{A1}$ and then send $T\_{A2}$ right after $T\_v$. ### 3.1. Noisy Transactions Between the event being emitted on the source chain and the swap being executed on the destination chain, the message must be relayed by at least one intermediary. During this time interval, numerous swaps in unknown directions may occur in the corresponding liquidity pool. We call these swaps noisy transactions and denote $q$ as the probability that no noisy transactions exist between $T\_{A1}$ and $T\_v$. Noisy transactions may change the pool’s state to one that does not meet A’s expectations, thereby directly affecting the potential profit of its cross-chain sandwich attack on $T\_v$. As an extreme case, if a large-volume noisy transaction occurs in the direction opposite to $T\_{A1}$, then even if $T\_v$ executes successfully, A can only swap back fewer tokens than $\Delta x\_{A1}$, leading to a loss in its sandwich attack. As it is impossible to acquire or predict any information about noisy transactions at the time when the event is observed, we regard noisy transactions as a black-box transformation: $$ f : (x\_{A1}, y\_{A1}) \rightarrow (x\_n, y\_n) $$ The input and output represent pool states after $T\_{A1}$ and $T\_n$. If $T\_v$ exchanges X for Y, we denote $p$ as the probability that $(x\_n + \Delta x\_v, y\_n - \Delta y\_v)$ can ensure that A does not incur a loss: $$ \Delta x\_{A2} \geq \Delta x\_{A1} $$ when $T\_1...T\_n$ are not empty. As $p$ and $q$ are derived from this empirical black-box model, we estimate their values through large-scale historical data analysis rather than theoretical derivation. In practical settings, leaving a small buffer for $T\_v$ is a reasonable strategy for A to prevent noisy transactions from pushing $T\_v$ to its slippage limit and causing a transaction revert. Therefore, when $T\_v$ is about to be executed, exploitable opportunities may still exist, allowing single-chain attackers B to perform sandwich attacks on $T\_v$. We denote by $\theta \in (0, 1)$ the fraction extracted by A. This leaves a buffer of $(1 - \theta)s\_v\Delta y$ in token Y, and the victim will expect to receive $(1 - \theta)s\_v\Delta y$ more than the baseline amount $(1 - s\_v)\Delta y$. The condition is tightened to: $$ \Delta y\_v = (1-s\_v)\Delta y +(1-\theta)s\_v\Delta y = (1-s\_v \times \theta)\Delta y $$ ### 3.2. Profit of the Attack A direct implication of such attack under our assumptions is that the maximum profit in token X of A is $s\_v\Delta x\_v$. This value corresponds to the maximum tolerable loss of $T\_v$, and it is independent of other transactions occurring between $T\_{A1}$ and $T\_v$. This is because the minimum output amount of $T\_v$, `minReturnAmount`, is predefined in the emitted event, determined at the moment $T\_{A1}$ is placed. As long as $T\_v$ can be successfully executed, the corresponding token price in the pool at that time will not exceed the acceptable range of $T\_v$, thus the profit in token X of $T\_{A1}$ cannot exceed $s\_v\Delta x\_v$. Assuming $T\_v$ exchanges $\Delta x\_v$ X for Y, there are four possible scenarios for A. #### No single-chain sandwich attack If there is no single-chain sandwich attack, the execution ordering is: $$ (T\_{A1}, T\_1...T\_n, T\_v, T\_{A2}) $$ The maximum potential extracted value is $s\_v\Delta x\_v$. A successfully attacks if: $$ s\Delta x\_v > G\_c + (1 - (1 - f)^2)\Delta x\_{A1} $$ To show the expected profit, assume that when profit is positive, the average profit rate is $r^+$, and when profit is negative, the average profit rate is $r^-$. Considering parameters $p$ and $q$ in noisy transactions, the expected profit is: $$ E(P) = \Delta x\_{A1}((q +(1-q)p)r^+ +(1-q)(1-p)r^-) $$ #### $T\_{A2}$ executed before $T\_{B2}$ Although A is always able to place $T\_{A1}$ ahead of $T\_{B1}$, it cannot guarantee winning the race when inserting back-running transactions. If A wins this race, the transaction ordering is: $$ (T\_{A1}, T\_1...T\_n, T\_{B1}, T\_v, T\_{A2}) $$ $T\_{B1}$ can be treated as one of $T\_1...T\_n$, and the maximum potential extracted value and expected profit are the same as the situation with no single-chain sandwich attack. #### $T\_{A2}$ executed after $T\_{B2}$ If A loses the race, the transaction ordering is: $$ (T\_{A1}, T\_1...T\_n, T\_{B1}, T\_v, T\_{B2}, T\_{A2}) $$ Because B captures the buffer’s surplus, A’s maximum attainable profit is $r s\_v\Delta x\_v$, and the expectation is the same as the previous equation. #### $T\_{A1}$ is attacked by B If A is attacked by B, the transaction ordering is: $$ (T\_{B1}, T\_{A1}, T\_{B2}) $$ In each of the preceding scenarios, A’s profit decreases by at most $s\_A\Delta x\_{A1}$. However, A can mitigate this risk through methods such as decreasing $s\_A$ or leveraging a private mempool. Thus, this scenario is regarded as having no impact on A’s profit. ### 3.3. Against Current Countermeasures Existing defenses against sandwich attacks are designed for single-chain settings and therefore cannot address attacks that exploit information leakage across chains. In all cases, their protection applies only after a transaction reaches the destination chain, whereas cross-chain sandwich attacks arise before the transaction ever appears in the destination-chain mempool or block-construction pipeline. Proposer-Builder Separation (PBS) [\[6\]](#references) restricts the proposer’s ability to reorder transactions after seeing their plaintext contents. It ensures that once builders submit sealed blocks, the proposer cannot manipulate intra-block ordering for MEV extraction. Fair ordering consensus [\[27\]](#references), [\[28\]](#references), [\[11\]](#references) enforces partial transaction-ordering guarantees at the consensus layer by ensuring that transactions are ordered roughly in the sequence they are observed by the network. Both mechanisms regulate only transactions that are already visible to destination-chain nodes. Since a cross-chain victim transaction is predicted from source-chain events before it enters the destination chain’s network, these guarantees provide no protection. Similarly, private or encrypted mempools [\[29\]](#references), [\[8\]](#references), [\[9\]](#references) hide pending transactions after they reach the destination chain. However, in liquidity-pool-based cross-chain bridges, the essential details of the victim transaction are included in source-chain events that must be publicly emitted for relayers to function. Since the leak occurs before any mempool logic applies, hiding mempool contents does not stop the attack. ## 4. Empirical Analysis We investigate the scale of cross-chain sandwich attacks by analyzing historical transaction data from a cross-chain protocol to assess its feasibility and potential impact on the DeFi market. ### 4.1. Detection Algorithm Our cross-chain sandwich attack detection algorithm is inspired by the method for identifying potential single-chain sandwich attacks provided by Qin et al. [\[3\]](#references). We employ the following heuristics. * **Direction:** Both $T\_{A1}$ and $T\_v$ exchange token X for token Y, while $T\_{A2}$ exchanges token Y for token X. * **Pair:** Each $T\_{A1}$ can match only one $T\_{A2}$. * **Amounts:** For a perfect sandwich attack, the amount of bought token in $T\_{A1}$ should equal the amount of sold token in $T\_{A2}$. In practice, we relax this constraint by requiring the amount sold in $T\_{A2}$ to be between 90% and 110% of the amount bought in $T\_{A1}$. * **Position:** $T\_{A1}$ and $T\_v$ should be included in different blocks. $T\_{A2}$ has no such constraint. If $T\_{A1}$ and $T\_v$ are in the same block, we classify them as single-chain sandwich attacks. These heuristics are exactly the same as those proposed by Qin et al. [\[3\]](#references). * **Timestamp:** The timestamp of $T\_{A1}$ must fall between those of the start transaction on source chain $T\_s$ and end transaction on destination chain $T\_v$. The timestamp of $T\_{A2}$ should be controlled within a suitable range after $T\_v$. * **Address:** Either the same user address receives tokens in $T\_{A1}$ and $T\_{A2}$, or two different addresses send $T\_{A1}$ and $T\_{A2}$ to the same pool contract address. Among qualifying back-running transactions, the transaction with the same token receiving address as $T\_{A1}$ has higher priority to pair with $T\_{A1}$. ### 4.2. Detection Settings We select the Symbiosis protocol [\[16\]](#references) as an example. At the time of writing, it had processed over 4,578,130 cross-chain transactions, with a total cross-chain transaction volume reaching 6.44 billion USD [\[30\]](#references) since November 2022. In this protocol, when a user signs a cross-chain transaction, the bridge contract on the source chain emits an `OracleRequest` event that contains all calldata to be executed on the destination chain. An attacker can locally reconstruct the bridge contract’s function logic on the destination chain and iteratively parse that calldata to extract the information they need, including: * The targeted destination chain and liquidity pool. * The amount of token X to be swapped. * The minimum acceptable amount of token Y. With this information, the attacker can perform a cross-chain sandwich attack. The Symbiosis protocol relies on external DEX aggregators to compute the optimal swap path, so the calldata emitted in the event contains the aggregator’s swap execution logic. Taking 1inch [\[31\]](#references) as an example, Symbiosis ultimately calls the `swap` function in `AggregationRouterV5` to perform token exchanges in the corresponding pools. In practice, however, we found that the executor contract responsible for parsing calldata in swaps is not open source, so the exact calldata format is unknown. To address this, we use Tenderly [\[32\]](#references) to replay transactions corresponding to calldata on specific historical blocks and record swap details along the contract execution path. We collect two months of historical cross-chain transaction data from this protocol, from August 10 to October 10, 2025 . We first filter the dataset based on two criteria: * The swap on the destination chain must occur within a liquidity pool and must not involve stablecoin-to-stablecoin exchanges. * The interval between $T\_s$ and $T\_v$ must fall within a reasonable range. In practice, we observed cases where this interval exceeded 10 minutes. Such cross-chain transactions provide little analytical value for our study. The distribution of these intervals indicates that 95% are within 100 seconds. Therefore, we set 100 seconds as the maximum allowable interval. We then apply the detection heuristics described above to find instances of these attacks within the filtered transactions. ### 4.3. Empirical Results #### Transactions In total, we collect 60,130 cross-chain transactions from the protocol, of which 37,649 remain as valid transactions after applying the filtering criteria. By applying the detection algorithm to each transaction, we identify 316,809 potential cross-chain sandwich attack pairs. Among them, only 269 pairs occur within the same block, representing single-chain sandwich attacks. They account for merely 0.085% of the total. The BUSD↔WBNB pools are the most frequently targeted, accounting for 57.65% of all identified attacks. We provide a case in which both single-chain and cross-chain sandwich attacks coexist on Ethereum Mainnet. The following transactions correspond to components $(T\_s, T\_{A1}, T\_{B1}, T\_v, T\_{B2}, T\_{A2})$: * [0x0aaf...b44f](https://basescan.org/tx/0x0aaf8f5aac0b43bfcba7e7f227028c6b3d52ade3fba6ab056ecb43ef0919b44f) * [0x9d5f...d548](https://etherscan.io/tx/0x9d5f874f8fde164a45cc758611424c6e91e60ed98f265f1a6ed1f11b5482d548) * [0xef06...2d7a](https://etherscan.io/tx/0xef068c4ae7e56a54a72432887dc9faa6ea2f7ce9606d8ddc758c975970692d7a) * [0xe16b...82c0](https://etherscan.io/tx/0xe16b2360053139b1d2991c26380529007ddd20ca6bb8d5ec59076bb4853282c0) * [0xc07d...2b8f](https://etherscan.io/tx/0xc07da1dea2dba2baf985e2f774342f3ebdec551d40905bf9400646e04f612b8f) * [0xe2a1...86de](https://etherscan.io/tx/0xe2a1c948e86bdc4785bf3fee56218a16d823ccbd56662c0d1d490249a94986de) $T\_v$ attempted to swap WETH for MXY. A placed $T\_{A1}$ at block 23286093, then $T\_v$ was successfully executed at block 23286100. Concurrently, $T\_v$ was also targeted by B, labeled as a MEV bot in this case. Existing MEV monitoring platforms, such as [EigenPhi](https://eigenphi.io/mev/ethereum/tx/), only detect $T\_{B1}$ and $T\_{B2}$ for $T\_v$. Subsequently, A placed $T\_{A2}$ at block 23286105 to extract value. Excluding gas costs, A gained an additional 0.034 WETH and achieved a 21.4% profit rate: $$ \frac{\Delta x\_{A2} - \Delta x\_{A1}}{\Delta x\_{A1}} $$ The profit rate of B was only 0.8%. #### Extracted Profit Profit is calculated based on token prices in USD as of October 31, 2025 [\[33\]](#references), without considering gas costs. Overall, the total profit calculated from the dataset is 5,273,857 USD out of a total trading volume of 412,632,065 USD. The largest profit from a single sandwich attack is 20,284 USD. Additionally, there remains 1,425,500 USD worth of unexploited potential profit. The profit rate appears roughly symmetric around zero, while absolute profit is predominantly positive, indicating that large-volume opportunities overwhelmingly produce positive returns. The top 10 blockchain pairs by profit are as follows: | Source chain | Destination chain | Profit (USD) | Transactions value (USD) | Percentage | | ------------ | ----------------- | -----------: | -----------------------: | ---------: | | Ethereum | BSC | 2,096,164 | 247,920,634 | 0.85% | | Base | BSC | 1,447,602 | 90,356,394 | 1.6% | | Arbitrum | BSC | 337,532 | 34,062,217 | 0.99% | | Avalanche | BSC | 100,162 | 6,528,034 | 1.53% | | Ethereum | Base | 66,914 | 5,845,820 | 1.14% | | Optimism | BSC | 51,558 | 2,443,226 | 2.11% | | Avalanche | Base | 32,647 | 1,469,088 | 2.22% | | Gnosis | BSC | 14,559 | 495,505 | 2.94% | | Ethereum | Arbitrum | 10,225 | 497,432 | 2.06% | | Polygon | Base | 8,964 | 434,752 | 2.06% | Among these, Ethereum→BSC yields the highest attacker profit, with 2,096,164 USD extracted. BUSD↔WBNB is the most sandwich attack-prone token pair on the destination chain, with a profit of 3,170,661 USD. Its pools are also the most frequently attacked, with a total of 182,620 sandwich transaction pairs. The profit accounts for 60.1% of the total attacked volume. One possible reason for this high concentration is that this token pair has a large cross-chain trading volume, reaching 330,121,414 USD. In the dataset, single-chain sandwich attacks produced only 6,109 USD in profit, approximately 0.116% of total profits. Together with the single-chain sandwich transaction counts reported above, this suggests that when cross-chain sandwich attacks are already in play, little to no exploitable volume remains when the victim transaction appears in the mempool. #### Pools Sorted by Number of Attacks | Address | Tokens | Chain | Protocol | Number of attacks | | ------------------------------------------ | ------------ | --------- | -------------- | ----------------: | | 0x172fcd41e0913e95784454622d1c3724f546f849 | BUSD-WBNB | BSC | PancakeSwap V3 | 118731 | | 0x47a90a2d92a8367a91efa1906bfc8c1e05bf10c4 | BUSD-WBNB | BSC | Uniswap V3 | 63889 | | 0xf2688fb5b81049dfb7703ada5e770543770612c4 | USDC-WBNB | BSC | PancakeSwap V3 | 63049 | | 0x62fcb3c1794fb95bd8b1a97f6ad5d8a7e4943a1e | ETH-WBNB | BSC | PancakeSwap V3 | 7458 | | 0x72ab388e2e2f6facef59e3c3fa2c4e29011c2d38 | WETH-USDC | Base | PancakeSwap V3 | 6344 | | 0x9f599f3d64a9d99ea21e68127bb6ce99f893da61 | ETH-BUSD | BSC | PancakeSwap V3 | 4509 | | 0xe0554a476a092703abdb3ef35c80e0d76d32939f | USDC-WETH | Ethereum | Uniswap V3 | 3224 | | 0x62cf00528cb7af872c1f9dd426e655c903f16770 | ETH-USDC | BSC | PancakeSwap V3 | 2822 | | 0x6f38e884725a116c9c7fbf208e79fe8828a2595f | WETH-USDC | Arbitrum | Uniswap V3 | 2439 | | 0x7e58f160b5b77b8b24cd9900c09a3e730215ac47 | ASTER-BUSD | BSC | PancakeSwap V3 | 2352 | | 0xa20c959b19f114e9c2d81547734cdc1110bd773d | WAVAX-USDC | Avalanche | Aerodrome | 2346 | | 0xe30d5bf485f7476ac15884a28ffb3c9cea635dcb | AVNT-USDC | Base | Aerodrome | 2303 | | 0xdbc6998296caa1652a810dc8d3baf4a8294330f1 | WETH-USDC | Base | Aerodrome | 1865 | | 0xb4cb800910b228ed3d0834cf79d697127bbb00e5 | WETH-USDC | Base | Uniswap V3 | 1443 | | 0x247f51881d1e3ae0f759afb801413a6c948ef442 | BUSD-BTCB | BSC | PancakeSwap V3 | 1364 | | 0x62edaf2a56c9fb55be5f9b1399ac067f6a37013b | BTCB-WBNB | BSC | PancakeSwap V3 | 1271 | | 0x8bfb0fb037b30562fdb7be3f71440575664ab74e | ASTER-BUSD | BSC | Uniswap V3 | 1264 | | 0x2325e3f261cadb1c30cebf66c9f95f6fb016c0d4 | WETH-PUPPIES | Ethereum | Uniswap V2 | 1197 | | 0x50203df8efcddba9755c886f086b9b2d537a15f9 | XPL-BUSD | BSC | PancakeSwap V3 | 1107 | | 0x36696169c63e42cd08ce11f5deebbcebae652050 | BUSD-WBNB | BSC | PancakeSwap V3 | 1088 | | 0x90166b5795250fe7f0831e844121cc91799787e9 | USDC-STBL | BSC | PancakeSwap V3 | 1077 | | 0x70f536b375296b60078a6e1bb0790919a13efe77 | USDC-LINEA | LINEA | NA | 1066 | | 0x16b9a82891338f9ba80e2d6970fdda79d1eb0dae | BUSD-WBNB | BSC | PancakeSwap V2 | 1015 | | 0xfae3f424a0a47706811521e3ee268f00cfb5c45e | WAVAX-USDC | Avalanche | Uniswap V3 | 929 | | 0xc7bbec68d12a0d1830360f8ec58fa599ba1b0e9b | WETH-USDT | Ethereum | Uniswap V3 | 877 | | 0xe1799b52c010ad415325d19af139e20b8aa8aab0 | BTCB-USDC | BSC | PancakeSwap V3 | 848 | | 0x6ec31af1bb9a72aacec12e4ded508861b05f4503 | WBNB-MYX | BSC | PancakeSwap V3 | 767 | | 0x4141325bac36affe9db165e854982230a14e6d48 | USDC-WBNB | BSC | Uniswap V3 | 737 | | 0x1b54cd932b6b751803c996cbef36280b53795f81 | BUSD-HEMI | BSC | PancakeSwap V3 | 716 | | 0xb1026b8e7276e7ac75410f1fcbbe21796e8f7526 | WETH-USDC | Arbitrum | Algebra | 612 | | 0x7fcdc35463e3770c2fb992716cd070b63540b947 | WETH-USDC | Arbitrum | PancakeSwap V3 | 570 | | 0x85faac652b707fdf6907ef726751087f9e0b6687 | WBNB-BUSD | BSC | PancakeSwap V3 | 561 | | 0x882df4b0fb50a229c3b4124eb18c759911485bfb | DAI-LGNS | Polygon | Uniswap V2 | 517 | #### Sandwich Transaction Positions Unlike single-chain sandwich attacks that seek to place transactions immediately adjacent to the victim transaction, cross-chain sandwich attacks prioritize maximizing use of early-obtained information while avoiding direct competition with existing MEV bots. We analyze relative block positions of transactions in each cross-chain sandwich pair, specifically the position of $N\_{A1}$ relative to $N\_s$ and $N\_v$, and the position of $N\_{A2}$ relative to $N\_v$ and $N\_v + num$. In the experiments, we set $num = 100$. Empirically, A tends to sign $T\_{A1}$ immediately upon observing a profitable event and to submit $T\_{A2}$ immediately after $T\_v$ is executed in order to realize profit. This behavior aligns with the assumption described earlier. The distribution of relative positions for all sandwich attacks closely resembles that of profitable sandwich attacks, indicating that attackers follow similar strategies. However, their specific profits are influenced by the impact of intermediate noisy transactions. #### Sandwich Transaction Gas Price For each sandwiching transaction pair, we examine the relationship between the gas price of $T\_{A1}$ and that of $T\_v$, as well as between the gas price of $T\_{A2}$ and $T\_v$. For $T\_{A1}$, in 99.56% of cross-chain transaction pairs, the ratio is less than 1, meaning that almost all gas prices of $T\_{A1}$ are lower than those of $T\_v$. This is intuitive, as the attacker does not need to participate in a gas bidding competition to obtain the right to place the front-running transaction. The difference between $T\_v$ and $T\_{A2}$ exhibits a certain degree of randomness. We infer that this is because there are other transactions in the same direction following $T\_v$ in some cases, meaning that A does not exclusively attack $T\_v$. As a result, the corresponding gas prices deviate from the expected pattern. In addition, we found that 31,311 front-running transactions had a gas price of 0. This indicates that some attackers submit front-running transactions to private miners to avoid attack from single-chain sandwich attackers. In contrast, we did not observe any victim transactions with a gas price of 0, since victim swaps are automatically initiated by smart contracts and the protocol does not provide a mechanism to submit these transactions to private pools. | $\delta = GasPrice\_{T\_v} - GasPrice\_{T\_{A2}}$ | Number | Percentage | | ------------------------------------------------- | -----: | ---------: | | $\delta < 0$ GWei | 175496 | 55.39% | | $0$ GWei $\leq \delta < 1$ GWei | 140015 | 44.2% | | $1$ GWei $\leq \delta < 10$ GWei | 1271 | 0.4% | | $10$ GWei $\leq \delta$ | 27 | 0.009% | | Total | 316809 | 100% | #### Empirical Parameters The 37,649 valid cross-chain transactions were executed through a total of 73,391 liquidity pools, as a swap may traverse multiple pools. For each pool, we extract $T\_1...T\_n$ occurring between timestamps of $T\_s$ and $T\_v$ and examine their impact on the pool state. The results show: * In 41,811 pools, no transactions occurred between these timestamps, yielding $q = 0.57$. * Among the remaining 31,580 pools where $T\_1...T\_n$ existed, 21,579 pools exhibit final states in which $T\_{A1}$ did not incur a loss after execution of $T\_v$, yielding $p = 0.68$. Overall, noisy transactions $T\_1...T\_n$ and $T\_v$ ultimately give $T\_{A1}$: $$ q + (1 - q)p = 86.2% $$ chance of remaining profitable. This suggests that $T\_1...T\_n$ tend to follow the same directional trend as $T\_v$ in such cross-chain scenarios. We computed positive and negative return rates, $r^+$ and $r^-$, for all detected cross-chain sandwich attacks. We observed extreme cases in which $r^+$ approached or exceeded 1 and $r^-$ approached -1. For example, the following cross-chain attack transaction pairs had profit rates of 0.96 and -0.82 respectively: * [0xaf59...9607](https://arbiscan.io/tx/0xaf599b7440a0991b3743e0ba4840f9442f6b66e92c7f38e0289a8e0a999e9607), [0x7872...6598](https://arbiscan.io/tx/0x7872f01e3905805bfbe73dd1182432b6a730f4afcdc919d62d41422cee216598), [0xe143...c752](https://arbiscan.io/tx/0xe1431d7152461e249ee2e91861ddae0538af242894a8fef516a9becc2adcc752) * [0x6590...12c1](https://arbiscan.io/tx/0x659098be3fc46e0af7f92900f4771a5248ff2e78062eb68a2fd4bf355eeb12c1), [0x57d7...31b2](https://arbiscan.io/tx/0x57d7d7b89c0755150c1102dc5cd099f0bbae9c1c7a24a2f811f38250bc4631b2), [0xbbf8...156a](https://arbiscan.io/tx/0xbbf8f046ba5b76db053e01a538e16027bc03eb18add3672b7edf8da51115156a) Both involved UXLINK↔USDC swaps that coincided with a black swan event on September 23, 2025: [https://dex.coinmarketcap.com/token/arbitrum/](https://dex.coinmarketcap.com/token/arbitrum/0x1a6b3a62391eccaaa992ade44cd4afe6bec8cff1/) [0x1a6b3a62391eccaaa992ade44cd4afe6bec8cff1/](https://dex.coinmarketcap.com/token/arbitrum/0x1a6b3a62391eccaaa992ade44cd4afe6bec8cff1/) After excluding these outliers and using 95th-percentile statistics from the remaining data, we obtain: $$ r^+ = 0.045 $$ $$ r^- = -0.047 $$ The attacker’s expected profit rate is: $$ E(r) = (q + (1 - q)p)r^+ + (1 - q)(1 - p)r^- = 3.23% $$ #### Limitations Currently, we have only collected cross-chain transaction data between EVM-based chains and parsed them with events and functions shown in the appendix. However, the Symbiosis protocol also includes destination chains of the UTXO type, such as Bitcoin. Since these chains lack smart contract support, we are currently unable to access the exact data format used by the protocol in such cases and therefore cannot parse the corresponding transactions. As a result, potential profits from these cross-chain interactions remain unknown, and the real profit is larger than calculated. In addition to Symbiosis, other cross-chain protocols, such as Thorswap [\[25\]](#references), also meet the prerequisites for cross-chain sandwich attacks. Thorswap reached a peak monthly swap volume of 11.18 billion USD [\[34\]](#references). It maintains its own liquidity pools and executes swaps via its relay chain. However, it does not provide an interface to query pool swap information on the relay chain, preventing analysis of its historical data. By examining more protocols of this type in the future, we will be able to obtain a more accurate assessment of cross-chain sandwich attack potential. ### 4.4. Discussion of Future Strategy The foregoing analysis is based on historical data. However, from the attacker’s perspective there are multiple viable strategies in the cross-chain setting. The first strategy corresponds to the one described previously: upon observing a profitable cross-chain event, the attacker immediately submits a front-running transaction. After the victim transaction is executed on the destination chain, it immediately submits the back-running transaction and has no other intermediate actions. This strategy is based on the attacker’s belief in the empirical value of probability $q$. A second class of strategies involves dynamic decision-making: the attacker adaptively adjusts behavior in response to noisy transactions. For example: * If reverse-direction transaction volume exceeds the attacker’s tolerance, the attacker may cut losses early. * When same-direction noisy transactions appear, some attackers may adopt a greedy policy by submitting a small back-running transaction to capture a portion of the profit. * In extreme cases, a large same-direction transaction pushes victim transaction execution beyond its slippage tolerance and causes a transaction revert. The attacker may place the back-running transaction immediately after that large transaction to realize even greater profit. However, because the Symbiosis protocol does not expose information about reverted cross-chain transactions, we can only discuss this possibility qualitatively and cannot identify empirical instances to validate these strategies. Some cross-chain protocols do not publish their event data formats, meaning that corresponding smart contract code is not open source. In such cases, an attacker must locally simulate calldata execution on the most recent block to infer the destination-chain swap path and then place $T\_{A1}$ in the relevant pool. This approach introduces uncertainty because the actual execution time of $T\_v$ is unknown. If execution is delayed, blockchain state may change and the calldata’s execution result may differ. That can cause the attacker to misjudge details of $T\_v$ and increase the risk of loss. ## 5. Mitigation The information necessary for cross-chain sandwich attacks is obtained on the source chain. Consequently, future changes to mempool opacity [\[35\]](#references), [\[8\]](#references), [\[9\]](#references) or transaction-ordering mechanisms [\[27\]](#references), [\[28\]](#references) on the destination chain would not prevent this attack. To eliminate cross-chain sandwich attacks in such protocols, one must either prevent information emitted on the source chain from being publicly exposed or ensure that any publicly available information is useless to an attacker. This argument relies on the assumption that the protocol itself is honest and reliable. If protocol designers or operators are malicious, the attack cannot be stopped. In the worst case, a malicious designer can read cross-chain information directly from the frontend or other privileged channels and execute these sandwich attacks. They observe information strictly earlier than any external attacker. Under the honest-protocol assumption, we present several potential countermeasures. ### Private Relayers A cross-chain protocol could choose not to publish events on-chain and instead send corresponding cross-chain information privately to its own relay nodes or a set of trusted relays. While this design can completely prevent cross-chain sandwich attacks, it also means the protocol must give up the market of decentralized relay networks and take on the cost of maintaining its own relay network. Moreover, this increases the level of centralization in the protocol and reduces users’ trust in it. ### Encrypted Message A protocol can encrypt cross-chain swap information on the source chain and reveal plaintext on the destination chain only after the relayer forwards the encrypted message. However, decrypting data directly in the bridge contract is impractical: * All key variables and decryption logic within a smart contract are publicly visible. * Employing cryptographic techniques such as DKG [\[36\]](#references) to achieve decentralized key management would incur extremely high gas costs and introduce significant time delays. Therefore, some entity must have access to the plaintext of the event in order to execute it. The protocol can introduce a trusted off-chain decryption committee. After receiving the encrypted event from the relayer, the committee selects a member to decrypt the event and execute the calldata logic on the destination chain. In this design, even if a relayer or attacker observes the event emitted on the source chain, they cannot extract useful information and therefore cannot perform a cross-chain sandwich attack. ### Use Real-Time Swap Calldata The root cause of cross-chain sandwich attacks is that cross-chain protocols compute exact swap calldata on the source chain through DEX aggregators such as 1inch [\[31\]](#references) and OpenOcean [\[37\]](#references), allowing the frontend to show the user a precise expected output. This calldata contains chosen pools and execution paths, is sent to the destination chain, and becomes observable to relayers or attackers. A simple and effective fix is to move swap calldata generation to the destination chain. On the source chain, the relayer should receive only the minimal necessary information, such as that the user wants to swap token X for token Y, without including pool, path, or routing details. Because aggregators’ optimal paths change over time, an attacker who sees only this rough intent cannot predict exact future calldata or the chosen route. Guessing a specific pool and submitting a front-running transaction carries risk, so a rational attacker would not attempt such an attack. ## 6. Related Works ### Maximum Extractable Value Eskandir et al. [\[38\]](#references) were the first to introduce the concept of front-running from traditional financial markets into DeFi. Subsequently, Flash Boys 2.0 [\[5\]](#references) studied priority gas auctions, where the winner gains priority in transaction ordering. This work introduced the concept of MEV and empirically demonstrated that MEV poses a significant threat to Ethereum. Torres et al. [\[39\]](#references) and Qin et al. [\[3\]](#references) conducted systematic analyses based on historical Ethereum transaction data and showed that many miners have already been extracting MEV through gas bidding. Qin et al. [\[3\]](#references) evaluated profits miners obtained from arbitrage, liquidation, and sandwich attacks. Zhou [\[40\]](#references) formally defined the sandwich attack problem in AMM exchanges and analyzed it theoretically and empirically from the attacker’s perspective, identifying conditions under which such attacks can yield profit. To detect MEV behaviors, some works explore learning-based detection of malicious transactions and MEV bots at scale [\[41\]](#references), [\[42\]](#references), [\[43\]](#references). Li et al. [\[44\]](#references) conducted a comprehensive study of Flashbots bundles and discovered 17 previously unknown DeFi MEV strategies by leveraging their detection tool. There are several effective countermeasures against sandwich attacks. The Proposer-Builder Separation mechanism [\[6\]](#references) in Ethereum splits block production into two roles. Builders construct blocks and include transactions, while proposers only select which block to propose. This separation improves fairness in transaction ordering. Aequitas, provided by Kelkar et al. [\[27\]](#references), is a protocol designed to achieve order fairness at the consensus layer, later extended to a permissionless setting [\[28\]](#references). Furthermore, some works leverage encrypted mempools [\[8\]](#references), [\[9\]](#references), [\[10\]](#references) to hide transaction content until ordering is finalized. All existing mitigations aim to ensure fair transaction ordering within the block containing the victim transaction. However, cross-chain sandwich attacks do not rely on transaction ordering within that block; they place the front-running transaction in the block preceding the target block. Therefore, all the aforementioned methods are ineffective against this type of attack. ### Cross-Domain MEV Cross-domain MEV arises when extractable value spans different domains, such as Layer 1 to Layer 2 or cross-chain environments. Its essence lies in exploiting manipulation opportunities caused by network communication delays, state differences, or information asymmetry between different domains. Cross-chain arbitrage is a common form of cross-domain MEV. Arbitrageurs observe price differences of the same token across different chains and execute rapid buy and sell trades to capture profits. Oz et al. [\[45\]](#references) analyzed one year of data across nine blockchains and identified 868.64 million USD worth of cross-chain arbitrage transactions. Additionally, they observed a centralization trend in cross-chain arbitrage, with five addresses generating more than half of these transactions. Gogol et al. [\[46\]](#references) investigated non-atomic arbitrage in cross-rollup scenarios, where arbitrage is not executed within a single atomic transaction and delays between buy and sell operations introduce risk. They found that price differences on rollups often last for 10–20 blocks and discovered over 0.5 million unexploited arbitrage opportunities on these rollups. In the rollup setting, Ferreira et al. [\[47\]](#references) exploited centralized sequencing mechanisms of rollups to manipulate transaction ordering and mount cross-layer sandwich attacks. Their analysis estimates that attackers could have earned roughly 2 million USD through such sequencer-level manipulation. However, this line of work is fundamentally different from ours. Cross-layer attacks rely on privileged control or structural properties of a specific rollup’s sequencer, whereas we uncover an attack vector arising purely from cross-chain message flow. Prior studies do not examine the possibility that cross-chain infrastructure itself can leak actionable transaction information and enable sandwich attacks across chains. To the best of our knowledge, this work is the first to identify, formalize, and empirically analyze cross-chain sandwich attacks, supported by real-world historical data. ## 7. Conclusion and Future Works In this paper, we identify a previously unrecognized cross-chain sandwich attack in which an attacker exploits information leaked by cross-chain protocols to execute profitable front-running and back-running transactions. In this setting, existing defenses against sandwich attacks fail, allowing attackers to consistently outperform current MEV bots. We provide a theoretical analysis of the cross-chain sandwich attack and conduct an empirical study on historical data from a major cross-chain protocol. Our results show that this class of attacks produced at least 5.27 million USD in profit over a two-month period. To the best of our knowledge, we are the first to construct and publicly release a large-scale dataset of cross-chain sandwich attacks, providing a foundation for future research on cross-chain security. This work highlights a critical security risk introduced by cross-chain interoperability and aims to inspire more robust DeFi defense mechanisms. ### Future Works We plan to extend this line of reasoning to examine whether other MEV activities, such as arbitrage or liquidation, can gain additional advantage in cross-chain settings. We also intend to investigate the existence and prevalence of these strategies using historical data. More interestingly, cross-chain environments may enable entirely new forms of MEV that do not arise in single-chain settings. ## 8. Acknowledgment This work is supported by the Guangzhou-HKUST(GZ) Joint Funding Program (No. 2024A03J0630 and No. 2025A03J3882), the Guangzhou Municipal Science and Technology Project (No. 2025A04J4168), and the Guangdong Provincial Key Lab of Integrated Communication, Sensing and Computation for Ubiquitous Internet of Things (No.2023B1212010007). ## References 1. “Defi llama,” , 2025. 2. L. Zhou, X. Xiong, J. Ernstberger, S. Chaliasos, Z. Wang, Y. Wang, K. Qin, R. Wattenhofer, D. Song, and A. Gervais, “Sok: Decentralized finance (defi) attacks,” in *2023 IEEE Symposium on Security and Privacy (SP)*. IEEE, 2023, pp. 2444–2461. 3. K. Qin, L. Zhou, and A. Gervais, “Quantifying blockchain extractable value: How dark is the forest?” in *2022 IEEE Symposium on Security and Privacy (SP)*. IEEE, 2022, pp. 198–214. 4. K. Qin, L. Zhou, P. Gamito, P. Jovanovic, and A. Gervais, “An empirical study of defi liquidations: Incentives, risks, and instabilities,” in *Proceedings of the 21st ACM internet measurement conference*, 2021, pp. 336–350. 5. P. Daian, S. Goldfeder, T. Kell, Y. Li, X. Zhao, I. Bentov, L. Breidenbach, and A. Juels, “Flash boys 2.0: Frontrunning in decentralized exchanges, miner extractable value, and consensus instability,” in *2020 IEEE symposium on security and privacy (SP)*. IEEE, 2020, pp. 910–927. 6. S. Yang, K. Nayak, and F. Zhang, “Decentralization of ethereum’s builder market,” in *2025 IEEE Symposium on Security and Privacy (SP)*. IEEE, 2025, pp. 1512–1530. 7. S. Wang, Y. Huang, W. Zhang, Y. Huang, X. Wang, and J. Tang, “Private order flows and builder bidding dynamics: The road to monopoly in ethereum’s block building market,” in *Proceedings of the ACM on Web Conference 2025*, 2025, pp. 2144–2157. 8. A. R. Choudhuri, S. Garg, J. Piet, and G.-V. Policharla, “Mempool privacy via batched threshold encryption: Attacks and defenses,” in *33rd USENIX Security Symposium (USENIX Security 24)*, 2024, pp. 3513–3529. 9. A. R. Choudhuri, S. Garg, G. V. Policharla, and M. Wang, “Practical mempool privacy via one-time setup batched threshold encryption,” in *34th USENIX Security Symposium (USENIX Security 25)*, 2025, pp. 3477–3495. 10. J. Bormet, S. Faust, H. Othman, and Z. Qu, “{BEAT-MEV}: Epoch-less approach to batched threshold encryption for {MEV} prevention,” in *34th USENIX Security Symposium (USENIX Security 25)*, 2025, pp. 3457–3476. 11. M. Kelkar, S. Deb, S. Long, A. Juels, and S. Kannan, “Themis: Fast, strong order-fairness in byzantine consensus,” in *Proceedings of the 2023 acm sigsac conference on computer and communications security*, 2023, pp. 475–489. 12. Z. Li and E. Pournaras, “Sok: Consensus for fair message ordering,” *arXiv preprint arXiv:2411.09981*, 2024. 13. P. Sheng, X. Wang, S. Kannan, K. Nayak, and P. Viswanath, “Trust-boost: Boosting trust among interoperable blockchains,” in *Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security*, 2023, pp. 1571–1584. 14. A. Augusto, R. Belchior, M. Correia, A. Vasconcelos, L. Zhang, and T. Hardjono, “Sok: Security and privacy of blockchain interoperability,” in *2024 IEEE Symposium on Security and Privacy (SP)*. IEEE, 2024, pp. 3840–3865. 15. Y. Guo, M. Xu, X. Cheng, D. Yu, W. Qiu, G. Qu, W. Wang, and M. Song, “{zkCross}: A novel architecture for {Cross-Chain}{Privacy-Preserving} auditing,” in *33rd USENIX Security Symposium (USENIX Security 24)*, 2024, pp. 6219–6235. 16. “Symbiosis documentation,” , 2025. 17. “Uniswap,” , 2025. 18. L. Heimbach and R. Wattenhofer, “Eliminating sandwich attacks with the help of game theory,” in *Proceedings of the 2022 ACM on Asia Conference on Computer and Communications Security*, 2022, pp. 153–167. 19. E. Tairi, P. Moreno-Sanchez, and C. Schneidewind, “Ledgerlocks: A security framework for blockchain protocols based on adaptor signatures,” in *Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security*, 2023, pp. 859–873. 20. ChainLink, “Understanding cross-chain token transfers,” [https://chain.](https://chain.link/education-hub/cross-chain-token-transfers) [link/education-hub/cross-chain-token-transfers](https://chain.link/education-hub/cross-chain-token-transfers), 2025. 21. M. Herlihy, “Atomic cross-chain swaps,” in *Proceedings of the 2018 ACM symposium on principles of distributed computing*, 2018, pp. 245–254. 22. Y. Xue, D. Jin, and M. Herlihy, “Fault-tolerant and expressive cross-chain swaps,” in *Proceedings of the 24th International Conference on Distributed Computing and Networking*, 2023, pp. 28–37. 23. ChainLink, “Cross chain interoperability protocol,” [https://docs.chain.](https://docs.chain.link/ccip) [link/ccip](https://docs.chain.link/ccip), 2025. 24. Cosmos, “Cosmos inter-blockchain communication protocol,” [https:](https://docs.cosmos.network/ibc/v10.1.x/intro) [//docs.cosmos.network/ibc/v10.1.x/intro](https://docs.cosmos.network/ibc/v10.1.x/intro), 2025. 25. “Thorswap,” , 2025. 26. deBridge, “debridge,” , 2025. 27. M. Kelkar, F. Zhang, S. Goldfeder, and A. Juels, “Order-fairness for byzantine consensus,” in *Annual International Cryptology Conference*. Springer, 2020, pp. 451–480. 28. M. Kelkar, S. Deb, and S. Kannan, “Order-fair consensus in the permissionless setting,” in *Proceedings of the 9th ACM on ASIA Public-Key Cryptography Workshop*, 2022, pp. 3–14. 29. W. Ding, Y. Tang, and Y. Wang, “Asymmetric mempool dos security: Formal definitions and provable secure designs,” in *2025 IEEE Symposium on Security and Privacy (SP)*. IEEE, 2025, pp. 1584–1602. 30. “Symbiosis explorer,” , 2025. 31. “1inch,” , 2025. 32. Tenderly, “Tenderly,” , 2025. 33. “Coinmarketcap,” , 2025. 34. “Thorstatistics,” [https://runescan.io/stat/swapVolumeUsd?time=](https://runescan.io/stat/swapVolumeUsd?time=month) [month](https://runescan.io/stat/swapVolumeUsd?time=month), 2025. 35. B. Weintraub, C. F. Torres, C. Nita-Rotaru, and R. State, “A flash (bot) in the pan: measuring maximal extractable value in private pools,” in *Proceedings of the 22nd ACM Internet Measurement Conference*, 2022, pp. 458–471. 36. A. Kate, E. V. Mangipudi, P. Mukherjee, H. Saleem, and S. A. K. Thyagarajan, “Non-interactive vss using class groups and application to dkg,” in *Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security*, 2024, pp. 4286–4300. 37. “Openocean,” , 2025. 38. S. Eskandari, S. Moosavi, and J. Clark, “Sok: Transparent dishonesty: front-running attacks on blockchain,” in *International Conference on Financial Cryptography and Data Security*. Springer, 2019, pp. 170–189. 39. C. F. Torres, R. Camino et al., “Frontrunner jones and the raiders of the dark forest: An empirical study of frontrunning on the ethereum blockchain,” in *30th USENIX Security Symposium (USENIX Security 21)*, 2021, pp. 1343–1359. 40. L. Zhou, K. Qin, C. F. Torres, D. V. Le, and A. Gervais, “High-frequency trading on decentralized on-chain exchanges,” in *2021 IEEE Symposium on Security and Privacy (SP)*. IEEE, 2021, pp. 428–445. 41. Z. Wu, J. Wu, H. Zhang, Z. Zheng, and W. Wang, “Hunting in the dark forest: A pre-trained model for on-chain attack transaction detection in web3,” in *Proceedings of the ACM on Web Conference 2025*, 2025, pp. 4519–4530. 42. Z. Ma, M. Jiang, F. Luo, X. Luo, and Y. Zhou, “Surviving in dark forest: Towards evading the attacks from front-running bots in application layer,” in *Proceedings of the 34th USENIX Security Symposium (USENIX SEC)*, 2025. 43. T. Niedermayer, P. Saggese, and B. Haslhofer, “Detecting financial bots on the ethereum blockchain,” in *Companion Proceedings of the ACM Web Conference 2024*, 2024, pp. 1742–1751. 44. Z. Li, J. Li, Z. He, X. Luo, T. Wang, X. Ni, W. Yang, X. Chen, and T. Chen, “Demystifying defi mev activities in flashbots bundle,” in *Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security*, 2023, pp. 165–179. 45. B. z, C. F. Torres, C. Schlegel, B. Mazorra, J. Gebele, F. Rezabek, and F. Matthes, “Cross-chain arbitrage: The next frontier of mev in decentralized finance,” *arXiv preprint arXiv:2501.17335*, 2025. 46. K. Gogol, J. Messias, D. Miori, C. Tessone, and B. Livshits, “Cross-rollup mev: Non-atomic arbitrage across l2 blockchains,” *arXiv preprint arXiv:2406.02172*, 2024. 47. C. Ferreira Torres, A. Mamuti, B. Weintraub, C. Nita-Rotaru, and S. Shinde, “Rolling in the shadows: Analyzing the extraction of mev across layer-2 rollups,” in *Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security*, 2024, pp. 2591–2605. ## Appendix A. Other Data The following table presents an overview of the events and functions leveraged in the detection. | Protocol | Event name | Event topic hash | | ----------------------------------------------------------------- | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Uniswap V2, PancakeSwap V2, Uniswap V3, PancakeSwap V3, Symbiosis | Swap, Swap, Swap, Swap, OracleRequest | 0xd78ad95fa46c994b6551d0da85fc275fe613ce37657fb8d5e3d130840159d822 0xd78ad95fa46c994b6551d0da85fc275fe613ce37657fb8d5e3d130840159d822 0xc42079f94a6350d7e6235f29174924f928cc2ac818eb64fed8004e115fbcca67 0x19b47279256b2a23a1665c810c8d55a1758940ee09377d4f8d26497a3577dc83 0x532dbb6d061eee97ab4370060f60ede10b3dc361cc1214c07ae5e34dd86e6aaf | | Protocol | Function name | Function signature | | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------- | | Symbiosis, Symbiosis, Symbiosis, Symbiosis, Symbiosis, 1inch, 1inch, OpenOcean, Uniswap V2, Uniswap V2 | metaMintSyntheticToken, metaBurnSyntheticToken, receiveRequestV2Signed, metaUnsynthesize, externalCall, swap, uniswapV3SwapTo, swap, swapExactTokensForTokens, swapExactTokensForETH | 0xc29a91bc 0xe66bb550 0x84d61c97 0xc23a4c88 0xf5b697a5 0x12aa3caf 0xbc80f1a8 0x90411a32 0x38ed1739 0x18cbafe5 | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://newsandwich.gitbook.io/docs/new-sandwich-report/the-walls-have-ears-unveiling-cross-chain-sandwich-attacks-in-defi.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.