A blockchain bridge moves assets between two separate blockchains that share no native interoperability. The most common mechanism locks a token inside a smart contract vault on the source chain, then mints a synthetic wrapped equivalent on the destination chain at a 1:1 ratio. The wrapped token represents a claim on the locked collateral. To exit, a user burns the wrapped token, which triggers the source-chain vault to release the original.
​

Each blockchain is a sovereign ledger. Ethereum cannot read Solana's state, and Solana cannot execute an Ethereum transaction. Bridges solve this by acting as a coordination layer between two otherwise isolated networks. The core design challenge is the trust assumption: who or what verifies that the lock on chain A actually happened before authorizing the mint on chain B? That question drives every architectural difference discussed below.
​

Bridge designs span a wide spectrum. At one end, a small committee of validators signs off on every transfer. At the other, cryptographic proofs let the destination chain verify the source-chain event without trusting any operator at all. The tradeoff is roughly: faster and cheaper versus more secure and decentralized. Understanding where a bridge sits on that spectrum is the most important evaluation any user or developer can make before using one. You can track the live risk profiles of major bridges at L2BEAT's bridge risk dashboard.
​

Lock-and-mint is the most common bridge architecture. A user deposits a token into a custodial vault contract on the source chain. A relayer or validator network detects the deposit event, constructs a message attesting that it happened, and submits that message to a contract on the destination chain. That contract mints a wrapped token to the user's address. The wrapped token has no independent value and is redeemable only if the original vault still holds the collateral and the bridge protocol continues to operate.
​

The trust surface is determined by who controls the attestation step between deposit and mint. Three main designs exist in production:
​

Multisig validator sets. A fixed group of validators, often a 5-of-9 or 8-of-13 threshold, co-sign the attestation message. This approach is fast and cheap but concentrates risk: compromise enough keys and an attacker can forge attestations, draining the vault without burning any wrapped tokens. Ronin, Wormhole, and Nomad all exposed variants of this vulnerability in 2022.
​

Optimistic verification. Relayers submit attestations that are accepted after a challenge window of 30 minutes to a few hours, unless a watcher posts a fraud proof within that window. Nomad used this model. It reduces validator-key risk but introduces a window during which a malicious relayer can attempt fraud before watchers respond.
​

Light-client or ZK verification. The destination chain runs a compact representation of the source chain's consensus and verifies block headers or zero-knowledge proofs against them. This eliminates the trusted validator set entirely but is computationally expensive and slow to build correctly. IBC on Cosmos uses a light-client model. Several Ethereum bridges are migrating toward ZK header verification.
​

Regardless of design, the vault contract holding locked tokens is a concentrated target. The entire security of the wrapped token depends on that vault never being drained. That concentration is the central reason bridge hacks have been so large in absolute dollar terms. Learn about the broader implications of trust assumptions in what trustless means in blockchain. The L2BEAT bridge monitor tracks total value locked per bridge and assigns a risk score to each based on validator set size and upgrade key custody.
​

Canonical bridges are the official, protocol-defined bridges that connect an L2 rollup to its parent L1, which is almost always Ethereum. They are operated by the rollup itself rather than a third party. For optimistic rollups like Arbitrum and Optimism, canonical withdrawals from L2 back to Ethereum take seven days. That delay allows anyone to submit a fraud proof challenging an invalid state transition before funds are released.
​

The seven-day window is a fundamental property of the optimistic rollup security model, not an operational limitation. During that window, the rollup's state root is assumed valid unless challenged. Once the window closes without a valid challenge, the withdrawal finalizes on L1 and the ETH or token is released from the bridge contract. For a full explanation of why the delays differ between rollup types, see how optimistic vs ZK rollups work.
​

ZK rollups like zkSync Era and Starknet have shorter finality windows, typically hours rather than days, because validity proofs are submitted with each batch. The L1 contract verifies the proof cryptographically rather than waiting for a challenge period. This makes ZK canonical bridges faster for withdrawals while preserving equivalent security guarantees.
​

Three properties distinguish canonical rollup bridges from third-party alternatives:
​

Security equivalence. A canonical bridge inherits the full security of the L1 and the rollup's proving system. No additional validator set is introduced. Assets bridged via the canonical bridge are as secure as assets held directly on Ethereum, subject only to the rollup's own trust assumptions.
​

Official token representations. Tokens deposited through the canonical bridge receive the rollup's official representation. Third-party bridges often mint competing wrapped versions of the same asset, fragmenting liquidity and creating ambiguity about which token is canonical.
​

No liquidity constraints. Canonical bridges do not require pre-funded liquidity pools on the destination side. They mint directly. There is no slippage and no upper limit on transfer size beyond gas cost.
​

The Ethereum Foundation documents the canonical bridge architecture at ethereum.org/en/bridges.
​

Circle's Cross-Chain Transfer Protocol (CCTP) uses a burn-and-mint mechanism instead of lock-and-mint. When a user transfers USDC via CCTP, Circle burns the tokens on the source chain and mints native USDC directly on the destination chain. No vault ever holds locked collateral. The minted USDC is identical to any other natively issued USDC on that chain, backed by Circle's dollar reserves rather than a third-party wrapped token.
​

This distinction eliminates the vault risk that makes lock-and-mint bridges such concentrated targets. In a lock-and-mint bridge, the vault contract is a single point of failure potentially holding billions in collateral. If the vault is drained, the wrapped tokens become worthless. CCTP has no vault. The burn on chain A and the mint on chain B are both authorized by Circle's attestation service, which signs messages confirming that a burn occurred before allowing any mint on the other side.
​

The practical differences between a standard bridge and CCTP for USDC transfers:
​

Token type. A lock-and-mint bridge produces a wrapped USDC, sometimes called USDC.e or USDbC depending on the chain. CCTP produces native USDC. On chains like Base, Arbitrum, and Avalanche, native USDC and bridged USDC coexist but are not interchangeable at the smart-contract level without an explicit conversion.
​

Trust model. Lock-and-mint bridges trust their own validator set or proof system. CCTP trusts Circle specifically: Circle's ability to run its attestation API correctly and not authorize fraudulent mints. This is a different centralization trade rather than a strictly better one. CCTP is centralized around Circle as issuer, whereas lock-and-mint bridges vary from highly centralized (multisig) to minimally trusted (ZK proofs).
​

Speed. CCTP transfers typically settle in under five minutes on supported chains. Circle's attestation latency is the primary constraint. Full details on supported corridors are at circle.com/cctp.
​

No liquidity pool required. CCTP mints on demand. Third-party lock-and-mint bridges that handle USDC require a pool of pre-deposited USDC on the destination chain, and large transfers can exhaust that pool or incur slippage.
​

For stablecoin transfers specifically, CCTP is generally the preferred infrastructure when available. See also the best cross-chain stablecoin swap infrastructure for a broader comparison of how CCTP fits into the current ecosystem.
​

Intent-based bridges invert the standard model. Instead of the user initiating a lock or burn onchain and waiting for a relayer to respond, the user declares an intent: "I want X tokens on chain B; here is my authorization to spend Y tokens on chain A." Solvers, which are liquidity providers competing for the fill, front the destination-chain tokens from their own inventory immediately. The solver then collects the source-chain funds through a settlement process afterward, often in a batched proof.
​

The result is that users get near-instant finality from the perspective of their destination-chain balance. The solver bears the bridging latency and the inventory cost. The user's experience is fast regardless of the underlying settlement mechanism because the solver is pre-funding the transfer out of pocket.
​

Across Protocol pioneered this design for Ethereum and its rollups. LI.FI operates as an aggregation layer that routes across intent-based and traditional bridges depending on availability and cost. The economic logic is straightforward: solvers participate because they earn a fee on each fill, and competition among solvers keeps fees close to the actual capital cost of the bridge route.
​

Security properties differ from traditional bridges in important ways. The user's funds are not sitting in a vault waiting for an attestation. The solver is the one taking counterparty risk during settlement. If the settlement mechanism fails, the solver loses money rather than the user, assuming the destination-chain transfer already landed. This makes intent bridges more resilient to the vault-draining attacks that have hit lock-and-mint bridges.
​

The tradeoff is that intent bridges require liquid solver networks to function. For large transfers or illiquid routes, no solver may be willing to take the risk, and the route falls back to slower traditional bridging or fails entirely. Solver capital constraints are the practical ceiling on throughput. The full landscape of protocols using this model is covered in this comparison of cross-chain intent protocols. You can also explore how intent-based designs intersect with treasury and payment automation at the best stablecoin automation platforms.
​

Across uses a hub-and-spoke model anchored on Ethereum mainnet. Solvers post capital on each spoke chain and get reimbursed via the Ethereum hub after providing proof of fill. LI.FI abstracts routing across Across, Stargate, CCTP, and canonical rollup bridges, choosing the best route per transfer based on cost, speed, and available liquidity. Both are covered in L2BEAT's bridge risk framework at l2beat.com/bridges.
​

Bridges have been the single largest source of onchain losses in crypto history. The combination of large concentrated TVL, complex multi-chain validator logic, and attack surface spanning two chains simultaneously makes them disproportionately attractive to sophisticated attackers. Three incidents define the threat model that serious bridge designers now build against.
​

Ronin Bridge, March 2022: $625 million. The Ronin bridge secured the Axie Infinity game economy between Ethereum and the Ronin sidechain. It relied on a 5-of-9 multisig validator set. Attackers later attributed to the Lazarus Group compromised five validator keys: four belonging to Sky Mavis and one belonging to the Axie DAO, giving them the threshold needed to forge withdrawal approvals. They drained 173,600 ETH and 25.5 million USDC across two transactions. The hack went undetected for six days. The root failure was key management: a centralized set of private keys, several held by a single organization, controlled access to a vault holding hundreds of millions of dollars.
​

Wormhole Bridge, February 2022: $320 million. Wormhole connects Solana to Ethereum and other chains. An attacker found a vulnerability in the Solana program that verified guardian signatures: a deprecated function still present in the codebase allowed the attacker to bypass signature verification entirely and forge a message claiming a deposit had occurred. The program minted 120,000 wETH on Solana with no corresponding Ethereum deposit. Jump Crypto, a Wormhole backer, injected $320 million in ETH within 24 hours to keep the bridge solvent, but the underlying failure was a code audit gap rather than a key-management failure.
​

Nomad Bridge, August 2022: $190 million. Nomad used an optimistic verification model. During a routine upgrade, a developer initialized a trusted root as zero bytes. This meant any message passing through the system was automatically considered valid, because any bytes trivially match the zero root. Once the first attacker discovered this, the exploit was fully copyable by anyone reading the mempool. Hundreds of addresses drained the bridge within hours in a chaotic free-for-all. The root failure was improper initialization in a contract upgrade path.
​

The pattern across all three: trust assumptions were not backed by adequate security. Validators were too centralized, code audits missed critical logic, and upgrade procedures lacked proper review. Modern bridge designs respond by pushing toward ZK proof verification, distributing validator sets to much larger decentralized groups, and implementing circuit breakers that pause withdrawals if outflows exceed normal velocity. Understanding what trustless means in practice is the foundation for evaluating any bridge's security claims. L2BEAT maintains live risk scores for major bridges at l2beat.com/bridges.
​

USDC exists in two fundamentally different forms on most chains: bridged USDC (sometimes called USDC.e or USDbC) and native USDC. Bridged USDC is a wrapped version created by locking real USDC on Ethereum and minting a synthetic equivalent through a bridge. Native USDC is minted directly by Circle on that chain, backed by Circle's dollar reserves, and redeemable directly with Circle without routing through any bridge contract.
​

The practical implications for builders and users are significant:
​

USDC.e on Arbitrum was the original USDC on that chain, bridged from Ethereum via the canonical Arbitrum bridge. When Circle launched native USDC on Arbitrum via CCTP, two separate ERC-20 tokens began trading under different contract addresses. Protocols that had integrated USDC.e did not automatically upgrade. Liquidity fragmented across pools denominated in each. Some DEXes ran parallel pools, and arbitrageurs keep the prices close but not always identical at every moment.
​

USDbC on Base followed the same pattern. Base launched with bridged USDC from Ethereum. Circle later issued native USDC on Base via CCTP. USDbC remains in circulation and is supported by many Base-native protocols, but Circle's recommendation for new integrations is native USDC.
​

The risk difference matters at the protocol level. USDC.e is only as good as the bridge backing it. If the Arbitrum canonical bridge had a catastrophic failure, USDC.e holders would have impaired claims. Native USDC holders would be unaffected because their recourse is directly to Circle. For treasury management and stablecoin automation, holding native USDC is strictly lower-risk than holding bridged variants. Explore how this distinction affects stablecoin infrastructure decisions at cross-chain stablecoin swap infrastructure.
​

Circle's migration path for protocols is documented at circle.com/cctp. The recommended approach is to update token interfaces to accept native USDC and use CCTP for all new cross-chain transfers, while continuing to accept bridged USDC from legacy integrations until liquidity migrates organically.
​

The four main bridge architectures have distinct tradeoffs across trust, speed, liquidity requirements, token type, and security model. No single type wins on every dimension.
​

Safety depends entirely on the bridge's trust model and audit history. Canonical rollup bridges backed by Ethereum's consensus are the safest option but have slow withdrawals for optimistic rollups. Third-party lock-and-mint bridges have historically been the most exploited infrastructure in crypto. Intent-based bridges and CCTP offer stronger risk profiles for stablecoin transfers. Always check a bridge's risk score on L2BEAT before committing significant funds.
​

If the vault holding locked collateral is drained, wrapped tokens lose their backing and typically approach zero in value. Recovery depends on whether the bridge team or backers inject new capital, as Jump Crypto did for Wormhole in 2022, or whether users can claim through an insurance fund. There is no protocol-level guarantee of recovery, which is why vault risk is the central concern when evaluating any lock-and-mint bridge.
​

The seven-day delay applies specifically to withdrawals from optimistic rollups like Arbitrum One and Optimism back to Ethereum. The delay is the fraud-proof challenge window, giving anyone time to submit evidence of an invalid state transition before the L1 contract releases funds. Deposits from Ethereum to the rollup are fast. ZK rollups have much shorter finality windows because validity proofs replace the challenge period. Read more about optimistic vs ZK rollup mechanics.
​

A bridge moves the same asset between chains: ETH on Ethereum to ETH on Arbitrum. A cross-chain swap moves value between chains and changes the asset in the same transaction, such as USDC on Ethereum to SOL on Solana. Cross-chain swaps typically combine a bridge mechanism with a DEX swap on one or both ends. Aggregators like LI.FI handle both in a single transaction by routing through the most efficient combination of bridge and swap path available at that moment.
​

Most chains have at least one canonical or official bridge, especially L2s and sidechains built to be Ethereum-compatible. Standalone L1s like Solana, Avalanche, and Cosmos chains rely on third-party bridges for Ethereum connectivity. Cosmos chains with IBC support have a native light-client bridge protocol built into the consensus layer. Not all bridges cover all chains, which is why aggregators that route across multiple bridge protocols are useful for obscure or newly launched chain pairs.
​

Related reading