The canonical bridge, in and out

The trustless route between Ethereum and Robinhood Chain is the canonical Arbitrum bridge. It is two directions with two very different shapes, and the difference is not a detail — it decides how you design around it.

In: about ten minutes

A deposit is a single transaction on Ethereum. ETH goes through the fast path (L1MessageType_ethDeposit) and needs no gas reserved on the other side; ERC-20 deposits go through the token gateway and land as a retryable ticket, which means the L2 leg needs enough gas to complete or it can be redeemed by hand within seven days. Reserving gas is not optional for tokens, and it is the single most common way a deposit appears to vanish — it has not vanished, it is waiting to be redeemed.

The contracts, all of them proxies on L1:

• Inbox 0x1A07cc4B…7a2D
• L1 router 0x6a2E3a1e…75bB
• Outbox 0xf0ce991e…3DE9
• L2 router 0x1E324B93…1B89

Because they are proxies, reading a selector off them means reading the implementation address out of the EIP-1967 slot first. Calling the proxy directly for anything unusual gets you nothing useful.

Out: two stages, and the second one is the hard part

A withdrawal is not one transaction. The first is on L2, and it only initiates. The assets are released on Ethereum later, by presenting a Merkle proof — and that can only happen once the state root containing your withdrawal has been confirmed, which means waiting out the challenge period.

Read from the chain rather than from documentation, that period is 45,818 L1 blocks, about 6.4 days. The commonly quoted "seven days" is the round number, and it is wrong by enough to matter if you are scheduling on it.

The claim itself is mechanical once you have the pieces: take the L2ToL1Tx event to get the position, read the newest confirmed (root, l2BlockHash) pair from the Outbox's SendRootUpdated, pull sendCount from that block, ask NodeInterface at 0xC8 for the proof, and call Outbox.executeTransaction.

Two traps, both of which cost real time to find:

• getAssertion(bytes32) returns createdAtBlock in its third word, not its first. The first is firstChildBlock. Take the wrong one and you will scan a hundred and forty-eight blocks that are all the wrong ones.
• Do not try to work out which block has been confirmed. SendRootUpdated tells you directly.

A note on the RPC

Free endpoints on this chain cap eth_getLogs at a window of roughly two thousand blocks, and confirmations arrive about every half hour, so polling for the event is a loop rather than a single call. Our own bridge page does all of the above in the browser — you can watch it read the chain rather than take our word for it.