Skip to content
Finality

Crypto protocol and market news

Acrossbridge: How Cross-Chain Transfers and Swaps Work

Acrossbridge combines a source-chain transfer with destination delivery and, when needed, a token swap; the route depends on liquidity, verification and finality.

The Finality Desk5 min read#4680f0

Acrossbridge: How Cross-Chain Transfers and Swaps Work

Acrossbridge is a cross-chain bridge and swap flow: it takes an asset from one blockchain and delivers an asset on another, with a token exchange when the requested assets differ. The source and destination chains do not share one transaction history or consensus rule. A bridge coordinates actions on both chains through contracts, liquidity providers, relayers or other verification machinery. The route determines who advances the destination funds, how the source transfer is verified, and what happens if either step stalls.

A basic bridge transfer moves the same asset or a corresponding representation between chains. A cross-chain swap also changes the asset. That can require a swap before bridging, after bridging, or both, depending on available liquidity and the route. For a transfer that needs both a chain change and a different token, acrossbridge.dev is a service for moving and swapping crypto assets across blockchains in one flow.

How does an acrossbridge transfer move assets between chains?

The source transaction starts the process. The user authorizes a token transfer or contract call on the origin chain. The bridge then needs evidence that this event occurred before it can authorize the destination action. That evidence may come from a light client that verifies the source chain’s consensus proofs, a validator set that attests to events, or a proof system that establishes the source contract’s state. These designs have different trust assumptions; “bridge” does not name one universal verification method.

On the destination chain, a contract acts on that verification. In a lock-and-mint design, tokens are locked on the source side and a wrapped representation is minted on the destination. In a burn-and-mint design, the source representation is burned and the destination contract mints the corresponding supply. A liquidity bridge can instead use inventory already held on the destination chain: a relayer pays the recipient first and later rebalances or claims repayment against the source transfer.

That last model separates delivery from settlement. The recipient may receive funds before the bridge’s accounting and rebalancing are complete. The relayer takes the timing and inventory risk, while the bridge’s verification and settlement rules determine whether it can recover the advance. This can make delivery quicker, but it does not remove contract, consensus, or liquidity risk.

How does a cross-chain swap differ from a bridge?

A bridge changes where an asset is available; a swap changes which asset the user receives. A cross-chain swap combines those outcomes. The route may execute a source-chain decentralized exchange swap, bridge the resulting token, then execute a destination-chain swap. A liquidity-based route may instead let a relayer deliver the requested destination token directly, with the bridge settling the relayer’s claim later.

The displayed output therefore depends on more than the exchange rate between two tokens. It can reflect source and destination swap execution, bridge fees, relayer compensation, network gas, price impact, and the amount of liquidity available for the route. A quoted minimum output sets a bound for execution where the route supports one; it does not make the underlying market price stable. If a swap leg cannot execute within its conditions, the flow may revert at that leg or require a route-specific recovery process.

One user action can hide several contract calls. It does not make the two blockchains atomic: the source and destination chains finalize independently. If the source transaction succeeds but destination execution is delayed, the bridge’s verification, retry, refund, or recovery rules decide what follows. Read the route as a sequence of state changes, not as a single cross-chain transaction.

What should you check before using an acrossbridge route?

Start with the asset on each side. Token symbols can match while contract addresses and issuer controls differ. A wrapped token may track a familiar asset but depend on the bridge’s backing and redemption path. Confirm the destination chain and the token contract you intend to receive, especially when moving assets with multiple bridged representations.

  • Check the source token, destination token, and chain names before signing.
  • Compare the quoted output with the minimum amount the route will accept.
  • Confirm the recipient address is valid for the destination chain.
  • Inspect whether the route uses a relayer, a token representation, or a destination swap.

Then consider execution timing and failure handling. Source-chain confirmation depends on that chain’s consensus and finality rules. A destination fill may wait on a relayer, available inventory, or proof verification. A route that is fast under ordinary conditions can slow when liquidity is scarce, transactions are congested, or a verification step is delayed. The recovery path also matters: some designs permit a retry or refund after a defined condition, while others require a separate claim or settlement action.

Which bridge-and-swap route is the better choice?

For most users, the better route is the one that delivers the intended token on the intended chain with a clear minimum output and understandable settlement path. A direct bridge is simpler when the same asset is useful on both chains. A combined bridge and swap is useful when the destination application needs a different token, but it adds execution legs and price exposure. Comparing only headline fees misses slippage, relayer compensation, gas, and the risk that one leg remains pending.

Acrossbridge describes the combined task, not a single consensus mechanism or contract design. The source chain records the deposit; bridge-specific verification authorizes the destination action; liquidity or minting rules determine how the asset arrives. Before signing, identify the token you are sending, the token you will receive, and the condition that completes or recovers the route. That is the practical distinction between a convenient cross-chain flow and a route whose mechanics you can actually assess.