Bridging

Taiko's bridge enables trust-minimized asset transfers and message passing between Ethereum (L1) and Taiko (L2). The bridge uses Merkle proofs and synchronized world state roots to verify cross-chain messages, requiring no trusted third party. Any contract or user can send and verify messages between chains.

Architecture Overview

The bridge system consists of three layers:

Signal Service

The Signal Service is the foundation of cross-chain communication. It is deployed on both L1 and L2 and provides two core operations:

Sending a signal. Any contract or user calls sendSignal(message) to store a message in the Signal Service's contract storage. The message is persisted as a storage slot value, which becomes part of the chain's state trie.

Verifying a signal. On the destination chain, anyone can call verifySignalReceived(message, proof) with a Merkle proof demonstrating that the signal was stored on the source chain. The Signal Service reconstructs the Merkle root using the provided sibling hashes and verifies it against the stored world state root of the source chain.

How State Roots Stay in Sync

• L1 state on L2. Every L2 block includes an anchor transaction that stores the corresponding L1 world state root in the L2 Anchor contract. This happens automatically as part of block construction.
• L2 state on L1. When a proposal range is proved on L1 (which finalizes it under Shasta), Inbox writes a checkpoint into the L1 Signal Service committing to the finalized L2 state. There is no separate "verify later" step.

This bidirectional state synchronization enables Merkle proofs to be verified in both directions.

Bridge Contract

The Bridge contract provides the user-facing interface for cross-chain transfers. It handles message lifecycle management including sending, processing, retrying, and recalling messages.

Message Lifecycle

A bridge message transitions through the following states:

Sending a Message (Source Chain)

1. The user calls sendMessage on the Bridge contract (or sendToken on a token vault).
2. The Bridge contract locks ETH or tokens.
3. The Bridge contract calls sendSignal on the Signal Service to record the message.
4. A MessageSent event is emitted.

Processing a Message (Destination Chain)

1. A relayer (or the user) retrieves the Merkle proof for the message using eth_getProof on the source chain.
2. The relayer calls processMessage on the destination chain's Bridge contract, providing the message and its proof.
3. The Bridge contract verifies the proof via the Signal Service.
4. If valid, the bridge releases assets to the recipient and marks the message as DONE.

Token Bridging

How Token Vaults Work

Taiko uses a vault system for token bridging. There are three vault contracts, one for each token standard:

Bridging Tokens to the Destination Chain

1. The user calls sendToken on the appropriate vault on the source chain.
2. The vault locks the tokens and creates a bridge message via the Bridge contract.
3. On the destination chain, the message is processed and a BridgedERC contract mints the equivalent tokens.

Bridging Tokens Back to the Canonical Chain

1. The user calls sendToken on the BridgedERC contract on the destination chain.
2. The bridged tokens are burned.
3. On the canonical chain, the original vault releases the locked tokens back to the user.

ETH Bridging

ETH transfers work through the Bridge contract directly:

• Direct transfer: Call sendMessage on the Bridge with ETH attached.
• With token transfer: Call sendToken on a token vault with ETH included as part of the transaction value.

L1 to L2 vs. L2 to L1

The bridging flow differs in timing depending on the direction:

Message Claiming: Automatic vs. Manual

Bridge messages can be claimed in two ways:

Automatic (via relayer). A relayer monitors for bridge messages and submits the Merkle proof on the destination chain automatically. The relayer earns a processing fee (set by the user when sending the message) as compensation for the gas cost.

Manual (by the user). The user retrieves the proof themselves and calls processMessage directly on the destination chain. No processing fee is required, but the user must pay the destination chain gas cost.

Summary