Author: Luo Benben, Former Arbitrum Technical Ambassador & Co-founder of Goplus Security
Introduction
In this continuation of our technical deep dive into Arbitrum One, we explore the components governing cross-chain messaging and censorship-resistant transaction entry points. Building on Part 1, which covered the Sequencer, Validators, Sequencer Inbox, Rollup Blocks, and fraud proofs, we now focus on Delayed Inbox, Retryables, Gateways, and Outbox systems.
Cross-Chain and Bridging Mechanisms
Cross-chain transactions fall into two categories:
- L1 to L2 (Deposits)
- L2 to L1 (Withdrawals)
Unlike traditional bridges relying on third-party validators, Arbitrum's native bridging is structurally secure because L2’s state is derived from L1 data. Rollups aren’t independent chains but "windows" into L1’s ledger, making them "half-chains" anchored to Ethereum.
👉 Explore Arbitrum’s bridging security
Retryable Tickets: Ensuring Reliable Deposits
Retryables are foundational for Arbitrum’s official bridge, handling ETH and ERC-20 deposits:
- Submission on L1: Created via
createRetryableTicket()in the Delayed Inbox. - Automatic Redemption on L2: The Sequencer typically processes tickets automatically.
- Manual Redemption: Required if gas prices spike or auto-redemption fails (must be completed within 7 days).
Key Difference: Withdrawals lack Retryables since L1 lacks automation—users manually claim assets via the Outbox post-challenge period.
ERC-20 Gateway System
Arbitrum’s Gateway architecture solves complex ERC-20 cross-chain challenges:
- Gateway Router: Manages token address mappings (L1 ↔ L2) and token-to-gateway pairs.
- Custom Gateways: Handle specialized tokens (e.g., WETH, rebase tokens).
Example: WETH Cross-Chain
WETH must be unwrapped to ETH before bridging to maintain 1:1 collateralization. The WETH Gateway automates this process, ensuring symmetry between L1 and L2.
Delayed Inbox: Anti-Censorship and Deposits
Functions:
- Processes L1→L2 deposits (e.g.,
depositETH()). - Force Inclusion: Users can bypass Sequencer censorship by submitting transactions directly to Delayed Inbox. After 24 hours,
forceInclusion()ensures transactions are added to Sequencer Inbox.
👉 Learn how force inclusion protects users
Outbox: Managing Withdrawals
Outbox tracks finalized withdrawals post-challenge period:
- Merkle Proofs: Users submit proofs to unlock assets on L1.
- Spent Mapping: Prevents replay attacks by recording processed withdrawals (
spent[uint256]).
ETH Deposit/Withdrawal Flow
ETH Deposit
- Submit via Delayed Inbox (
depositETH()orcreateRetryableTicket()). - Sequencer includes it in L2’s transaction sequence.
ETH Withdrawal
- Initiate on L2 (
withdrawEth()). - After 7 days, claim via L1 Outbox with Merkle proof.
Fast Withdrawals (Third-Party Bridges)
Options:
- Atomic Swaps: Peer-to-peer but liquidity-dependent.
- Witness Bridges: Faster but less secure than native bridges.
Force Inclusion for Censorship Resistance
If the Sequencer ignores a withdrawal:
- Use
inbox.sendL2Message()to bypass Sequencer. - After 24 hours, call
forceInclusion()to force transaction inclusion.
FAQ
Q1: Is Arbitrum’s native bridge safer than third-party bridges?
A: Yes. Native bridges inherit Ethereum’s security, while third-party bridges rely on external validators.
Q2: How long does a forced withdrawal take?
A: 24 hours (force inclusion delay) + 7 days (challenge period).
Q3: Can ERC-20 tokens use Retryables?
A: Yes, via createRetryableTicket() with Gateway integrations.
Q4: What happens if a Retryable expires?
A: Unredeemed tickets after 7 days may result in lost funds or require fee payments to extend.