Bridging from a parent chain to a child chain

Looking for implementation guides?

This document explains the protocol-level concepts of parent-to-child messaging. For practical, step-by-step instructions on implementing bridging and messaging, see How to bridge from parent chain to child chain.

In the Bypassing the Sequencer section, we introduced an alternative way for users to submit transactions to a child chain by going through the parent chain's Delayed Inbox contract instead of sending them directly to the Sequencer. This approach is one example of a parent-to-child messaging path. More broadly, parent-to-child chain messaging covers all ways to:

• Submit child chain bound transaction from a parent chain
• Deposit ETH or native tokens from a parent chain to a child chain
• Send arbitrary data or instructions from a parent chain to a child chain

We generally categorize these parent-to-child chain messaging methods as follows:

1. Native token bridging: Refers to depositing a child chain's native token from the parent chain to the child chain. Depending on the type of Arbitrum chain, this can include:

• ETH Bridging: For Arbitrum chains that use ETH as their gas token, users can deposit ETH onto a child chain via the Delayed Inbox.
• Custom gas token bridging: For Arbitrum chains that use a custom gas token, users can deposit that chain's native token to a child chain using the same mechanism.

2. Transaction via the Delayed Inbox: As described in the Bypassing the Sequencer section, this method allows users to send transactions through the parent chain. It includes two sub-types of messages:

• Unsigned messages: General arbitrary data or function calls
• Signed messages: Messages that include a signature, enabling certain authenticated actions

3. Retryable tickets are Arbitrum's canonical mechanism for creating parent-to-child messages–transactions initiated on a parent chain that trigger execution on a child chain. This method contains the following functionality:

• General retryable messaging: For sending arbitrary data or calls from a parent-to-child chain.
• Customized feature messaging (e.g., token bridging): Leveraging retryable tickets (and other messaging constructs) for specialized actions, such as bridging tokens from a parent-to-child chain.

This section will explore these categories in detail and explain how they work. The diagram below illustrates the various paths available for parent-to-child chain communication and asset transfers.

Native token bridging

Native token bridging refers to depositing a chain's native currency (the token used to pay gas fees) from the parent chain to the child chain. This follows a different, simpler process than ERC-20 token bridging through the canonical token bridge.

Arbitrum chains can use ETH or any other ERC-20 tokens as their gas fee currency. Arbitrum One and Nova use ETH as their native token, while some Arbitrum chains opt for a custom gas token. For more details about chains that use custom gas tokens, refer to the Custom gas token SDK.

Whether a chain uses ETH or a custom gas token, users can deposit the token from a parent chain (for Arbitrum One, it is Ethereum) to a child chain. Below, we describe how to deposit ETH on chains that use ETH as the native gas token. The process for depositing custom gas tokens follows the same steps, except it uses the chain's Delayed Inbox contract.

Depositing native tokens

A special message type exists for simple native token deposits from parent-to-child chains. The Inbox contract's depositEth method provides this functionality for chains using ETH, while custom gas token chains use similar mechanisms through their Delayed Inbox contract.

For step-by-step instructions on depositing native tokens, see How to bridge from parent chain.

How deposits work

When you call Inbox.depositEth, the ETH is sent to the bridge contract on the parent chain. The bridge then "credits" the deposited amount to the designated address on the child chain. From the L1 perspective, the funds are held in Arbitrum’s bridge contract on your behalf.

A diagram illustrating this deposit process is below:

Note on caller type and aliasing:

• If the parent chain caller is an Externally Owned Account (EOA):
  • The deposited ETH will appear in the same EOA address on the child chain.
• If the parent chain caller is a contract:
  • The ETH will be deposited to the contract's aliased address on the child chain. In the next section, we will cover Address aliasing.
• If the caller is a 7702-enabled account (EOA with temporary contract code):
  • The ETH goes to the aliased address, similar to contracts. This is due to the presence of runtime code during execution, and ensures consistent aliasing behavior post-EIP-7702.

Address aliasing

All unsigned messages submitted through the Delayed Inbox have their sender addresses "aliased" when executed on the child chain. Instead of returning the parent chain sender's address as msg.sender, the child chain sees the "child alias" of that address. Formally, the child alias calculation is:

Child_Alias = Parent_Contract_Address + 0x1111000000000000000000000000000000001111

Why aliasing?

Address aliasing in Arbitrum is a security measure that prevents cross-chain exploits. Without it, a malicious actor could impersonate a contract on a child chain by simply sending a message from that contract's parent chain address. By introducing an offset, Arbitrum ensures that child chain contracts can distinguish between parent-chain contract calls and those from child chain native addresses.

Computing the original parent chain address

If you need to recover the original parent chain address from an aliased child chain address onchain, you can use Arbitrum's AddressAliasHelper library. This library allows you to translate between the aliased child address and the original parent address in your contract logic.

modifier onlyFromMyL1Contract() override {
    require(AddressAliasHelper.undoL1ToL2Alias(msg.sender) == myL1ContractAddress, "ONLY_COUNTERPART_CONTRACT");
    _;
}

Transacting via the Delayed Inbox

Arbitrum provides a Delayed Inbox contract on the parent chain that can deliver arbitrary messages to the child chain. This functionality is important for two reasons:

1. General cross-chain messaging: Allows parent chain EOAs or parent chain contracts to send messages or transactions to a child chain. This functionality is critical for bridging assets (other than the chain's native token) and performing cross-chain operations.
2. Censorship resistance: It ensures the Arbitrum chain remains censorship-resistant, even if the Sequencer misbehaves or excludes certain transactions; refer to Bypassing the Sequencer for more details.

Users can send child chain transactions through the Delayed Inbox in two primary ways:

1. General child chain messaging
2. Retryable tickets

General child chain messaging

Any message sent via the Delayed Inbox can ultimately produce a transaction on the child chain. These messages may or may not include a signature.

• Signed messages: Signed by an EOA on the parent chain. This signature proves the sender is an EOA rather than a contract, preventing certain cross-chain exploits and bypassing the need for aliasing.
• Unsigned messages: These do not include a signature from an EOA. For security reasons, the sender's address on the child chain must be aliased when the message gets executed; see the Address aliasing section for details.

Below, we describe the Delayed Inbox methods for each scenario.

Signed messages

Signed messages let a parent chain EOA prove ownership of an address, ensuring the child chain transaction will execute with msg.sender equal to the signer's address on the child chain (rather than an alias). This mechanism is beneficial for bypassing the Sequencer if:

• You want to force-include a transaction on a child chain in case of Sequencer downtime or censorship.
• You need an operation on a child chain that explicitly requires EOA authorization (e.g., a withdrawal).

When submitting through the Delayed Inbox, a child chain transaction signature gets included in the message's calldata. Because it matches the EOA's signature, the child chain can safely treat the signer's address as the sender.

The Delayed Inbox provides two methods for signed messages: sendL2Message (more flexible, can be called by EOAs or contracts) and sendL2MessageFromOrigin (cheaper gas costs, EOA-only). For implementation details, see Sending signed messages.

Unsigned messages

Unsigned messages allow a parent chain sender to specify transaction parameters without an EOA signature. Because there is no signature, the sender's address must be aliased on the child chain (see the Address aliasing section for the rationale).

The Delayed Inbox provides methods for unsigned messages from both EOAs and contracts, with variants for whether funds are transferred from the parent chain or drawn from the child chain balance. For implementation details and method signatures, see Sending unsigned messages.

Messages types

Arbitrum Nitro defines various message types to distinguish between the categories described above (signed vs. unsigned, EOAs vs. contracts, etc.). These message types help the protocol route and process each incoming message securely.

You can find additional details on message types in the next section of this documentation.

note

Please refer to the Address aliasing discussion for more background on address aliasing. This mechanism ensures that a parent chain contract can't impersonate a child chain address unless it provides a valid signature as an EOA.

Retryable tickets

Retryable tickets are Arbitrum's canonical method for creating parent-to-child chain messages—parent-chain transactions that initiate a message to be executed on a child chain. A retryable is submittable for a fixed cost (dependent only on its calldata size) paid at the parent chain. Critically, the ticket's submission on the parent chain is separable and asynchronous from its execution on the child chain. This design provides atomicity between the cross-chain operations: if the parent chain transaction to request submission succeeds (does not revert), then the execution of the retryable on the child chain has a strong guarantee to eventually succeed.

For step-by-step instructions on creating retryable tickets, including parameter estimation and SDK usage, see Creating retryable tickets.

Retryable ticket lifecycle

The lifecycle of a retryable ticket involves three stages: submission, automatic redemption, and manual redemption.

Submission

Creating a retryable ticket is initiated with a call to the createRetryableTicket function of the inbox contract. Key parameters include the destination address, call value, gas limits, refund addresses, and calldata. The ticket requires sufficient funds to cover both submission costs and gas for child chain execution. Upon successful submission, a unique TicketID is created and the ArbRetryableTx precompile emits a TicketCreated event.

Automatic redemption

Upon successful ticket creation, the system checks if conditions are met for automatic redemption: the user's child chain balance must cover the gas costs, and the provided maxFeePerGas must meet or exceed the child chain base fee. If these conditions are met, the system automatically attempts to execute the ticket (auto-redeem).

If auto-redemption succeeds, the ticket executes immediately with the original parameters, and excess fees are refunded. If auto-redemption fails (for example, due to insufficient gas or an increase in gas prices), the ticket remains in the retryable buffer for up to one week, allowing for manual redemption.

Manual redemption

If automatic redemption fails, anyone can manually redeem the ticket by calling the ArbRetryableTx precompile's redeem method. The manual redemption attempt donates its call gas to the execution, and the gas limit is not constrained by the original ticket parameters. This allows tickets to be retried with different gas conditions.

Tickets remain in the retryable buffer for one week. If not successfully redeemed within this period, the ticket expires and is automatically discarded. However, tickets can be kept alive indefinitely by paying a fee to extend the lifetime for another full period before expiration.

If a ticket expires without successful redemption, the escrowed callValue is refunded to the callValueRefundAddress specified during submission. This protects user funds even if execution never succeeds.

Receipt types

Retryable tickets produce two types of receipts:

• Ticket creation receipt: Confirms successful ticket creation and includes a TicketCreated event with the ticketId
• Redeem attempt receipt: Records each redemption attempt and includes a RedeemScheduled event

Only one successful redemption can occur per ticket. Multiple failed redemption attempts will each produce a receipt until one succeeds.

Token bridging

Retryable tickets power Arbitrum's canonical token bridge. For the full token bridge architecture, including how ETH and ERC-20 tokens are bridged between layers, see the Token bridging overview.