Child to parent chain messaging

Looking for implementation guides?

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

Arbitrum's outbox system allows for arbitrary child chain to parent chain contract calls, i.e., messages initiated from the child chain, which eventually resolve in execution on the parent chain. Child-to-parent chain messages (aka "outgoing" messages) bear some things in common with Arbitrum's parent chain to child chain messages, which are "in reverse" though with differences, which we'll explore in this section.

Protocol flow

Messages from child to parent are included in Arbitrum's Rollup state and finalized through the Rollup Protocol. The process follows these steps:

1. Message creation on child chain:
   • To initiate a child-to-parent chain message, a user or contract calls the sendTxToL1 method on the ArbSys precompile.
2. Message inclusion in an assertion:
   • The message is batched with other transactions and included in a Rollup assertion.
   • Assertions are submitted to the Rollup contract on the parent chain and enter the dispute window (~one week).
3. Assertion confirmation:
   • If the assertion remains unchallenged after the dispute window, the Rollup contract finalizes the assertion.
   • The assertion's Merkle root gets posted to the outbox contract on the parent chain.
4. Execution on the parent chain:
   • Once the assertion is confirmed, anyone can execute the message on the parent chain by proving its inclusion.
   • Execution is possible using Outbox.executeTransaction, which takes a Merkle proof proving the message exists in the finalized assertion.

Sending and executing messages

Child-to-parent messages are sent via the ArbSys precompile's sendTxToL1 method. After the ~7 day challenge period, messages can be executed on the parent chain using the Outbox.executeTransaction method with a Merkle proof obtained from the NodeInterface contract.

For step-by-step implementation instructions, see How to bridge to parent chain.

Protocol design details

Constant overhead for node confirmation

• Calling confirmNode on the Rollup contract has constant gas overhead, regardless of the number of messages in the assertion.
• This confirmation ensures malicious actors cannot grief the network by submitting assertions with many outgoing messages.

Why child to parent chain messages require manual execution

Unlike retryable tickets, which can execute automatically with pre-funded gas, child-to-parent chain message must undergo manual execution because Ethereum (parent chain) does not support scheduled execution.

However, applications can implement execution markets that allow third parties to execute messages for a fee.

Persistence and expiry

• Child-to-parent chain messages: - Persist indefinitely on the parent chain once included in the outbox.

Parent-to-child chain message lifecycle

Each message progresses through three primary states:

Stage	Description
Posted on child chain	The message is sent via ArbSys.sendTxToL1.
Waiting for finalization	The assertion containing the message is in the challenge period (~6.4 days)
Confirmed and executable on the parent chain	If no fraud proof is submitted, the assertion is confirmed, and the message is available for execution in the outbox.

Asset withdrawals

ETH withdrawals

The ArbSys precompile provides a withdrawEth convenience method for withdrawing ETH from the child chain. This method burns the ETH on the child chain and creates a child-to-parent message. Like all child-to-parent messages, it requires execution on the parent chain after the challenge period via Outbox.executeTransaction.

For implementation details, see Withdrawing ETH.

ERC-20 token withdrawals

Token withdrawals use Arbitrum's canonical bridge architecture, detailed in the Token bridging overview. The process flows through the L2GatewayRouter to the appropriate gateway contract (L2ArbitrumGateway), which burns the child chain tokens and creates a message to the parent chain gateway. After the challenge period, the message can be executed on the parent chain to release tokens from escrow.

For implementation details, see Withdrawing ERC-20 tokens.