Cross-Chain Sandwich Attack Analysis

• Cross-chain sandwich attacks are manipulative strategies targeting cross-chain bridge protocols by exploiting early swap parameter leakage to gain a temporal advantage.
• They leverage liquidity pool events and automated market makers to front-run and back-run transactions across interconnected blockchain networks.
• Mitigation strategies include using private relayers, event encryption, and calldata abstraction to obscure swap details, though each incurs trade-offs in decentralization and cost.

A cross-chain sandwich attack is a manipulative strategy targeting cross-chain bridge protocols—specifically those based on liquidity pools and automated market makers (AMMs)—which exploits the information leakage in cross-chain interoperability mechanisms. Unlike traditional single-chain sandwich attacks that rely on mempool transparency within a single blockchain, cross-chain sandwich attacks exploit the fact that detailed transaction information is broadcast via events on the source chain before the corresponding swap transaction even appears on the destination chain. This early leakage of swap parameters grants attackers a provable temporal and informational advantage, enabling them to place front-running and back-running transactions on the destination chain in a manner unachievable using classical memory pool (MEV) strategies. The effectiveness, distinctive workflow, and empirical scale of this attack vector have established it as a critical threat to cross-chain decentralized finance applications (Li et al., 19 Nov 2025).

1. Foundations of Cross-Chain Bridge Protocols and Attack Surface

Cross-chain interoperability enables trust-minimized asset and data transfers from a source chain ($\mathcal{S}$), such as Ethereum, to a destination chain ($\mathcal{D}$), such as BSC. In liquidity-pool-based cross-chain bridge protocols (e.g., Symbiosis), the workflow proceeds as follows:

• On $\mathcal{S}$, the user invokes a bridge contract $\mathcal{C}_S$ with parameters $({\text{dstChain}},\, \Delta x,\, s)$, locking or burning $\Delta x$ of token X, and emitting an event (OracleRequest) encapsulating all requisite calldata for execution on $\mathcal{D}$.
• Permissionless relayers observe this event and propagate it to $\mathcal{D}$.
• On $\mathcal{D}$, the corresponding contract $\mathcal{C}_D$ uses the event data to execute a DEX swap ($\Delta x: X\to Y$ via a local AMM), releasing the output Y to the user.

Crucially, the OracleRequest event on $\mathcal{S}$ exposes the entire swap specification: liquidity pool address, input amount $\Delta x$, minimum output $(1-s)\Delta y$, and DEX routing paths. These disclosures happen before any corresponding transaction enters the mempool of $\mathcal{D}$, rendering swap execution entirely transparent to adversaries well in advance.

2. Comparison with Single-Chain Sandwich Attacks

A single-chain sandwich attack leverages the mempool’s openness to insert a pair of trades around a detected victim swap $T_v$ (size $\Delta x_v$) with slippage tolerance $s$:

1. The attacker places a front-running swap $T_{A1}$ ($\Delta x_{A1}: X\to Y$) at a premium gas price, inflating the $X:Y$ price.
2. $T_v$ executes at this adverse rate.
3. The attacker back-runs with $T_{A2}$ ($\Delta y_{A1}: Y\to X$), reversing the price distortion to extract profit.

The optimal front-run size $\Delta x_{A1}$ equates the victim's post-sandwich price to their slippage limit using established AMM equations. Aggregate profit is $P = \Delta x_{A2} - \Delta x_{A1} - G_c$, with $G_c$ denoting gas expenditure.

In contrast, cross-chain sandwich attacks enable the attacker to act on $\mathcal{D}$ prior to any observable activity in its mempool, entirely subverting defenses designed for single-chain MEV strategies (Li et al., 19 Nov 2025).

3. Mechanism and Formal Analysis of the Cross-Chain Attack

3.1 Information Flow and Adversarial Advantage

In AMM-based cross-chain messaging paradigms (CCMPs), source-chain events leak the deterministic calldata required for destination-chain execution. Adversaries monitoring $\mathcal{S}$ receive OracleRequest events exposing:

• The target pool address
• Input amount $\Delta x$
• Minimum return threshold $(1-s)\Delta y$
• Routing details

This signal precedes and is independent of the subsequent destination-chain transaction’s mempool appearance, often by several seconds.

Formally, the attacker’s probability of sandwich success rises from a baseline $P_{\text{baseline}}$ (when only observing $\mathcal{D}$’s mempool) to $P_{\text{front}}$ with event leakage. Empirically, $P_{\text{front}} \approx 1$, while $P_{\text{baseline}}$ may be $0.3$–$0.5$ under MEM-bot competition, yielding $$\mathrm{Advantage} = P_{\text{front}} - P_{\text{baseline}} > 0$$. This temporal dominance allows the attacker to submit a front-run in block $N_v-1$ before the victim’s $T_v$, circumventing all mempool-based ordering controls (Li et al., 19 Nov 2025).

3.2 Workflow and Pseudocode Overview

The attack sequence is as follows:

1. Monitor $\mathcal{S}$ for OracleRequest events revealing $\Delta x$, $s$, and pool.
2. Compute optimal $\Delta x_{A1}$ via AMM optimality equations.
3. Immediately submit $T_{A1}$ to $\mathcal{D}$, with a competitive gas price.
4. Detect $T_v$’s execution on $\mathcal{D}$ at the manipulated price.
5. Submit $T_{A2}$ (back-run) to recoup profit.
6. Aggregate net profit: $\Delta x_{A2} - \Delta x_{A1} - \text{gas costs}$.

Sample (partial) pseudocode is:

def AttackerSandwich(): subscribe to sourceChain.events(OracleRequest) onEvent(e): parse Δx, s, pool = e.calldata Δx_A1 = solve_AMM_optimality(Δx, s) sendTransaction(T_A1, pool, Δx_A1) await_confirmation(T_v, pool) sendTransaction(T_A2, pool, derive_Δy_A1(Δx_A1))

4. Empirical Quantification and Heuristic Detection

An empirical paper was conducted on the Symbiosis bridge protocol, covering transactions between August 10 and October 10, 2025. The dataset included 60,130 cross-chain transactions, filtered to 37,649 valid AMM-based swaps. A bespoke heuristic detector (Algorithm 1) was deployed, matching front-running and back-running transaction pairs on the destination chain by pool, direction, and token amounts—with surrounding timing windows and amplitude checks—while excluding classical single-chain (same-block) sandwiches.

Key findings:

• 316,809 cross-chain sandwich pairs were identified, of which 269 occurred in the same block (representing classical single-chain MEV attacks).
• The accrued profit (excluding gas) was $5.273 million USD on$412.6 million traded—1.28% of bridged volume.
• Single-chain sandwiches found in the same dataset amounted to just $6.1K in profit, indicating the cross-chain variant’s dominance.
• Top source/dest pairs: Ethereum→BSC ($2.096M), Base→BSC ($1.448M).
• The BUSD↔WBNB pair on PancakeSwap V3 (BSC) was the principal attack target: 182,620 attacks, $3.17M profit.
• Empirically, $q=0.57$ (no noisy swap), $p=0.68$ (profitable if noisy occurs), $r^+=4.5\%$, $r^-=-4.7\%$; average expected per-trade return $E[r]\approx 3.23\%$ (Li et al., 19 Nov 2025).

5. Profitability, Risks, and Defensive Limitations

Expected profit per attack is:

$$E[\Pi] = \alpha \times (\Delta P) - C_{\mathrm{gas}}$$

with:

• $\alpha$ as the probability of no large interfering transactions,
• $\Delta P$ as price impact (approximately $s\Delta x_v$),
• $C_{\mathrm{gas}}$ as total gas cost.

A refined model incorporating noise parameters is:

$$E[P] = \Delta x_{A1}\left[(q+(1-q)p)\,r^+ + (1-q)(1-p)\,r^-\right]$$

This captures the impact of stochastic, unrelated swaps ("noisy swaps") potentially affecting the realized profit. The profitability and success probability are markedly higher for cross-chain sandwich attacks than for single-chain attacks, due to the advance knowledge of victim intent not reliant on destination-chain mempool visibility.

Existing MEV defenses, including proposer-builder separation, fair ordering, and encrypted/private mempools, are circumvented because they assume the victim's transaction appears first in the target chain's mempool. In the cross-chain model, attackers act preemptively, before such visibility occurs (Li et al., 19 Nov 2025).

6. Mitigation Strategies and Open Challenges

Potential mitigations include:

• Private relayers: Do not emit swap details on-chain; route calldata only to a trusted relay set, thereby trading off some degree of trust-minimization for privacy.
• Event encryption: Source-chain events are encrypted, with plaintext revealed only via threshold decryption upon arrival on the destination chain. This adds considerable complexity and gas burden.
• Calldata abstraction: On $\mathcal{S}$, publish merely user intent $(\Delta x,X,Y)$ rather than concrete pool or routing information, postponing swap path selection to execution time on $\mathcal{D}$. This inhibits preemptive front-running by rendering prediction of the target pool infeasible.

Each mitigation involves practical trade-offs in decentralization, gas cost, and user experience. Current defensive techniques targeting single-chain MEV manipulation are ineffective against this cross-chain variant.

Open research questions include: extending analysis to other cross-chain MEV strategies (e.g., arbitrage, liquidation), modeling attacker adaptations to noisy transaction regimes, and designing formal protocols that cryptographically conceal swap parameters until execution, especially in heterogeneous (non-EVM, UTXO-based) ecosystems (Li et al., 19 Nov 2025).