Skip to content
Financial Context Wiki

Canonical Bridge

A verification-first guide to protocol-designated bridges, asset backing, cross-domain message states, optimistic and validity-proof withdrawals, upgrade controls, fees and fast-bridge comparisons.

Updated

For educational purposes only; not investment, legal, or security advice. A protocol-designated bridge can still fail through contracts, proofs, data availability, governance, operations, liquidity, or user error.

Direct answer

A canonical bridge is the asset or message route designated by a particular rollup or chain ecosystem. It usually connects contracts that escrow or burn an asset on one chain, transmit a protocol-recognized message, and mint, unlock or release the corresponding asset on the other chain. The word canonical is an ecosystem label, not a universal standard, cryptographic guarantee or proof that a website and address are authentic.

Its security is not an additive formula. It depends jointly on source-chain finality, data availability, state or message verification, bridge accounting, destination execution, replay protection, upgrade and pause powers, and a usable exit path. A fast bridge may pay users sooner from liquidity and settle later through the canonical route, but that adds liquidity-provider, solver, verifier and execution assumptions rather than accelerating the same state machine for free.

1
Lock or burn

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

How it works

  1. Pin the route snapshot: source and destination chainId, direction, rollup stack and version, bridge, portal, messenger, inbox or gateway addresses, token addresses, recipient, amount, block references and official documentation. Never rely on a search result or the label official alone.
  2. Resolve the security and control model. Record optimistic fault-proof or validity-proof rules, data-availability mode, sequencer and forced path, proxy implementation, admin or security council, timelock, pause state, rate limits and upgrade delay. Canonical does not mean immutable.
  3. Classify the asset ledger. Distinguish native value from ERC-20 tokens and identify lock-and-mint, burn-and-release or burn-and-mint behavior. Verify the registered token pair, raw units, decimals, custom gateway and support for fee-on-transfer, rebasing or denylisted assets.
  4. Build the direction-specific message state machine. A deposit can move through approval, source escrow or burn, source finality, derivation or relay and destination mint or unlock. A withdrawal can require destination burn or escrow, message inclusion, state commitment, proof, challenge or proof acceptance, finalization and source release.
  5. Track three clocks separately: transaction inclusion, protocol settlement or state finality, and asset availability for use or withdrawal. Record the source transaction hash, message or withdrawal hash, output or proof reference and each relay, prove, finalize, claim, retry or refund transaction.
  6. Build the economic ledger. Separate bridged principal, source and destination gas, proof or finalization gas, protocol or relayer fee, liquidity-provider fee, slippage and waiting-time opportunity cost. Compare a fast bridge with the canonical path as different claims and trust models.
  7. Reconcile the completed route against receipts, events, escrow balances, representation supply, pending claims, recipient balances and remaining allowances. Wait for the required finality, keep emergency gas, test permissionless or forced paths where applicable, and stop rather than repeating a deposit whose message state is unexplained.

Worked examples

  • Native-asset deposit ledger. A user starts with 5.0000 ETH, deposits 2.5000 ETH and pays 0.0042 ETH of source-chain gas. The source wallet ends at 5.0000 - 2.5000 - 0.0042 = 2.4958 ETH; escrow increases by 2.5000 ETH; and after a successful one-for-one relay the destination representation increases by 2.5000 ETH. The backing ratio is 2.5000 / 2.5000 = 100%. Escrow and representation are backing and claim, not 5 ETH of newly created economic value.
  • Raw token units and mapping. A user deposits 1,250.000000 USDC. The verified origin contract uses 6 decimals, so the raw amount is 1,250 * 10^6 = 1,250,000,000. Under a verified one-for-one mapping with no token fee, source escrow and destination mint each change by 1,250,000,000 raw units, displaying 1,250.000000 USDC remotely. A same-symbol token at another address is not interchangeable evidence.
  • Withdrawal clocks are distinct. Assume a deployment records a withdrawal at 2026-08-01 12:00:00 UTC and applies a 604,800-second = 7-day challenge period from that protocol-defined start. The time threshold is 2026-08-08 12:00:00 UTC; a prove or finalize transaction, gas and the chosen source-chain confirmation policy can add more time. This parameterized example does not claim that every bridge waits seven days, and destination transaction finality does not itself release source-chain funds.
  • Fast-route quote versus waiting cost. For 10,000 USDC, a fast bridge charges 0.08% plus 3 USDC, ignoring gas and slippage. Cost is 10,000 * 0.0008 + 3 = 11 USDC and immediate proceeds are 9,989 USDC. Relative to a hypothetical 7-day canonical wait, the simple annualized price of earlier access is (11 / 9,989) * (365 / 7) = 5.7420305193%. That comparison is not a yield or risk-free rate and excludes solver, liquidity, default and settlement risks.

Risks

  • Using a phishing interface or unverified documentation domain.
  • Selecting the wrong source or destination chain and chainId.
  • Sending to a counterfeit bridge, portal, messenger, gateway or recipient.
  • Accepting a same-symbol token with the wrong registered counterpart mapping.
  • Misreading decimals, raw units or nonstandard token transfer behavior.
  • Confusing native assets, wrapped gas tokens and bridged representations.
  • Exposing an excessive allowance or approving the wrong spender.
  • Missing a proxy upgrade, admin compromise, security-council action or timelock change.
  • Encountering a pause, denylist, rate limit or frozen withdrawal route.
  • Treating a source receipt as proof that destination execution succeeded.
  • Underfunding destination execution, retry, prove, claim or refund gas.
  • Losing a message to retry expiry, incorrect refund handling or address aliasing.
  • Ignoring a source-chain reorganization or insufficient finality.
  • Depending on a censored or unavailable sequencer without a working forced path.
  • Losing data availability needed to prove, reconstruct or exit state.
  • Accepting an invalid state root, message proof, nullifier or replay condition.
  • Depending on unavailable proposers, provers, challengers or permissioned finalizers.
  • Misreading a challenge, maturity or proof-acceptance parameter after an upgrade.
  • Suffering escrow insolvency, accounting drift, token depeg or destination illiquidity.
  • Adding fast-bridge, aggregator, verifier, LP, solver, slippage, tax and sanctions risk.

Common misconceptions

  • Canonical is a universal standard and automatically means trustless or risk-free.
  • A successful source transaction or an arrived UI balance proves final settlement.
  • Every rollup withdrawal has the same seven-day waiting period.
  • Source escrow and destination representations can be added together as independent TVL.
  • A fast bridge is merely the same canonical bridge with a speed setting.

Sources

Navigation

Search the wiki...