Bridging & Settlement

Value moves across the L1↔L2 boundary through a set of contracts that are deliberately split by direction. This module covers deposits (Inbox → retryables), withdrawals (Outbox redemption), and how fraud-proof settlement makes the whole thing safe.

L1 → L2: deposits

A user (or relayer) calls Inbox on L1 with a deposit or a general message. For ETH, createEthDeposit; for arbitrary messages, createRetryableTicket.
The message is committed to the inbox accumulator and becomes a delayed message.
The sequencer's next batch includes the message (marking it afterDelayedMessagesRead), at which point ArbOS turns it into an L2 transaction.
For retryables, execution on L2 is funded by the ticket's escrowed gas budget; failure leaves the ticket redeemable rather than lost (see Execution).

L2 → L1: withdrawals

On L2, a user calls ArbSys.sendTxToL1 (or the token bridge) which emits an outbox message with a Merkle commitment.
The message is included in an assertion (state commitment) posted by stakers to the L1 contracts.
Once the assertion is confirmed — after the challenge period (~8 days on One) or via a successful challenge — the message is finalized.
Anyone calls Outbox on L1 with the Merkle proof to executeTransaction, releasing funds.

Settlement: assertions and the challenge game

The settlement layer is the part most users never see, but it's what gives withdrawals their security:

Stakers post assertions — commitments to the L2 state at a given block, plus the accumulated outbox messages.
If two stakers disagree, they enter a challenge in ChallengeManager. The dispute is resolved by bisection: the two sides repeatedly narrow the disagreement down to a single VM step, then the L1 bridge executes that one step of the Geth-as-WASM machine to decide who's right.
The loser is slashed (their stake is forfeited), and the winner's assertion becomes the canonical state. Faulty assertions can therefore be financially punished, which is what makes "optimistic" settlement sound.

Bridging tokens

The standard token bridge mints/burns an Arbitrum-side representation of an L1 token. On deposit, the L1 token is locked in the bridge and the equivalent is minted on L2; on withdrawal, the L2 token is burned and the L1 token released. Custom bridge designs (e.g. for fast exits or alternative collateral) are built on the same Inbox/Outbox message machinery.

Edge cases

A withdrawal's outbox redemption must be done by someone on L1; it's not automatic. Tools like the Arbitrum bridge UI and the SDK do it for you.
Retryables with an undersized maxSubmissionCost revert at submission — include a buffer, and remember the cost is refundable if the ticket executes successfully.
Token bridges require the L1 token to be ERC-20 standard; non-standard tokens (fee-on-transfer, rebasing) need a custom bridge, not the standard one.
Fast-exit services exist but are custodial — the canonical bridge is always available even if a third-party fast-exit provider disappears.

Interface

solidity

// Inbox — L1 -> L2 message entry.
contract Inbox {
    function createRetryableTicket(
        address to, uint256 l2CallValue, uint256 maxSubmissionCost,
        address excessFeeRefundAddress, address callValueRefundAddress,
        uint256 gasLimit, uint256 maxFeePerGas, bytes calldata data
    ) external payable returns (uint256);
 
    function createEthDeposit(address to) external payable returns (uint256);
 
    function bridge() external view returns (address);
}
 
// Outbox — where finalized L2 -> L1 messages are redeemed on L1.
contract Outbox {
    function executeTransaction(
        bytes32[] calldata proof,
        uint256 index,
        address l2Sender,
        address to,
        uint256 l2Block,
        uint256 l1Block,
        uint256 l2Timestamp,
        uint256 value,
        bytes calldata data
    ) external;
}

STATUSinterface