An overview of the fundamental technical and operational models for transferring assets between a Layer-1 blockchain and its Layer-2 scaling solution.
LABS
Guides
Comparing Native Bridges vs. Third-Party Bridges for Layer-2s
An architectural and security analysis of cross-chain bridging solutions for Ethereum Layer-2 rollups and sidechains.
Chainscore © 2025
core-concepts
Core Concepts and Definitions
01
Native Bridge
A canonical bridge is built and maintained directly by the core development team of the Layer-2 network. It is the official, trust-minimized pathway for moving assets to and from the base layer.
- Direct Integration: Embedded into the L2's protocol and security model.
- Official Mint/Burn: Locks assets on L1 to mint a 1:1 representation on L2, and burns to withdraw.
- Example: Arbitrum's bridge to Ethereum, or Optimism's Standard Bridge.
- User Impact: Offers the highest security guarantee as it's sanctioned by the L2, but can be slower and more expensive for withdrawals due to built-in challenge periods.
02
Third-Party Bridge
Also known as an external or alternative bridge, this is built by an independent entity, not the L2's core team. It provides an alternative route for cross-chain asset transfers, often focusing on speed or cost.
-
Independent Operation: Runs on its own smart contracts and economic security model.
-
Liquidity-Based: Often uses pooled liquidity or wrapped assets to facilitate instant transfers.
-
Example: Across Protocol, Hop Protocol, or Stargate.
-
User Impact: Can enable faster, cheaper withdrawals and connect multiple L2s, but introduces trust in the third-party's security and solvency.
03
Security Model
The fundamental trust assumptions and mechanisms that secure the bridge and user funds. This is the primary differentiator between bridge types.
-
Native Security: Inherits security from the underlying L1 via fraud proofs or validity proofs (ZK).
-
Third-Party Security: Relies on its own validator set, multi-sigs, or economic bonding, which can vary in decentralization.
-
Risk Profile: Native bridges have L1-level security for withdrawals; third-party bridges carry additional smart contract and custodian risk.
-
Why it Matters: Directly impacts the safety of bridged assets and the recovery options in case of failure.
04
Withdrawal Speed & Cost
The time and transaction fees required to move assets from the Layer-2 back to the base Layer-1. This is a major user experience differentiator.
-
Native Delay: Has a built-in challenge period (e.g., 7 days for Optimistic Rollups) for security, making withdrawals slow.
-
Third-Party Speed: Often provides instant withdrawals by providing immediate liquidity from a pool on L1, for a fee.
-
Cost Trade-off: Paying for speed with a third-party often costs more than the base gas fee for a slow, native withdrawal.
-
Use Case: Traders needing quick liquidity opt for third-party bridges, while long-term holders may use the native route.
05
Liquidity & Composability
Refers to the availability of assets on the destination chain and how easily they can be used within its ecosystem after bridging.
-
Native Tokens: Bridging via the canonical route typically mints the official, canonical version of the asset (e.g., "Arb ETH"), which is natively supported by all DeFi apps.
-
Wrapped Tokens: Third-party bridges often issue a wrapped representation (e.g., "USDC.e"), which may not be accepted by all protocols.
-
Fragmentation Risk: Multiple bridge versions of the same asset can split liquidity.
-
Why it Matters: Affects where you can use your assets immediately after the bridge transfer is complete.
06
Interoperability Scope
The range of networks and assets a bridge can connect. Native bridges are typically point-to-point, while third-party solutions are often multi-chain.
-
Point-to-Point: A native bridge usually connects only its specific L2 to its parent L1 (e.g., zkSync to Ethereum).
-
Hub-and-Spoke: Many third-party bridges act as hubs, connecting Ethereum to multiple L2s and even other L1s in a single transaction.
-
Example Use Case: Using Hop Protocol to bridge USDC from Arbitrum to Optimism without going back to Ethereum mainnet.
-
User Benefit: Enables efficient asset movement and liquidity routing across the entire multi-chain ecosystem.
Architectural and Trust Comparison
Comparing Native Bridges vs. Third-Party Bridges for Layer-2s
| Feature | Native Bridge (e.g., Arbitrum L1↔L2) | Third-Party Bridge (e.g., Hop, Across) | Hybrid Approach (e.g., Optimism's Superchain) |
|---|---|---|---|
Trust Model | Inherits security from L1 via canonical messaging | Relies on external validator set or liquidity pool | Combines native security with third-party fast exit liquidity |
Withdrawal Time (Avg.) | 7 days (Arbitrum challenge period) | ~5-15 minutes | ~5-15 minutes for fast exits, 7 days for canonical |
Architecture | Single, protocol-defined smart contract on L1 | Multi-chain liquidity pools with relayers | Native bridge with integrated third-party fast lane |
Security Assumption | L1 is secure; inherits full L1 finality | Economic security of bonded relayers/validators | L1 security for finality, plus economic security for speed |
Capital Efficiency | High (no locked liquidity for withdrawals) | Lower (requires substantial locked liquidity in pools) | Moderate (liquidity only needed for fast lane) |
Sovereignty | Full control by L2 core devs/DAO | Governed by independent bridge protocol DAO | Shared governance between L2 and bridge protocol |
User Cost | ~$5-15 (L1 gas for proving) | ~$0.50-2 (L2 gas + protocol fee) | ~$0.50-2 for fast exit, ~$5-15 for canonical |
Example | Arbitrum's EthBridge, zkSync's L1↔L2 Contract | Hop Protocol, Across Protocol | Optimism's Superchain with Across integration |
How a Native Rollup Bridge Works
Process overview comparing the architecture and user flow of a native bridge, built by the Layer-2 (L2) team, versus third-party bridges.
1
Step 1: Initiate Deposit on the Native Bridge
User locks assets in the official L1 smart contract.
Detailed Instructions
The user begins the bridging process by connecting their wallet (e.g., MetaMask) to the native bridge's official frontend, such as the Optimism Gateway or Arbitrum Bridge. They select the asset (e.g., 10 ETH) and the destination L2 network. Upon confirmation, the bridge's canonical L1 deposit contract (e.g., 0x8315177aB297bA92A06054cE80a67Ed4DBd7ed3a for Arbitrum) is invoked. This contract securely locks the user's assets on Ethereum mainnet (L1).
- Sub-step 1: Transaction Submission: The user signs and submits a transaction to the L1 deposit contract. This transaction includes critical data like the destination L2 address (
0xUserAddress) and the exact deposit amount. - Sub-step 2: Event Emission: The deposit contract emits a standardized event (e.g., a
DepositInitiatedevent) containing all deposit details. This event is the primary message for the L2. - Sub-step 3: Transaction Finality: The user waits for L1 block confirmations (typically 12+ blocks for security) to ensure the deposit transaction is irreversible.
Tip: Always verify you are on the official bridge URL to avoid phishing scams. The native bridge is the only way to mint canonical, protocol-backed assets on the L2.
2
Step 2: L2 Validator Observes and Proves the Deposit
The L2's infrastructure reads the L1 event and proves its validity.
Detailed Instructions
The L2 Sequencer or Validator node continuously monitors the L1 deposit contract for new events. This is a core component of the native bridge's trust-minimized architecture. When the DepositInitiated event is detected, the validator must cryptographically prove its inclusion and validity to the L2 state. This is done using Merkle proofs or by verifying the L1 block header.
- Sub-step 1: Event Polling: The validator's
inboxorbridgewatcher service queries an Ethereum RPC (e.g.,eth_getLogs) for new logs from the deposit contract address. - Sub-step 2: Proof Generation: For a fraud-proof or validity-proof based rollup, the validator generates a proof that the event is part of the canonical L1 chain. In Optimistic Rollups, this data is posted to the
CanonicalTransactionChain. - Sub-step 3: State Update Preparation: The validator packages the deposit information into an L2 transaction format, preparing to credit the user's L2 address. The command to replay this on a node might look like:
rollup-node process-deposit --tx-hash 0xabc123.
Tip: This step highlights the key difference from third-party bridges, which rely on their own validator sets and liquidity pools, not direct L1 state proofs.
3
Step 3: Mint Canonical Assets on the L2
The L2 protocol mints a 1:1 representative token for the user.
Detailed Instructions
After the deposit is validated, the L2 protocol itself mints the corresponding asset in the user's wallet. This minted token is the canonical, protocol-guaranteed representation of the locked L1 asset (e.g., "Optimism ETH" or "Arbitrum ETH"). It is not a wrapped token from a third-party bridge. The minting is executed as a special system transaction that updates the L2's native balance mapping.
- Sub-step 1: Balance Update: The L2's state transition function processes the validated deposit data. It directly increments the balance for the user's address in the L2 state tree.
- Sub-step 2: Token Standard: For ERC-20 assets, the minted token on L2 is typically the standard bridge contract (e.g., the
L2StandardERC20at0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000on Optimism). This contract is pre-deployed and managed by the L2 team. - Sub-step 3: User Notification: The user sees their balance update in their L2 wallet (e.g., in MetaMask switched to the Optimism network). The entire process from L1 tx finality usually takes 10-30 minutes for Optimistic Rollups.
Tip: Canonical assets are required for interacting with core L2 protocols (e.g., staking, governance) and are the only assets that can be withdrawn directly back to L1 via the native bridge.
4
Step 4: Withdraw Assets Back to L1 via the Challenge Period
Initiating and finalizing a withdrawal, a key differentiator from third-party bridges.
Detailed Instructions
To move assets back to L1, the user initiates a withdrawal on the L2. For Optimistic Rollups, this triggers a 7-day challenge period (e.g., Arbitrum and Optimism standard), which is the main latency differentiator from instant third-party bridges. During this time, anyone can submit fraud proofs if the withdrawal is invalid.
- Sub-step 1: Burn on L2: The user sends a transaction to the L2's bridge contract to "burn" or destroy their canonical assets. This transaction emits a
WithdrawalInitiatedevent on L2. - Sub-step 2: Wait for Challenge Period: The user must wait for the full challenge window (e.g., 7 days or 45818 blocks on Optimism) to pass without a successful fraud challenge. This ensures the L2 state is finalized.
- Sub-step 3: Prove and Finalize on L1: After the window, the user (or a relayer) submits a finalization transaction to the L1 bridge contract. This transaction includes a Merkle proof (generated via an SDK) that proves the burn occurred in a finalized L2 block. A sample CLI command might be:
bridge-cli finalize-withdrawal --l2-tx-hash 0xdef456. - Sub-step 4: Claim on L1: Upon successful proof verification, the L1 contract releases the originally locked assets to the user's L1 address.
Tip: Third-party bridges offer faster withdrawals (minutes) by providing immediate liquidity from their own pools, but they introduce counter-party risk and often charge higher fees for the service.
Third-Party Bridge Design Models
Understanding Bridge Basics
A bridge is a tool that lets you move your crypto assets, like tokens, between different blockchains. Think of it like a ferry connecting two islands. Native bridges are the official ferries built and operated by the Layer-2 (L2) network itself, such as Arbitrum's bridge to Ethereum. Third-party bridges are independent ferry services, like Across or Hop Protocol, that connect many different chains.
Key Differences
- Control & Trust: Native bridges are managed by the L2 team, so you must trust their security. Third-party bridges rely on their own security models, which can involve external validators or cryptographic proofs.
- Speed & Cost: Native bridges often have longer withdrawal times (e.g., 7 days for optimistic rollups) but may have lower fees. Third-party bridges use liquidity pools to offer near-instant transfers, sometimes at a higher cost.
- Flexibility: A third-party bridge like Synapse Protocol can connect you to dozens of chains from one interface, while a native bridge typically only connects to its parent chain (like Optimism to Ethereum).
When to Use Which?
Use a native bridge for large, non-urgent transfers to the official chain where security is paramount. Use a third-party bridge for fast, multi-chain swaps or when moving assets between two different L2s directly.
Security and Risk Analysis
Comparison of security attributes for bridging solutions to Layer-2 networks.
| Feature | Native Bridge | Third-Party Bridge (e.g., Hop, Across) | Third-Party Bridge (e.g., cBridge, Synapse) |
|---|---|---|---|
Custody Model | Non-custodial (user-controlled keys) | Mixed (some custodial, some MPC-based) | Decentralized Validator Set with Staking |
Time to Finality | ~7 days (Ethereum L1 challenge period) | ~1-30 minutes (optimistic attestations) | ~5-15 minutes (light client verification) |
Audit Status | Audited by OpenZeppelin, Trail of Bits | Audited by CertiK, Quantstamp | Audited by Halborn, ConsenSys Diligence |
Smart Contract Risk | High (complex, large attack surface) | Medium (modular, but often newer code) | Medium-High (complex cross-chain messaging) |
Validator/Relayer Decentralization | High (secured by L1 consensus) | Low-Moderate (limited operator sets) | Moderate (permissioned validator network) |
Economic Security (TVL Slashable) | $30B+ (Ethereum stake securing rollups) | $50M - $200M (bridge-specific pools) | $100M - $500M (staked by validators) |
Proven Hack History | Zero major native bridge hacks | Multiple (e.g., Wormhole $325M, Nomad $190M) | Limited (targeted exploits <$10M total) |
Upgrade Mechanism | Timelock + DAO governance (slow) | Multisig (3/5 to 5/8 signers) | DAO + Multisig (hybrid, faster execution) |
FAQ and Decision Framework
The security model is the fundamental distinction. Native bridges, like Arbitrum's and Optimism's official bridges, are secured by the Layer-2's own validation mechanism (e.g., fraud proofs or validity proofs), making them canonical and inheriting the L1's security assumptions. Third-party bridges, such as Hop Protocol or Across, rely on their own external validator sets, multi-signature schemes, or liquidity pools, which introduce separate trust assumptions. For example, a third-party bridge might use a federation of 8-of-15 multisig signers, whereas a native bridge's withdrawal is ultimately guaranteed by Ethereum's L1 consensus. The Wormhole bridge hack in 2022, resulting in a $325 million loss, exemplifies the risks of external validator compromise, a vector less relevant for canonical bridges.