Веерх ↑

Cross-chain transfer

Learn how cross-chain transfers work, the main methods (bridges, wrapped assets, native swaps), and the key risks and considerations.

A cross-chain transfer is the process of moving value or assets from one blockchain to another, such as from Ethereum to Arbitrum, from Solana to Ethereum, or from BNB Chain to Polygon. Because most blockchains cannot directly read or write to each other, cross-chain transfers rely on special protocols, bridges, or wrapped representations of assets.

For users, cross-chain transfers enable access to different ecosystems, lower fees, faster settlement, or specific applications that exist only on certain chains. However, they also introduce additional complexity and risk compared to same-chain transactions.

Why cross-chain transfers are needed

Blockchains are typically isolated environments.

Isolated ledgers

  • Each blockchain maintains its own ledger, consensus, and set of validators.
  • A token on Ethereum (for example, ERC-20 USDC) does not natively exist on Solana, Arbitrum, or other chains.
  • Smart contracts on one chain cannot directly control assets on another chain.

Different ecosystems and use cases

  • Some applications are only available on specific chains (for example, certain DeFi protocols, NFT marketplaces, or gaming platforms).
  • Fees, speed, and user experience vary significantly between chains (for example, L2s vs L1s).
  • Users may want to:
    • Move funds to a chain with lower transaction fees.
    • Access a particular protocol or liquidity pool.
    • Diversify across ecosystems.

Cross-chain transfers provide the “bridges” between these isolated environments.

How cross-chain transfers work

There is no single standard; different protocols use different mechanisms. The common theme is that value is “locked or burned” on the source chain and “minted or released” on the destination chain.

1. Lock-and-mint (pegged / wrapped assets)

  • On the source chain:
    • You send your original assets (for example, ETH on Ethereum) to a bridge contract or custodian.
    • Those assets are locked in a smart contract or held by a custodian.
  • On the destination chain:
    • The bridge mints a corresponding representation (for example, “wrapped ETH” or “bridged ETH”) on the target chain.
    • You receive this wrapped asset in your destination-chain address.
  • The wrapped asset is pegged 1:1 (in theory) to the original asset and can be used in DeFi, trading, or other applications on the destination chain.
  • To move back:
    • You burn or return the wrapped asset on the destination chain.
    • The bridge releases the original asset on the source chain.

This is the most common pattern for token bridges.

2. Burn-and-mint (native assets)

  • Some bridges handle native assets more directly:
    • On the source chain, the native tokens are burned (removed from circulation).
    • On the destination chain, an equivalent amount of native tokens is minted or released from a reserve.
  • This approach aims to keep the total supply consistent across chains.
  • It requires tight coordination and trust in the bridge’s control over minting/burning on both chains.

3. Liquidity-based swaps

  • Instead of locking and minting, some protocols use liquidity pools on both chains:
    • You deposit asset A on chain 1 into a pool.
    • The protocol pays you asset A (or a stablecoin equivalent) from a pool on chain 2.
    • Internally, the protocol rebalances liquidity across chains over time.
  • To the user, this feels like a cross-chain swap: you send on one chain, receive on another.
  • This can be faster and avoid minting new tokens, but relies on sufficient liquidity and proper risk management.

4. Message-passing and generalised bridges

  • More advanced protocols allow arbitrary data and contract calls to be passed between chains:
    • You initiate a transaction on chain 1 that includes a message for a contract on chain 2.
    • Relayers or validators transmit and verify the message across chains.
    • The destination contract executes based on the verified message (for example, releasing funds, minting tokens, or triggering logic).
  • This enables complex cross-chain applications (for example, cross-chain lending, NFTs, or governance).
  • It also increases complexity and attack surface.

Common types of cross-chain solutions

Users encounter several types of cross-chain infrastructure.

Token bridges

  • Purpose-built to move specific tokens between chains.
  • Examples:
    • Official bridges from L1 to L2 (for example, Ethereum to Arbitrum, Optimism, Base).
    • Third-party multi-chain bridges supporting many assets and chains.
  • Typically use lock-and-mint or burn-and-mint mechanisms.
  • Users interact via a bridge UI: select source chain, destination chain, asset, and amount.

Wrapped assets

  • Representations of an asset on a chain where it does not natively exist.
  • Examples:
    • Wrapped BTC (WBTC) on Ethereum representing Bitcoin.
    • Bridged USDC, ETH, or other tokens on various L2s and alt-L1s.
  • Once wrapped, these assets behave like native tokens on the destination chain (ERC-20, SPL, etc.).
  • Users must trust the bridge or custodian behind the wrapped asset to maintain the peg and redeemability.

Cross-chain DEX aggregators

  • Aggregators that find the best route to move value across chains:
    • They may combine bridges, liquidity pools, and swaps.
    • Show estimated received amounts, fees, and times across multiple routes.
  • Simplify the user experience by abstracting away the underlying bridge mechanics.

Native chain bridges (official)

  • Many L2s and sidechains provide official bridges from the mainnet:
    • Often more integrated and considered “canonical” for that chain.
    • May have different security assumptions than third-party bridges.
  • Common for moving ETH and major tokens between Ethereum and its L2s.

Risks of cross-chain transfers

Cross-chain activity introduces risks beyond standard same-chain transactions.

Smart-contract and bridge risk

  • Bridges are complex smart-contract systems that manage large amounts of value.
  • They have been frequent targets of exploits and hacks:
    • Bugs in bridge contracts.
    • Compromised validator or relayer keys.
    • Logic errors in message verification or minting/burning.
  • If a bridge is exploited, users’ locked or wrapped assets can be lost or depegged.

Custodial and centralisation risk

  • Some bridges rely on centralised custodians or multi-sig wallets to hold locked assets.
  • Users must trust these entities to:
    • Safeguard the reserves.
    • Honour redemptions.
    • Not freeze or censor transfers.
  • If the custodian is compromised, sanctioned, or acts maliciously, users may lose access to their funds.

Peg and depeg risk

  • Wrapped or bridged assets are supposed to maintain a 1:1 peg with the original asset.
  • In stress scenarios (for example, bridge exploits, loss of confidence):
    • The market price of the wrapped asset can deviate from the underlying (trade at a discount).
    • Redemption may be paused or restricted.
  • Users may find their “1 ETH on L2” not truly worth 1 ETH if the bridge is impaired.

Finality and timing risk

  • Cross-chain transfers are not instantaneous:
    • They depend on finality on the source chain.
    • They may require confirmation periods, challenge windows, or relayer processing time.
  • During this window:
    • The transaction could be delayed or, in rare cases, reverted (depending on the bridge design).
    • Users may see funds “in transit” with no immediate ability to cancel or modify.

User error and complexity

  • Users must select the correct:
    • Source and destination chains.
    • Asset versions (native vs bridged vs wrapped).
    • Recipient address on the destination chain.
  • Mistakes can lead to:
    • Funds sent to the wrong chain or address.
    • Receiving an unexpected token variant (for example, bridged USDC vs native USDC).
    • Difficulty reversing or recovering misrouted funds.

Regulatory and compliance risk

  • Some bridges or wrapped assets may be subject to:
    • Sanctions or restrictions in certain jurisdictions.
    • Regulatory actions affecting their operation or redeemability.
  • Users in regulated environments should be aware of the legal status of the bridges and tokens they use.

How cross-chain transfers affect users

From a user’s perspective, cross-chain transfers show up in several ways.

In wallets and interfaces

  • Multi-chain wallets show balances per chain:
    • ETH on Ethereum, ETH on Arbitrum, USDC on Polygon, etc.
    • Native vs bridged versions may appear as separate tokens.
  • Bridge UIs or integrated “Move” features allow you to:
    • Select source and destination chains.
    • Choose the asset and amount.
    • See estimated fees, received amount, and time.

Fees and costs

  • Cross-chain transfers typically involve multiple fee components:
    • Source-chain transaction fee (gas).
    • Bridge fee or protocol fee.
    • Destination-chain transaction fee for receiving or claiming.
  • Total cost can be significantly higher than a same-chain transfer, especially during congestion.

Timing and status

  • Transactions may show as:
    • “In progress”, “Waiting for confirmations”, or “Relaying to destination chain”.
    • Completed only after both chains have processed their parts.
  • Users must be patient and avoid resubmitting transactions prematurely, which can complicate recovery.

Asset variants

  • After a cross-chain transfer, you may hold:
    • A bridged or wrapped version of the asset, not the native one.
    • Multiple variants of the same economic asset (for example, native USDC, bridged USDC from different bridges).
  • For DeFi or trading, it matters which variant you use:
    • Some protocols only accept specific versions.
    • Liquidity and pricing can differ between variants.

Good practices for users

To use cross-chain transfers more safely:

  • Use well-known, widely audited bridges with a strong track record and significant TVL (total value locked).
  • Prefer official or canonical bridges for a given chain when available, especially for large amounts.
  • Double-check:
    • Source and destination chains.
    • Asset type (native vs bridged vs wrapped).
    • Recipient address on the destination chain.
  • Start with a small test transfer before moving large amounts, especially when using a new bridge or chain.
  • Monitor the transaction using block explorers for both chains and the bridge’s tracking page, if available.
  • Be aware that cross-chain transfers are not instant; allow time for finality and relaying.
  • Keep records of bridge transactions for tax and personal tracking (source chain TX hash, destination chain TX hash, amounts, timestamps).

Good practices for platforms

For wallets, exchanges, or protocols integrating cross-chain functionality:

  • Clearly label asset variants (native vs bridged vs wrapped) to avoid user confusion.
  • Provide clear information on:
    • Which bridges are used.
    • Estimated times, fees, and risks.
    • Any known limitations or chain-specific considerations.
  • Implement robust validation to prevent common user errors (wrong chain, incompatible assets).
  • Offer transaction tracking across both chains and the bridge layer.
  • Educate users about cross-chain risks, not just convenience and use cases.
  • Continuously monitor bridge security and be ready to pause or warn users if a bridge is compromised.
Spend your
crypto.
Don’t sell it
Join the members who figured it out.

Cookies preferences

✕

Others

Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.

Necessary

Necessary
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.

Advertisement

Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.

Analytics

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.

Functional

Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.

Performance

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.