--- title: "Bridging Assets To and From Robinhood Chain" type: concept tags: [bridging, canonical-bridge, withdrawals, arbitrum, l2] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-bridging-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-contracts-robinhood-chain-documentation.md", "raw/web_community-transaction-finality-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-terms-of-service-robinhood-chain-documentati.md"] confidence: medium --- # Bridging Assets To and From Robinhood Chain Robinhood Chain "supports moving assets through its canonical bridge plus several cross-chain routes from partners. The canonical bridge is the trustless default for moving funds between Ethereum and Robinhood Chain; the additional routes offer faster transfers and broader network coverage." Documented as of 2026-09-09. ## Route comparison The docs publish this route table verbatim: | Route | Type | Speed | Best for | | --- | --- | --- | --- | | Arbitrum canonical bridge | Trustless L1↔L2 | Deposit ~10 min · Withdrawal ~7 days (challenge period) | Move ETH and ERC-20s between Ethereum and Robinhood Chain | | LayerZero OFT / Stargate | Messaging + Omnichain token (OFT) transfer | Minutes (varies with source-chain finality) | Fast token movement across chains, moving WBTC, USDG, and other OFTs | | Chainlink CCIP / Transporter | Messaging + token transfer | Minutes (varies with source-chain finality) | Fast, secure cross-chain transfers and applications: move tokens & send messages (e.g. bridge SyrupUSDG and deposit it into a lending market) | | Relay | Intents-based bridge | Seconds | Fast, low-cost transfers — and bridge-and-execute (trigger an action on the destination chain) in one step | | Across | Intents-based bridge | Seconds | Fast, capital-efficient asset bridging across chains | | LiFi / 0x | Cross-chain swap aggregators | Seconds–minutes | Swap-and-bridge in one step | Only the first route is described as trustless. The others are third-party infrastructure; the Terms of Service classify "any associated cross-chain oracle, verification services or other infrastructure" as a "Third Party Provider" and state that Robinhood Chain itself and "any associated bridging contracts… is not part of the Services." ## The canonical bridge "The canonical bridge is the native bridge for Robinhood Chain. It is trustless and requires no third-party validators — security is inherited directly from Ethereum." ### Depositing (Ethereum → Robinhood Chain) "Deposits typically confirm within 10 minutes." The documented path for users is the Arbitrum canonical bridge interface. **If a deposit doesn't arrive:** "Deposits use Arbitrum's retryable ticket system. If the Robinhood Chain (L2) leg of a deposit fails — for example, due to insufficient gas — the funds are not lost. The deposit can be manually redeemed from the bridge interface within 7 days." Note the polarity precisely: funds are *not lost*, but redemption is bounded — within 7 days, and it requires an action from someone. ### Withdrawing (Robinhood Chain → Ethereum) "Withdrawing from Robinhood Chain is a three-step process": 1. "Initiate the withdrawal on Robinhood Chain (L2)." 2. "Wait for the 7-day challenge period, a standard requirement of Arbitrum's fraud proof system." 3. "Claim your funds by submitting a transaction on Ethereum (L1). This final step is required and incurs L1 gas costs." Step 3 is not optional and not automatic. Budget L1 gas for it. The 7-day delay is distinct from transaction finality: "Finality is distinct from the withdrawal delay. Moving assets from Robinhood Chain back to Ethereum via the canonical bridge is subject to a 7-day challenge period — a requirement of Arbitrum's fraud-proof system, separate from transaction finality." A transaction reaching full Ethereum finality does *not* shorten the challenge period. ## Bridging programmatically "To bridge programmatically, interact with the Delayed Inbox contract on Ethereum L1." | Contract | Layer | Robinhood Chain (mainnet) | | --- | --- | --- | | Delayed Inbox | Ethereum (L1) | `0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D` | | L1 Gateway Router | Ethereum (L1) | `0x6a2E3a1e16FC29f27Ce61429746D558d656975bB` | | L1 ERC20 Gateway | Ethereum (L1) | `0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0` | | L2 Gateway Router | Robinhood Chain (L2) | `0x1E324B9316138CA9a73F960213621AD1aaf01B89` | | L2 ERC20 Gateway | Robinhood Chain (L2) | `0xfd9b17206278C16DdaacF6AC8f05dBf97EdCb31e` | The full L1/L2 gateway set, including the Arb-Custom and WETH gateways and the testnet column, is on [protocol contracts](protocol-contracts.md). ## Bridged token addresses differ across layers This is the highest-risk operational detail on this page: > "Note that a bridged ERC-20's contract address on Robinhood Chain differs > from its address on Ethereum. To resolve the corresponding L2 address, call > `calculateL2TokenAddress` on the L2 Gateway Router, or refer to the Protocol > Contracts page." Do not reuse an Ethereum token address on 4663. Resolve it. A concrete illustration from the published tables: L1 Weth is `0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2` (Ethereum's canonical WETH), while L2 Weth on Robinhood Chain is `0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73`. ## Custody framing The Terms of Service state that Robinhood "does not take possession, custody, or control of any Digital Asset on Robinhood Chain or bridged through the Bridging Smart Contracts," and that users acknowledge Robinhood "makes no representations or warranties with respect to Robinhood Chain or the Bridging Smart Contracts, and that, if you use Robinhood Chain or the Bridging Smart Contracts, you do so at your own risk." The ToS also names the failure modes it disclaims: the components "may be subject to bugs, exploits, cyberattacks, key compromise, validator downtime, or other failures that could result in irreversible loss or devaluation of digital assets or in failed, delayed, replayed, or censored transactions." ## Choosing a route **Analysis:** the documented trade-off is trust for latency. The canonical bridge inherits Ethereum security and needs no third-party validator set, at the cost of ~10 minutes inbound and ~7 days plus an L1 claim outbound. Every faster route in the table introduces a third party — a messaging network, relayer, or intent solver — that the docs do not vouch for. Nothing here is a recommendation about which to use; document the trust assumption you are taking before you take it. ## Related pages - [Cross-chain messaging](cross-chain-messaging.md) — the primitive beneath bridging - [Protocol contracts](protocol-contracts.md) - [Lighter Domains](../entities/lighter-domains.md) — separate deposit/withdraw paths for the Lighter instance