Skip to content
Financial Context Wiki

Cross-chain bridge

A verification-first guide to cross-chain asset and message routes, trust models, message states, replay protection, backing, liquidity, fees, retries and final reconciliation.

Updated

For educational purposes only; not investment, legal, or security advice. A cross-chain route can fail through consensus, verification, contracts, governance, operations, liquidity, or user error.

Direct answer

A cross-chain bridge is a system that causes an asset transfer or message observed in one execution domain to produce an authorized result in another. Independent chains do not automatically trust each other’s state. A route therefore needs a verification model, destination execution rules and, for assets, an issuance, custody or liquidity model.

Those dimensions must be separated. Assets may use lock-and-mint, burn-and-release, issuer burn-and-mint or liquidity-provider delivery. Messages may be accepted through a light client or validity proof, an optimistic dispute process, an attester or validator threshold, or an application-specific verifier. Any combination can have different finality, replay, upgrade, liveness and solvency risks. A source transaction, an attestation, a destination balance and economic redemption are distinct states.

1
Lock or burn

The source-chain contract escrows or destroys the source representation.

How it works

  1. Pin the route snapshot: protocol and version, source and destination chainId or domain, gateway, router, messenger or adapter addresses, token pair, recipient, amount, decimals, deadline, block references and official documentation. A name, icon or aggregator label is not identity.
  2. Classify two independent dimensions. Record whether the asset path is lock-and-mint, burn-and-release, issuer burn-and-mint or liquidity delivery, and whether the message path uses consensus proofs, light clients, optimistic verification, attestations, a validator threshold or another verifier.
  3. Map the trust and control roots. Include source finality, data availability, proof or attester assumptions, destination executor, replay protection, proxy implementation, admin or security council, upgrade delay, pause and rate limits. Canonical, official, audited or proof-based is not a complete risk conclusion.
  4. Build the direction-specific message state machine: source submission, inclusion and required finality; message ID, nonce or sequence; proof or attestation; relay; destination execution; acknowledgement; and any retry, timeout, refund or claim. Deposit and withdrawal paths can be asymmetric.
  5. Build the asset and message ledgers in raw units. Reconcile eligible escrow, live representation supply, locked-not-yet-minted claims, burned-not-yet-released claims, issuer burns and mints, consumed message IDs and remaining allowances. Never count escrow and its representation as two independent assets.
  6. Build an executable economic ledger. Separate token principal and protocol fee from source and destination gas, relayer or liquidity-provider fee, quoted capacity, minimum output, slippage, price impact and waiting cost. A quote is not a fill, and gas paid in a native token is not automatically deducted from bridged-token output.
  7. Reconcile the route from actual evidence: source receipt and final block, message or packet status, verifier output, destination receipt and state changes, exact received token contract, balance, redeemability and liquidity. Revoke excess authority, preserve recovery gas, and stop rather than repeat an unexplained transfer.

Worked examples

  • Backing with in-flight claims. Eligible escrow is 10,000 units; live destination representation is 9,700 units; locked-not-yet-minted claims are 200 units; and burned-not-yet-released claims are 100 units. Economic claims are 9,700 + 200 + 100 = 10,000 units, so adjusted coverage is 10,000 / 10,000 = 100.0000000000%. Dividing only by live supply falsely reports 10,000 / 9,700 = 103.0927835052%. Coverage does not prove contract safety or immediate liquidity.
  • Token output versus economic cost. A user sends 5,000 USDC; a 5 USDC protocol fee is deducted, so destination token output is 4,995 USDC. Source gas is 0.003 ETH and destination claim gas is 0.001 ETH; at an explicit 2,000 USD/ETH, those separate cash flows cost $6 and $2. Total economic cost is $5 + $6 + $2 = $13, and net wealth received is $4,987, but the destination balance remains 4,995 USDC.
  • Threshold compromise and reserve shortfall. A hypothetical 3-of-5 attester bridge has $5,000,000 of escrow and 5,000,000 legitimate wrapped units. If three authorized keys forge an unbacked 1,000,000-unit mint, supply becomes 6,000,000, shortfall is $1,000,000, and pro-rata coverage is 5,000,000 / 6,000,000 = 83.3333333333%, or $0.8333333333 of reserve per token. That is an accounting result, not a guaranteed market or recovery price.
  • Liquidity-route capacity. A request is 100,000 units. Route A has capacity 60,000 and charges 0.20%, delivering 60,000 * (1 - 0.002) = 59,880 units. An independent route B handles 40,000 at 0.35% plus 20 units, delivering 40,000 * (1 - 0.0035) - 20 = 39,840 units. Total output is 99,720 units; cost is 280 units, or 280 / 100,000 = 0.2800000000%. Each route has separate security assumptions, and partial execution exists only if the actual protocol and receipts permit it.

Risks

  • Selecting the wrong source, destination, chainId or domain.
  • Using a phishing interface, documentation site or route aggregator.
  • Sending through a counterfeit gateway, router, messenger or adapter.
  • Accepting the wrong token pair, recipient or same-symbol representation.
  • Misreading decimals, raw units or fee-on-transfer and rebasing behavior.
  • Leaving an excessive approval, permit or operator permission.
  • Relying on a source transaction before sufficient finality or after a reorganization.
  • Trusting compromised verifier keys, validators, attesters or threshold members.
  • Accepting a flawed light client, proof verifier or dispute mechanism.
  • Allowing replay, double mint, sequence, ordering or idempotency failures.
  • Treating source success as proof of destination execution.
  • Underfunding destination execution, retry, claim or refund gas.
  • Depending on unavailable relayers, provers, attesters or executors.
  • Losing liveness through sequencer censorship or unavailable data.
  • Missing an upgrade, admin change, pause, rate limit or timelock bypass.
  • Ignoring escrow insolvency, pooled reserves or in-flight accounting drift.
  • Assuming nonstandard token hooks are compatible with the bridge.
  • Exceeding liquidity capacity or relying on a stale quote and rebalance path.
  • Suffering depeg, slippage, MEV or an unusable redemption route.
  • Misunderstanding timeout, refund, recovery, tax, sanctions or custody rules.

Common misconceptions

  • The identical coin physically moves from one blockchain to another.
  • Canonical, official, audited or proof-based automatically means risk-free.
  • A successful source transaction guarantees destination credit and final settlement.
  • One-for-one backing guarantees immediate one-for-one redemption and market liquidity.
  • A fast bridge is just the same settlement route running faster.

Sources

Navigation

Search the wiki...