If CCIP is the generalised default, native bridges are the specialised counterpart. Each major Layer 2 ships with its own canonical bridge to Ethereum mainnet, operated by the L2's foundation, optimised for the specific chain pair, and woven into the L2's security model. Where they apply, they are cheaper, faster, and better-resourced than any generalised messaging protocol. Where they do not apply, they are unusable. This part covers what native bridges do, where they fit in the institutional mix, and the optimistic-rollup withdrawal mechanic that is the most important footnote in the category.

Each chain ships with its own bridge

The canonical bridge for an L2 is the bridge operated by the L2's own team. Base bridge is operated by Coinbase. Arbitrum bridge by Offchain Labs. Optimism bridge by the Optimism Foundation. Polygon bridge by Polygon Labs. The Avalanche bridge for Ethereum-Avalanche traffic by Ava Labs and the supporting validator set.

Each is purpose-built for the chain pair it serves. The Base bridge knows about Base's sequencer, state-root posting cadence to Ethereum, and settlement guarantees. It does not work for Base-to-Polygon traffic; that is not its job. The trade-off is the inverse of CCIP's: native bridges are narrower in scope and richer in chain-specific integration. They are part of the L2's protocol stack rather than a layer on top of it.

The funding model matters too. The L2 foundations are well-resourced operators with strong incentives to keep the canonical bridge secure: it is the front door for liquidity into their chain, and a canonical-bridge exploit is an existential event for the L2 itself. A generalised bridge operator, by contrast, runs many chain pairs and bounds its exposure on any single pair to that pair's volume.

What they do well

Cheap. A Base-to-Ethereum bridge transaction costs cents on the Base side and standard Ethereum gas on the mainnet side, with no protocol fee on top. The economic model is the L2 economics, not a separate fee layer.

Fast in the deposit direction. Moving assets from Ethereum mainnet into the L2 typically settles in minutes. The mainnet transaction is included, the L2 sequencer observes it, and the corresponding L2 balance is credited. There is no second verification network adding latency; the L2's own consensus is the authority on its side.

Tightly integrated with the L2 security model. A canonical bridge operates inside the same trust assumptions the L2 itself operates under. If the institutional decision has already accepted the L2 as a settlement venue (which it has, by definition, if assets are being held there), the marginal trust assumption from using the canonical bridge is small. There is no third-party messaging network whose failure introduces a new risk vector.

For institutional flows that move assets within an issuer's own chain footprint, between mainnet and the L2 the issuer has chosen, native bridges are the right answer. JPMD on Base interacting with Ethereum-side liquidity uses Base bridge by default. MONY extending to Base when that integration arrives will use Base bridge for issuer-controlled rebalancing.

Where they break down

Chain-pair specific. A Base bridge moves assets between Base and Ethereum mainnet. It does not move assets between Base and Polygon, or between Base and Arbitrum. Each pair needs its own bridge or a generalised mechanism to fall back on. For an institutional product that needs to span more than two chains, the matrix of native bridges is unmaintainable. CCIP exists in part because no one wants to integrate twelve different bridges with twelve different APIs and twelve different security profiles.

Optimistic-rollup withdrawals are slow by design. This is the biggest operational footnote in the category and the one most commonly underestimated. Optimistic rollups (Base, Arbitrum, Optimism) settle to Ethereum through a fraud-proof mechanism: state roots are posted to mainnet, and a challenge window opens during which any party can submit evidence that the posted state is wrong. If no challenge succeeds, the state finalises. The standard challenge window is seven days.

For the deposit direction (Ethereum to L2), this does not matter. The L2 sequencer can credit the balance immediately because the L2 controls its own state. For the withdrawal direction (L2 to Ethereum), it is the binding constraint. A canonical-bridge withdrawal from Base to Ethereum takes seven days, because the mainnet contract will not release the asset until the challenge window has passed without successful challenge.

The seven-day delay is the security feature, not a bug. Removing it would weaken the rollup's security guarantee. It is also why a class of intermediary services (fast-withdrawal providers, intent solvers) exists: they front the user the destination-chain balance immediately, take the seven-day risk themselves, and unwind when the canonical withdrawal completes. Across, covered in Part 4, is the most prominent example.

For an institutional flow, the seven-day window has to be priced. Either the operation is structured so the delay is acceptable (treasury rebalancing on a weekly cadence is fine), or a fast-withdrawal layer is used and the counterparty risk is taken consciously. There is no protocol-level workaround.

Each bridge has its own security assumptions. Base bridge inherits Base's security model. Arbitrum bridge inherits Arbitrum's. The Avalanche bridge has historically relied on a permissioned validator set with its own incident history. A counterparty that uses multiple L2s does separate diligence on each native bridge, because the security profiles do not transfer. CCIP unifies this surface; native bridges fragment it.

Where they fit in the mix

Native bridges are the right answer for high-volume traffic on a single chain pair, where the issuer controls both ends and the operational frequency justifies the integration cost. They are not a substitute for a generalised mechanism when the chain footprint is wider, when the counterparty does not control both ends, or when the cross-chain operation needs to carry a programmable payload (which the canonical bridges generally do not support natively). The institutional pattern, made explicit in Part 5, is to use native bridges for the cases they were built for and CCIP everywhere else.