Crosschain arbitrage: trading price gaps between blockchains

Part 4 of a four-part series on DEX arbitrage.

Crosschain arbitrage trades price differences between markets on separate blockchains.

A token may trade at one price through Uniswap on Ethereum and another through a Solana route found by Jupiter. PancakeSwap on BNB Chain may show a third price. These markets do not share liquidity, so temporary gaps can develop between them.

Moving value across chains is the hard part. The trade may require a bridge, two gas assets, and several transactions that cannot settle atomically.

Why prices differ between networks

Each blockchain has its own users, liquidity pools, and trading activity.

A large purchase can push a token higher on one chain while its price remains unchanged elsewhere. Thin pools move more. Network congestion can also slow the arbitrageurs who would normally close the gap.

The main causes are:

• Different pool depth on each chain

• Local demand for the token

• Large swaps isolated to one network

• Bridge delays and transfer limits

• Gas and bridge costs

• Different token issuers or wrappers

A visible gap may persist because it is expensive or impossible to move the asset between the two markets.

The same ticker may not mean the same token

This is the first thing to check.

Tokens with the same symbol can have different contract addresses, issuers, and redemption rights. One chain may use a native version issued directly by the token’s issuer, while another uses a wrapped representation created through a bridge.

USDC, for example, may appear as native USDC or as one of several bridged versions, depending on the chain and route. Those assets should not be assumed to carry the same liquidity or risk.

Before comparing prices, verify:

• Contract address on each network

• Token issuer

• Native or bridged status

• Bridge route between the two versions

• Redemption or conversion process

• Liquidity available for the exact contracts

A price difference between two unrelated tokens sharing a ticker is not arbitrage.

A basic crosschain example

Suppose token X trades at $0.95 through a DEX on Arbitrum and $1.02 through a Solana market.

The gross spread is:

$$\frac{\$1.02 - \$0.95}{\$0.95} \times 100\% = 7.37\%$$

One route is to buy token X on Arbitrum, bridge it to Solana, and sell it there.

The 7.37% gap must cover both swaps, gas on each network, bridge fees, price impact, and any loss caused by the market moving during the transfer.

The route works only if the bridge delivers the exact version accepted by the destination pool.

Bridge-first execution

The simplest workflow uses one pool of capital:

1. Buy the token on the cheaper network.

2. Send it through a supported bridge.

3. Wait for the transfer to complete.

4. Sell the received token on the more expensive network.

This method is capital-efficient, but the position remains exposed while the bridge transfer is pending.

The destination price may fall. Its pool may lose liquidity. The transfer may require extra confirmation or manual claiming. By the time the asset arrives, the spread may be gone.

A bridge quote should therefore be checked for more than the displayed fee. Look at the expected output, minimum received amount, transfer time, route, token contract, and destination gas requirements.

Pre-funded execution

A faster setup keeps capital on both networks.

The trader buys token X on Arbitrum and sells existing token X on Solana at roughly the same time. No bridge transfer is required while the spread is open.

This cuts market exposure but creates an inventory imbalance. After the trade, the Arbitrum wallet holds more token X, while the Solana wallet holds less. Quote currency moves in the opposite direction.

The balances must eventually be rebalanced. The bridge cost has not disappeared; it has been delayed and can be netted across several trades.

Pre-funding also ties up more capital. ROI should be calculated using the funds reserved on both networks, not only the amount used for one leg.

Bridge time is unpredictable

A transfer estimate is not a guarantee.

Bridges use different designs. Some lock assets and mint wrapped tokens. Others burn on one chain and mint on another. Liquidity-based bridges pay out from inventory already available at the destination.

Transfer time can depend on:

• Source-chain confirmation

• Destination-chain finality

• Relayer activity

• Available bridge liquidity

• Security or challenge periods

• Transaction congestion

• Manual claiming requirements

A route described as fast may slow down when liquidity is limited. A cheaper route may require more steps. Speed and cost do not always move together.

Bridge security is part of the trade

Bridges add smart-contract and operational risk. Major bridge systems have suffered serious exploits, and a failure can affect assets still in transit or tokens backed by locked collateral.

Review how the bridge works before sending meaningful size. Check whether it has transfer limits, emergency pause controls, supported token lists, and a clear recovery process.

A bridge aggregator may offer several routes. The cheapest one is not necessarily the safest, and the fastest route may return a wrapped asset with poor destination liquidity.

Test unfamiliar routes with a small amount first.

Gas is paid on more than one chain

Crosschain trades may require gas for:

• The source-chain swap

• Token approval

• Bridge deposit

• Destination claim

• Destination-chain swap

Some bridges bundle part of this process or include destination gas in the quote. Others do not.

Keep the native gas token in both wallets. Arriving on the destination chain without enough gas to sell or claim the asset can leave the trade stuck while the price moves.

Network costs vary with congestion. A route that works for a large trade may be uneconomic for a small one, even when the percentage spread is identical.

Pool depth matters on both sides

Both DEX quotes are size-dependent.

A pool may show token X at $0.95 for a small swap but charge a higher average price for the intended order. The destination pool may offer $1.02 only for a small amount before its price falls.

Estimate the full trade against both liquidity curves:

• Average buy price

• Average sell price

• Swap fees

• Price impact

• Slippage tolerance

• Minimum destination output

The shallower pool sets the practical trade size.

Calculate the complete route

A crosschain PnL estimate should include every step:

$$\begin{aligned} \text{Net PnL} ={}& \text{Destination sale proceeds} - \text{Source purchase cost} \\ &- \text{Swap fees} - \text{Gas on both chains} \\ &- \text{Bridge and relayer fees} - \text{Slippage} \\ &\text{Rebalancing costs} \end{aligned}$$

For pre-funded execution, include the eventual cost of restoring inventory. Ignoring that cost makes repeated trades look more profitable than the full strategy.

Also account for capital held idle on both networks. A wide spread does not guarantee a high return on all committed funds.

Crosschain trades are not atomic

A source-chain transaction cannot normally guarantee that a separate transaction on another chain will complete at the expected price.

One side may fill while the other fails. A bridge message may arrive after the destination quote changes. The destination chain may be congested or temporarily unavailable.

Set limits before execution:

• Maximum bridge time

• Minimum amount received

• Maximum price impact

• Maximum acceptable gas cost

• Exit plan if the destination trade fails

• Capital limit per bridge and chain

Without those limits, the trade becomes an open crosschain position rather than arbitrage.

ArbLens consolidates balances across supported on-chain networks and records transfer history alongside exchange accounts. It does not quote bridge routes or execute swaps. It shows where the capital and inventory sit before and after a crosschain trade.