# Robinhood Chain — full corpus # LLM Wiki An open-source template for building LLM-powered knowledge bases, following [Andrej Karpathy's "LLM Wiki" pattern](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). You provide raw sources. The LLM reads them, writes structured wiki pages, cross-links everything, and maintains it over time. You never edit the wiki directly — you curate sources and ask questions. ## How It Works The system has three layers: ``` raw/ Sources you collect (articles, transcripts, notes, PDFs) wiki/ LLM-written & maintained pages (summaries, concepts, entities, syntheses) CLAUDE.md Schema that tells the LLM how to structure everything ``` Three operations drive the workflow: | Operation | Trigger | What happens | |-----------|---------|--------------| | **Ingest** | "ingest raw/my-source.txt" | LLM reads the source, creates a summary page, creates/updates concept and entity pages, adds cross-links, updates the index and log | | **Query** | Ask any question | LLM searches the wiki, synthesizes an answer with citations, optionally creates a synthesis page for novel insights | | **Lint** | "lint" or "health check" | LLM audits all pages for orphans, contradictions, missing links, incomplete sections, and low-confidence claims — fixes what it can, reports the rest | ## Quick Start 1. **Clone this repo** ```bash git clone https://github.com/YOUR_USERNAME/llm-wiki.git my-knowledge-base cd my-knowledge-base ``` 2. **Customize CLAUDE.md** for your domain - Update the Purpose section with your topic - Replace the placeholder tagging taxonomy with your own categories - Adjust confidence level descriptions if needed - Everything else (workflows, page formats, linking rules) works as-is 3. **Drop sources into `raw/`** - Text files, transcripts, articles, notes — any plain text - These are immutable once added; the LLM never modifies them 4. **Tell the LLM to ingest** ``` ingest raw/my-first-source.txt ``` The LLM will create summary pages, concept pages, entity pages, cross-links, and update the index. 5. **Ask questions** ``` What are the key differences between X and Y? ``` The LLM answers from the wiki, citing specific pages. 6. **Run health checks** ``` lint ``` The LLM audits the wiki and fixes issues. ## Directory Structure ``` . ├── CLAUDE.md # Schema — the LLM's instructions ├── raw/ # Your source documents (immutable) └── wiki/ ├── index.md # Master catalog of all pages ├── log.md # Append-only activity log ├── dashboard.md # Dataview dashboard (Obsidian) ├── analytics.md # Charts View analytics (Obsidian) ├── flashcards.md # Spaced repetition cards ├── summaries/ # One page per source document ├── concepts/ # Concept and framework pages ├── entities/ # People, tools, organizations, etc. ├── syntheses/ # Cross-cutting analyses and comparisons ├── journal/ # Research/session journal entries │ └── template.md # Journal entry template └── presentations/ # Marp slide decks ``` ## Enhancements This template includes several extras beyond the core wiki pattern: ### Dataview Dashboard (`wiki/dashboard.md`) Live queries that surface low-confidence pages, recent updates, concepts by tag, and pages with the most sources. Requires the [Dataview](https://github.com/blacksmithgu/obsidian-dataview) Obsidian plugin. ### Charts View Analytics (`wiki/analytics.md`) Visual analytics with pie charts, bar charts, and word clouds. Requires the [Charts View](https://github.com/caronchen/obsidian-chartsview-plugin) Obsidian plugin. ### Mermaid Diagrams Use Mermaid code blocks in any wiki page to create flowcharts, sequence diagrams, or concept maps. Native support in Obsidian and GitHub. ### Marp Slides (`wiki/presentations/`) Create slide decks from markdown using [Marp](https://marp.app/). Drop presentation files in this directory. ### Research Journal (`wiki/journal/`) Track your research sessions, experiments, or applied work with the included template. The LLM can reference journal entries when answering queries. ### Spaced Repetition (`wiki/flashcards.md`) Flashcards in the format used by the [Spaced Repetition](https://github.com/st3v3nmw/obsidian-spaced-repetition) Obsidian plugin. Ask the LLM to generate flashcards from any wiki page. ### MCP Server This repo works with Claude Code's MCP server capabilities. Point an MCP-compatible client at this repo and the LLM can read/write the wiki programmatically. ## Customizing for Your Domain The schema in `CLAUDE.md` is domain-agnostic. To adapt it: 1. **Purpose** — Describe your knowledge domain in one paragraph 2. **Tagging taxonomy** — Replace placeholder categories with your own (e.g., for a cooking KB: `cuisine`, `technique`, `ingredient`, `equipment`) 3. **Confidence levels** — Adjust the descriptions to match your domain's evidence standards 4. **Entity types** — Update the entity page description to match what entities mean in your domain (people, tools, companies, etc.) 5. **Journal template** — Customize `wiki/journal/template.md` for your workflow Everything else — page format, linking conventions, workflows, rules — is universal and works across domains. ## Example Domains This template works for any knowledge-intensive topic: - **Research notes** — papers, experiments, methodologies - **Book analysis** — themes, characters, author techniques - **Competitive analysis** — companies, products, market trends - **Course notes** — lectures, readings, key concepts - **Personal development** — frameworks, habits, book summaries - **Technical documentation** — APIs, architectures, design patterns - **Hobby deep-dives** — any subject you want to master ## License MIT --- title: "Knowledge Base Index" type: index updated: 2026-09-09 robinhood_chain_id: 4663 --- # Robinhood Chain Knowledge Base Robinhood Chain is an Ethereum Layer-2 (chain ID 4663) built for tokenized real-world assets, whose flagship asset is Stock Tokens — tokenised debt securities issued by Robinhood Assets (Jersey) Limited. This KB documents `docs.robinhood.com/chain`, Chainlink's Robinhood feed documentation, the Doppler launch protocol, and Uniswap's v4 deployments page, all as captured on 2026-09-09. Master catalog of all wiki pages. Every page in the wiki must have an entry here. ## Concepts | Page | Tags | Confidence | Updated | |------|------|------------|---------| | [access-controls-registry](concepts/access-controls-registry.md) | access-control, trust, permissions, governance, compliance | medium | 2026-09-09 | | [account-abstraction](concepts/account-abstraction.md) | erc-4337, eip-7702, paymaster, bundler, smart-accounts | medium | 2026-09-09 | | [bridging](concepts/bridging.md) | bridging, canonical-bridge, withdrawals, arbitrum, l2 | medium | 2026-09-09 | | [building-with-stock-tokens](concepts/building-with-stock-tokens.md) | erc-8056, erc-20, integration, uimultiplier, liquidity | medium | 2026-09-09 | | [connecting](concepts/connecting.md) | rpc, chain-id, wallet, block-explorer, endpoints | medium | 2026-09-09 | | [cross-chain-messaging](concepts/cross-chain-messaging.md) | cross-chain, retryable-tickets, arbsys, arbitrum-sdk, l2 | medium | 2026-09-09 | | [data-streams](concepts/data-streams.md) | chainlink, data-streams, verifier-proxy, pull-oracle, low-latency | medium | 2026-09-09 | | [deploying-contracts](concepts/deploying-contracts.md) | deployment, foundry, hardhat, verification, evm | medium | 2026-09-09 | | [differences-from-ethereum](concepts/differences-from-ethereum.md) | evm, arbitrum-nitro, precompiles, solidity, gotchas | medium | 2026-09-09 | | [doppler-launches](concepts/doppler-launches.md) | doppler, token-launch, auctions, liquidity-migration, fees | medium | 2026-09-09 | | [gas-and-fees](concepts/gas-and-fees.md) | gas, fees, calldata, arbgasinfo, layer-2 | medium | 2026-09-09 | | [governance](concepts/governance.md) | governance, security-council, validators, bold, upgrades | medium | 2026-09-09 | | [oracles-and-price-feeds](concepts/oracles-and-price-feeds.md) | chainlink, price-feeds, aggregatorv3, staleness, oracle-pause | medium | 2026-09-09 | | [protocol-contracts](concepts/protocol-contracts.md) | contracts, addresses, arbitrum, precompiles, bridge | medium | 2026-09-09 | | [running-a-node](concepts/running-a-node.md) | node, nitro, arbos, infrastructure, sync | medium | 2026-09-09 | | [stock-token-apis](concepts/stock-token-apis.md) | api, rest, rate-limits, corporate-actions, assets | medium | 2026-09-09 | | [stock-tokens](concepts/stock-tokens.md) | stock-tokens, rwa, erc-20, rhj, erc-8056 | medium | 2026-09-09 | | [token-contracts](concepts/token-contracts.md) | stock-tokens, erc20, contracts, rwa, erc-8056 | medium | 2026-09-09 | | [transaction-finality](concepts/transaction-finality.md) | finality, sequencer, confirmations, reorg, withdrawals | medium | 2026-09-09 | | [ui-multipliers](concepts/ui-multipliers.md) | erc-8056, multiplier, corporate-actions, stock-tokens, oracles | medium | 2026-09-09 | | [what-is-robinhood-chain](concepts/what-is-robinhood-chain.md) | robinhood-chain, layer-2, arbitrum, rwa, evm | medium | 2026-09-09 | ## Entities | Page | Tags | Confidence | Updated | |------|------|------------|---------| | [doppler-airlock](entities/doppler-airlock.md) | doppler, airlock, contract, modules, launch | medium | 2026-09-09 | | [lighter-domains](entities/lighter-domains.md) | lighter, orderbook, perps, deposits, withdrawals | medium | 2026-09-09 | ## Summaries | Page | Tags | Confidence | Updated | |------|------|------------|---------| | [docs-catalog](summaries/docs-catalog.md) | catalog, documentation, coverage, map | high | 2026-09-09 | ## Syntheses | Page | Tags | Confidence | Updated | |------|------|------------|---------| | [reading-a-stock-token-price](syntheses/reading-a-stock-token-price.md) | oracles, chainlink, staleness, integration, corporate-actions | medium | 2026-09-09 | | [what-this-wiki-cannot-tell-you](syntheses/what-this-wiki-cannot-tell-you.md) | scope, verification, abstention, provenance, addresses | high | 2026-09-09 | ## Statistics - **Total pages**: 26 - **Concepts**: 21 - **Entities**: 2 - **Summaries**: 1 - **Syntheses**: 2 - **Sources ingested**: 49 immutable raw captures - **High confidence**: 2 - **Medium confidence**: 24 - **Low confidence**: 0 --- title: "Access Controls and Disclosed Admin Powers" type: concept tags: [access-control, trust, permissions, governance, compliance] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md", "raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md", "raw/web_community-differences-from-ethereum-robinhood-chain-documentation.md", "raw/web_community-governance-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-terms-of-service-robinhood-chain-documentati.md", "raw/web_community-robinhood-chain-contracts-robinhood-chain-documentation.md", "raw/web_community-stock-tokens-robinhood-chain-documentation.md"] confidence: medium --- # Access Controls and Disclosed Admin Powers This page inventories every administrative power over Robinhood Chain (4663) and its Stock Tokens that the captured sources actually disclose, as documented on 2026-09-09. It is deliberately conservative: powers not described in a source are recorded as *not documented*, never inferred. ## No shared access-control registry is described **The captured sources describe no shared access-controls registry contract for Robinhood Chain or for the Stock Tokens.** Across all captured pages there is: - no named role constant (no `DEFAULT_ADMIN_ROLE`, `PAUSER_ROLE`, `MINTER_ROLE`, or any `*_ROLE` string), - no `hasRole` / `grantRole` / `revokeRole` surface, - no registry address, - no `blockAddress`, blocklist, freeze, or seize function on any Robinhood contract, - no documented token-wide `pause()` / `unpause()` that halts transfers. The only "registry" the docs mention is the **on-chain asset registry** that feeds the Token Contracts page — "The table below is generated live from the on-chain asset registry" — and its address, interface and write permissions are not published in any captured source. Treat the absence as a documentation gap, not as proof that no such contract exists. If you need the authoritative permission surface of a specific token, read the verified source on the block explorer for that exact address. ## Powers that ARE documented ### 1. Issuer control of the corporate-action multiplier (per token) Chainlink's provider page states: "Robinhood updates the multiplier on the token contract through two paths": - `updateMultiplier(uint256)` — "sets a new `uiMultiplier` effective immediately." - `updateMultiplier(uint256, uint256 effectiveAt)` — "stages the next multiplier." The same page states the contract itself constrains how those paths are used: "Robinhood's on-chain token contract enforces two update paths: **Small updates** (no price discontinuity): Applied immediately via automated processes… **Large updates** (price discontinuity): Requires a scheduled pause window and manual confirmation before unpause." The caller is described only as "Robinhood" / "the asset issuer". **No role name, admin address, multisig, or timelock is documented for this power.** See [UI multipliers](ui-multipliers.md) for the mechanism and its balance effects. ### 2. Issuer control of the oracle pause flag (per token) The token contract "exposes a dedicated oracle pause flag, `oraclePaused()`, that the feed honors." The transitions are `pauseOracle()` and `unpauseOracle()`, both described as issuer-driven. Its scope is narrow and the Robinhood docs are explicit about the limit: > "The flag is advisory and not enforced on-chain, so a paused oracle may still > return a value — keep your staleness check (`updatedAt` vs. heartbeat) as the > primary guard rather than relying on the flag alone." So `pauseOracle()` is **not** a transfer pause and **not** an on-chain enforcement mechanism as documented; it signals the Chainlink feed to hold its last known good value. Token transfers and swaps are not described as being affected: "Onchain swaps remain unaffected." Chainlink adds the trust framing directly: "Corporate actions are coordinated by Robinhood as the asset issuer. Chainlink does not provide corporate-action calendar data or automated pause triggers; pause timing and multiplier updates are coordinated by Robinhood." ### 3. Sequencer-level transaction screening (chain-wide) This is the chain's most consequential documented filter, and it sits at the sequencer, not in a contract: > "Robinhood Chain maintains compliance standards through sequencer-level > screening. While rare, this mechanism can influence smart-contract execution; > for instance, any transaction associated with a sanctioned address will be > excluded from inclusion." The documented consequences: - Reads are unaffected: "Standard read operations—such as `eth_call`, `eth_getLogs`, or balance queries—remain fully accessible and unaffected." - Nothing is reversed after the fact: "Since a blocked transfer is never processed, it simply appears as though the event never occurred, ensuring indexers remain synchronized with the actual state." Note the polarity carefully: this is **exclusion from inclusion**, not an on-chain blocklist that rejects a transfer mid-execution. The Terms of Service constrain the sequencer in the other direction: "The Robinhood Chain Sequencer cannot modify, reverse, or cancel transactions once submitted, and does not have access to your private keys." The ToS also describes the sequencer as "non-custodial and it does not store, hold, or control your Digital Assets at any time, other than collecting applicable gas fees," and states Robinhood "does not take possession, custody, or control of any Digital Asset on Robinhood Chain or bridged through the Bridging Smart Contracts." ### 4. Protocol upgrade authority: the Security Council Protocol-level upgrades are gated by an eight-signer Security Council with a timelock. Thresholds, seat allocation and the emergency path are covered in [governance](governance.md); the load-bearing distinction is that routine actions are "subject to a seven-day on-chain timelock before execution" while "Emergency actions bypass the timelock but require approval from seven of eight signers." ### 5. Proxy admin contracts (L1 and L2) The [protocol contracts](protocol-contracts.md) page lists proxy-admin contracts by address — `CoreProxyAdmin` and `L1 Proxy Admin` (both `0x1232813BDd40aa9d53066A880dE78a4Be70B90FD` on mainnet) and `L2 Proxy Admin` (`0xa3Acd31AFb851B4eB9DAD00F5204c01D924267dF`). **The captured sources list these addresses but do not document their owners, their function surface, or what they are permitted to upgrade.** ### 6. Doppler-side permissions (third-party protocol, not Robinhood) Doppler's own docs disclose permissions over pools launched through it. These are written generically across all Doppler chains and are *not* scoped to 4663 in the source, so treat them as protocol behavior to verify per deployment: - "Doppler Hooks are approved by the protocol multisig." - A pool's hook is mutable: it "can opt-in to use one later via the `setHook` function", can "opt-out… by setting the hook address to `address(0)`", and "can change its associated Doppler Hook to a different one at any time." - Rehype fee distribution: "Only the fixed fee distribution controller can replace the eight-value config." The controller "is fixed at pool creation", and assigning it "to addresses such as `0xdead`" is offered as a way "to make the config immutable." - "the airlock owner must receive at least 5% of streamed fees" is a contract-enforced constraint on V4 migration beneficiaries. See [Doppler launches](doppler-launches.md) and the [Airlock entity page](../entities/doppler-airlock.md). ## Trust surface summary **Analysis:** from the documented set, the parties with discretionary power over a user's position on 4663 are (a) the issuer, over each Stock Token's multiplier and oracle-pause flag; (b) the sequencer operator, over whether a transaction is included at all; and (c) the Security Council, over protocol upgrades. None of the captured sources documents a power to move, freeze, or claw back a token balance already held in a user wallet, and the ToS affirmatively denies custody and denies the sequencer the ability to reverse a submitted transaction. That is a meaningful limit — but it is documented in prose and terms, not in a published permission list, so it should be verified against contract source before being relied on. ## Related pages - [UI multipliers](ui-multipliers.md) - [Governance](governance.md) - [Protocol contracts](protocol-contracts.md) - [Token contracts](token-contracts.md) --- title: "Account Abstraction on Robinhood Chain" type: concept tags: [erc-4337, eip-7702, paymaster, bundler, smart-accounts] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-account-abstraction-robinhood-chain-documentation.md", "raw/web_community-about-robinhood-chain-robinhood-chain-documentation.md", "raw/web_community-connecting-to-robinhood-chain-robinhood-chain-documentation.md", "raw/web_community-gas-fees-robinhood-chain-documentation.md"] confidence: medium --- # Account Abstraction on Robinhood Chain ## Definition "Robinhood Chain has first-class support for ERC-4337 account abstraction, and also supports EIP-7702, which lets existing externally-owned accounts delegate to smart contract code — so users can get smart-account features (batching, sponsorship, session keys) without migrating to a new address." All addresses and values below are reproduced verbatim from `docs.robinhood.com/chain` **as documented on 2026-09-09**. The About page frames the same capability from the developer side: "Developers can submit and manage transactions, sponsor gas fees for users and create programmable wallets with built-in batching and session key support." ## Network Configuration | Property | Value | | --- | --- | | Chain ID | `4663` | | Bundler / RPC URL | `https://robinhood-mainnet.g.alchemy.com/v2/{API_KEY}` | Note that the bundler URL is the same Alchemy endpoint documented as the general RPC endpoint on the Connecting page — the AA page does not publish a separate bundler host. **No testnet bundler URL is documented**; the AA page covers mainnet only. ## Deployed ERC-4337 Contracts | Contract | Address | | --- | --- | | ERC-4337 Entrypoint v0.6.0 | `0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789` | | ERC-4337 SenderCreator v0.6.0 | `0x7fc98430eAEdbb6070B35B39D798725049088348` | | ERC-4337 Entrypoint v0.7.0 | `0x0000000071727De22E5E9d8BAf0edAc6f37da032` | | ERC-4337 SenderCreator v0.7.0 | `0xEFC2c1444eBCC4Db75e7613d20C6a62fF67A167C` | | ERC-4337 Entrypoint v0.8.0 | `0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108` | | ERC-4337 SenderCreator v0.8.0 | `0x449ED7C3e6Fee6a97311d4b55475DF59C44AdD33` | | ERC-4337 Safe Module Setup v0.3.0 | `0x2dd68b007B46fBe91B9A7c3EDa5A7a1063cB5b47` | | ERC-4337 Safe 4337 Module v0.3.0 (supporting Entrypoint v0.7.0) | `0x75cf11467937ce3F2f357CE24ffc3DBF8fD5c226` | All three EntryPoint versions — v0.6.0, v0.7.0 and v0.8.0 — are deployed simultaneously, each with its matching SenderCreator. The Safe 4337 Module row is explicitly scoped in the source to EntryPoint v0.7.0. **Analysis:** with three EntryPoints live, the version your account, bundler, paymaster and SDK each target must agree — a UserOperation built for one EntryPoint is not valid against another. The ZeroDev sample below pins `getEntryPoint("0.7")`, which matches the Safe module's documented scope. ## Providers "Account abstraction on Robinhood Chain is powered by Alchemy, with ZeroDev available as an alternative." Four are listed: | Service | Description as documented | | --- | --- | | Alchemy | "Create and manage programmable wallets to submit and manage transactions with built-in batching, configurable spend policies, and gas sponsorship for users." | | ZeroDev | "Smart AA wallets that can be embedded as UI or used through API. Supports gas sponsorship, transaction batching, transaction automation, and cross-chain execution." | | Privy | "Embedded wallets and account abstraction tooling" | | Dynamic | "Embedded wallets, wallet connectors, and account abstraction tooling" | ## Alchemy Quickstart "Alchemy recommends using the latest version `@alchemy/wallet-apis` for the easiest setup." The documented prerequisites are an Alchemy account with an app on Robinhood Chain (for the API key) and "a Gas Manager policy to sponsor gas" in the dashboard, noting the Policy ID. ```bash npm install @alchemy/wallet-apis @alchemy/common viem ``` ```js import { createSmartWalletClient, alchemyWalletTransport } from "@alchemy/wallet-apis"; import { robinhoodMainnet } from "@alchemy/common/chains"; import { privateKeyToAccount } from "viem/accounts"; import { zeroAddress } from "viem"; const client = createSmartWalletClient({ transport: alchemyWalletTransport({ apiKey: "YOUR_API_KEY", }), chain: robinhoodMainnet, signer: privateKeyToAccount("0xYOUR_PRIVATE_KEY" as const), paymaster: { policyId: "YOUR_POLICY_ID", // sponsor gas for the user }, }); // prepare and send calls const { id } = await client.sendCalls({ calls: [{ to: zeroAddress, value: BigInt(0) }], }); // get calls status const status = await client.waitForCallsStatus({ id }); ``` The chain object is named `robinhoodMainnet`. **Note the import path differs between the two documented samples:** Alchemy's imports it from `@alchemy/common/chains`, while the ZeroDev sample below imports `robinhoodMainnet` from `viem/chains`. Both appear on the same docs page. Neither import is verified against a package here; confirm against the package you install. ## ZeroDev Quickstart "If you prefer ZeroDev for gas sponsorship, configure a ZeroDev paymaster pointed at Robinhood Chain (chain ID 4663)." ```bash npm i @zerodev/sdk @zerodev/ecdsa-validator ``` The RPC template, verbatim — it embeds the chain ID in the path: ```js const ZERODEV_RPC = 'https://rpc.zerodev.app/api/v3/YOUR_PROJECT_ID/chain/4663' ``` The documented flow: build a signer, a public client over `ZERODEV_RPC`, an ECDSA validator, then a Kernel account and client. ```js import { createKernelAccount, createKernelAccountClient, createZeroDevPaymasterClient } from "@zerodev/sdk" import { KERNEL_V3_1, getEntryPoint } from "@zerodev/sdk/constants" import { signerToEcdsaValidator } from "@zerodev/ecdsa-validator" import { robinhoodMainnet } from "viem/chains" const chain = robinhoodMainnet const entryPoint = getEntryPoint("0.7") const kernelVersion = KERNEL_V3_1 ``` The paymaster is wired through `getPaymasterData`, which delegates to `zerodevPaymaster.sponsorUserOperation({userOperation})`. The sample sends a UserOperation with `kernelClient.sendUserOperation({ callData: await kernelClient.account.encodeCalls([...]) })` and awaits `kernelClient.waitForUserOperationReceipt({ hash: userOpHash, timeout: 1000 * 15 })`. The sample's own comment on the transport is worth keeping: "Use your own RPC provider in production (e.g. Infura/Alchemy)." ## Inspecting a UserOperation The ZeroDev sample logs the result at: ``` https://robinhoodchain.blockscout.com/op/ + userOpHash ``` That is the documented Blockscout path for a UserOperation on this chain, distinct from the `/address/` and `/tx/` paths used elsewhere in the docs. ## Why Batching Matters Here Specifically The Gas & Fees page lists batching as one of three documented fee-reduction tactics: "Batch operations where possible (see Account Abstraction for batched UserOperations)." Because the variable half of a Robinhood Chain fee is the L1 data fee and that fee "is proportional to the size of your transaction's calldata," folding several calls into one UserOperation reduces the per-operation overhead that would otherwise be posted separately. See [gas-and-fees.md](gas-and-fees.md). Gas *sponsorship* is a separate mechanism — a paymaster pays the fee on the user's behalf; it does not make the fee smaller. ## What Is Not Documented - No testnet AA deployment addresses or bundler URL. - No paymaster contract addresses (sponsorship is configured through provider dashboards — an Alchemy Gas Manager policy ID, or a ZeroDev project ID). - No session-key contract or interface, despite session keys being named as a supported feature on the About page. - No EIP-7702 delegation contract address or activation details beyond the statement that the chain supports it. ## Related Concepts - [gas-and-fees.md](gas-and-fees.md) - [connecting.md](connecting.md) — the underlying RPC endpoints - [what-is-robinhood-chain.md](what-is-robinhood-chain.md) ## Sources - `raw/web_community-account-abstraction-robinhood-chain-documentation.md` - `raw/web_community-about-robinhood-chain-robinhood-chain-documentation.md` - `raw/web_community-connecting-to-robinhood-chain-robinhood-chain-documentation.md` - `raw/web_community-gas-fees-robinhood-chain-documentation.md` --- 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 --- title: "Building with Stock Tokens" type: concept tags: [erc-8056, erc-20, integration, uimultiplier, liquidity] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-token-contracts-robinhood-chain-documentatio.md", "raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md"] confidence: medium --- # Building with Stock Tokens Developer-facing integration guide. For what the instrument legally is — a tokenised debt security issued by RHJ that "does not grant investors any legal or beneficial rights in, or against the issuer of, those underlying securities" — see [stock-tokens.md](stock-tokens.md). Nothing here is trading or investment advice. All values reflect `docs.robinhood.com/chain` and `docs.chain.link` **as documented on 2026-09-09**. ## What Works Out of the Box "Stock tokens are ERC-20 (18 decimals). All standard token operations work without modification": ```solidity IERC20 nvda = IERC20(NVDA_TOKEN_ADDRESS); uint256 balance = nvda.balanceOf(user); nvda.transfer(recipient, amount); nvda.approve(spender, amount); ``` The docs' framing: "programmable access to real-world assets using the same tools you already use for any ERC-20 — no special SDK required to get started." Wallets, indexers, token lists, and any ERC-20-aware contract work unchanged. **Token addresses are not recoverable from this capture.** The Token Contracts page renders its stock-token table client-side from the onchain asset registry and was captured as "Loading tokens…". Resolve addresses from the live Token Contracts page or from `GET https://api.robinhood.com/rhj/assets` (see [stock-token-apis.md](stock-token-apis.md)), and heed the docs' warning that "a token with a matching name/ticker but a different contract address is not a Robinhood Stock Token." ## The ERC-8056 Layer Stock tokens add ERC-8056 (Scaled UI Amount Extension) on top of ERC-20. "The multiplier scales the effective amount without changing raw balances or total supply — `balanceOf()` and `totalSupply()` stay fixed. Stock tokens are **not** rebasing tokens." ### Core interface ```solidity interface IScaledUIAmount { // Current UI multiplier, expressed with 18 decimals (1e18 = 1.0). function uiMultiplier() external view returns (uint256); // Emitted when the multiplier changes (e.g. a dividend or split). event UIMultiplierUpdated( uint256 oldMultiplier, uint256 newMultiplier, uint256 effectiveAtTimestamp ); // Emitted on a transfer, carrying both the raw value and the UI-adjusted // (underlying-share) value. event TransferWithScaledUI( address indexed from, address indexed to, uint256 value, uint256 uiValue ); } ``` ### Pending-update interface ```solidity interface IScaledUIAmountNewUIMultiplier { // The pending UI multiplier scheduled to take effect at effectiveAt. function newUIMultiplier() external view returns (uint256); // The timestamp at which the pending multiplier becomes effective. function effectiveAt() external view returns (uint256); } ``` "Before any update is scheduled this tracks the current multiplier" — so `newUIMultiplier()` is never a null sentinel; compare it against `uiMultiplier()` to detect a genuine pending change. ### UI-adjusted views ```solidity interface IScaledUIAmountBalances { // UI-adjusted balance of an account (raw balance scaled by uiMultiplier). function balanceOfUI(address account) external view returns (uint256); // UI-adjusted total supply. function totalSupplyUI() external view returns (uint256); } ``` ### Conversion ``` underlying shares = raw token amount × uiMultiplier ÷ 1e18 ``` "`uiMultiplier()` is fixed-point with 18 decimals — 1e18 = 1.0. At launch the multiplier is 1e18 (one token = one underlying share)." Chainlink's documentation adds the write paths, which are issuer-controlled: `updateMultiplier(uint256)` for an immediate change, and `updateMultiplier(uint256, uint256 effectiveAt)` to stage the next one. Small updates with no price discontinuity (routine dividend reinvestment) are "applied immediately via automated processes"; large updates with a price discontinuity (stock splits) require "a scheduled pause window and manual confirmation before unpause." **Analysis:** the multiplier is the one field that makes these tokens different from an ordinary ERC-20, and it moves. Any integration that caches a shares-per-token ratio, or that stores a USD value derived from one, needs an invalidation path driven by `UIMultiplierUpdated`. ## Reading a Price "Every stock token has a per-asset Chainlink price feed implementing the standard `AggregatorV3Interface` (`latestRoundData()`, read via the feed proxy — same interface as crypto feeds)": ```solidity AggregatorV3Interface feed = AggregatorV3Interface(NVDA_PRICE_FEED); (, int256 price, , uint256 updatedAt, ) = feed.latestRoundData(); require(price > 0 && updatedAt > 0, "Invalid price"); ``` Critically: "The Chainlink price already includes the corporate-action multiplier (dividends, splits), so the value you read is the token's full price — **don't apply the multiplier yourself.** If you need the raw ratio, read it onchain via the token's `uiMultiplier()`." Chainlink states the formula it implements as `Token Price = Underlying Equity Market Price × Multiplier`. Feed proxy addresses, decimals and heartbeats are not published in this capture — see [oracles-and-price-feeds.md](oracles-and-price-feeds.md), including the staleness and pause behaviour you must handle. ### Documented valuation example ```solidity // Returns the USD value of a user's stock token balance. function holdingValueUsd( IERC20 stockToken, AggregatorV3Interface priceFeed, address user ) external view returns (uint256) { uint256 balance = stockToken.balanceOf(user); // 18 decimals (, int256 price, , uint256 updatedAt, ) = priceFeed.latestRoundData(); require(price > 0 && updatedAt > 0, "Invalid price"); // price: 8 decimals // (balance * price) scaled by token + feed decimals return (balance * uint256(price)) / 1e8; } ``` **Analysis:** this example hardcodes `1e8` for feed decimals, while the Oracles page's own best-practice list says "Read `decimals()` — never hard-code." The two pages disagree in practice; the safer reading is to call `decimals()`. The example also checks only `updatedAt > 0`, which is not a staleness bound — the Oracles page asks for `updatedAt` compared against the feed's heartbeat. ### Presentation conversions - Token value (default): use the feed price directly. - Underlying share price: `feedPrice * 1e18 / uiMultiplier()` - Share-equivalent units: `balance * uiMultiplier() / 1e18` "The economic value is identical in every case — only the presentation differs." The docs warn: "Always divide by 1e18 after applying it… otherwise the result is off by a factor of 1e18." ## Liquidity and Venues The docs list four documented liquidity sources. This is a description of market structure, not a recommendation. | Source | How it works, as documented | | --- | --- | | RFQ | "RFQ uses signed market-maker quotes sourced through aggregators such as 0x RFQ, 1inch Fusion, and LiFi." Off-chain signed quotes. | | AMM | "Stock Tokens can also be traded through standard automated market maker (AMM) pools such as Uniswap. AMM pools provide composable, on-chain liquidity." | | Proprietary AMM (propAMM) | "Where on-chain AMM liquidity is limited, Stock Tokens can also be traded through proprietary AMM (propAMM) like Rialto, which provides market-maker-backed liquidity… unlike RFQ, which relies on off-chain signed quotes." | | Orderbook | "Stock Tokens also trade on Lighter (spot & perps)." | Direct mint and burn with RHJ is the primary market and is "available only to Authorized Participants / market makers and requires KYB onboarding." "Tokenized stocks trade via RFQ at launch. They remain standard ERC-20s and can be transferred and held in any wallet." (Note that the ToS restricts the phrase "tokenized stocks" for third-party content — see [stock-tokens.md](stock-tokens.md).) ## Documented Use Cases The docs list, verbatim: portfolio & display; trading (RFQ swap interfaces); lending & borrowing using stock tokens as collateral; indices & baskets; yield strategies; price-aware contracts ("A contract that executes when a stock token crosses a threshold"); perps & derivatives; and "Global access (in eligible regions)." The page carries its own disclaimer that listing a third-party protocol "does not constitute an endorsement, partnership, or warranty by Robinhood." ## Documented Getting-Started Sequence 1. "Pick a stock token — grab its address from Token Contracts." 2. "Read a balance — call `balanceOf` like any ERC-20." 3. "Read its price — call `latestRoundData()` on the token's Chainlink feed." 4. "Build — display it, swap it, use it as collateral, or compose it into your product." Before executing in a given session, the Stock Tokens page adds: check the asset's `tradingCapabilities` from `/assets`. ## Related Concepts - [stock-tokens.md](stock-tokens.md) - [stock-token-apis.md](stock-token-apis.md) - [oracles-and-price-feeds.md](oracles-and-price-feeds.md) - [data-streams.md](data-streams.md) ## Sources - `raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md` - `raw/web_community-stock-tokens-robinhood-chain-documentation.md` - `raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md` - `raw/web_community-robinhood-chain-token-contracts-robinhood-chain-documentatio.md` - `raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md` --- title: "Connecting to Robinhood Chain" type: concept tags: [rpc, chain-id, wallet, block-explorer, endpoints] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-connecting-to-robinhood-chain-robinhood-chain-documentation.md", "raw/web_community-add-network-to-your-wallet-robinhood-chain-documentation.md", "raw/web_community-deploy-a-contract-robinhood-chain-documentation.md", "raw/web_community-run-a-robinhood-chain-full-node-robinhood-chain-documentatio.md"] confidence: medium --- # Connecting to Robinhood Chain Every value on this page is reproduced verbatim from `docs.robinhood.com/chain` **as documented on 2026-09-09**. Check an address or URL against the live docs before moving funds. ## Network Configuration | Property | Robinhood Chain | Robinhood Chain Testnet | | --- | --- | --- | | Chain ID | `4663` | `46630` | | Currency Symbol | `ETH` | `ETH` | | Block Explorer | `robinhoodchain.blockscout.com` | `explorer.testnet.chain.robinhood.com` | The block explorer values are given by the docs exactly as shown — bare hostnames, no scheme. Elsewhere in the same doc set the explorer is used with a scheme, e.g. `https://robinhoodchain.blockscout.com/address/` and the Blockscout verification API at `https://robinhoodchain.blockscout.com/api/`. ## Public Endpoints The docs are explicit about the tradeoff: "The following public endpoints are available but are rate-limited and not recommended for production use. For production, use a provider." | Endpoint | Mainnet URL | Testnet URL | | --- | --- | --- | | RPC | `https://rpc.mainnet.chain.robinhood.com` | `https://rpc.testnet.chain.robinhood.com` | | Sequencer Feed | `wss://feed.mainnet.chain.robinhood.com` | `wss://feed.testnet.chain.robinhood.com` | | Sequencer | `https://sequencer.mainnet.chain.robinhood.com` | `https://sequencer.testnet.chain.robinhood.com` | The full-node guide notes of the feed URL: "The feed URL must be `wss://`, not `https://`." **Discrepancy worth knowing:** the Connecting page and the Deploy a Contract page both give the mainnet public RPC as `https://rpc.mainnet.chain.robinhood.com` (no trailing slash), while the Add-network-to-your-wallet page gives it as `https://rpc.mainnet.chain.robinhood.com/` (with a trailing slash). Both forms are documented; the testnet URL is given without a trailing slash on every page. ## Provider Endpoints "Alchemy is the recommended infrastructure provider for building on Robinhood Chain." You create an app on Robinhood Chain to obtain an API key. | Endpoint | Mainnet URL | Testnet URL | | --- | --- | --- | | RPC | `https://robinhood-mainnet.g.alchemy.com/v2/{API_KEY}` | `https://robinhood-testnet.g.alchemy.com/v2/{API_KEY}` | | Websocket | `wss://robinhood-mainnet.g.alchemy.com/v2/{API_KEY}` | `wss://robinhood-testnet.g.alchemy.com/v2/{API_KEY}` | "For historical reads and indexing, use an archive endpoint — available through providers such as Alchemy." Alchemy's documented service surface on this chain: **Node API** (standard JSON-RPC and Websocket), **Data API** ("Instant, reliable access to indexed blockchain data like token balances, transaction history, NFTs, and portfolio activity"), and **Gasless Transaction Infrastructure** (programmable wallets with gas sponsorship, batched transactions, policies, spending controls) — see [account-abstraction.md](account-abstraction.md). ### Other providers "Robinhood Chain is also supported by QuickNode, Blockdaemon, dRPC, and Validation Cloud. Sign up directly with your provider to get an endpoint." QuickNode endpoints follow the template: ``` https://{ENDPOINT}.robinhood-mainnet.quiknode.pro/{TOKEN} ``` The full-node page lists a slightly longer provider set with landing pages: Quicknode (`https://www.quicknode.com/chains/robinhood`), Blockdaemon (`https://docs.blockdaemon.com/docs/how-to-connect-to-robinhood`), dRPC (`https://drpc.org/chainlist/robinhood-testnet-rpc`), Validation Cloud (`https://www.validationcloud.io/robinhood`), Chainstack (`https://chainstack.com/build-better-with-robinhood-chain/`), GlobalStake (`https://GlobalStake.io`). ## Adding the Network to a Wallet ### Robinhood Wallet "Robinhood Wallet provides support for Robinhood Chain." The documented steps are: download Robinhood Wallet (requires iOS or Android), then create a wallet. ### Browser wallets "Robinhood Chain is compatible with EVM Wallets (MetaMask and more)." The docs page offers a click-to-add widget; in the 2026-09-09 capture that widget had not rendered (the page shows only "Loading wallet connection..."), so the automatic-add targets are not recoverable from this source. To add manually to MetaMask, the docs give these fields: | Property | Robinhood Chain | Robinhood Chain Testnet | | --- | --- | --- | | Chain ID | `4663` | `46630` | | Default RPC URL | `https://rpc.mainnet.chain.robinhood.com/` | `https://rpc.testnet.chain.robinhood.com` | | Currency Symbol | `ETH` | `ETH` | | Block Explorer | `robinhoodchain.blockscout.com` | `explorer.testnet.chain.robinhood.com` | ## Toolchain Configuration The Deploy a Contract guide gives working configuration for both major toolchains. Foundry (environment + verification): ```bash export RH_RPC_URL=https://rpc.mainnet.chain.robinhood.com forge verify-contract \ src/HelloRobinhood.sol:HelloRobinhood \ --chain-id 4663 \ --rpc-url $RH_RPC_URL \ --verifier blockscout \ --verifier-url https://robinhoodchain.blockscout.com/api/ ``` Hardhat network + custom-chain block: ```js networks: { robinhood: { url: process.env.RH_RPC_URL, chainId: 4663, accounts: [process.env.PRIVATE_KEY], }, }, etherscan: { apiKey: { robinhood: "empty" }, customChains: [ { network: "robinhood", chainId: 4663, urls: { apiURL: "https://robinhoodchain.blockscout.com/api", browserURL: "https://robinhoodchain.blockscout.com/", }, }, ], }, ``` For testnet, the docs say: "set `RH_RPC_URL` to the testnet RPC, use chain ID 46630, and verify against `https://explorer.testnet.chain.robinhood.com/api/`." ## Running Your Own Node If you need your own endpoint rather than a hosted one, the node is Nitro. Ports are `8547` (HTTP) and `8548` (WS); the container image documented is `offchainlabs/nitro-node:v3.11.2-3599aca`; the chain runs **ArbOS 61**. A node needs *both* an L1 execution RPC endpoint and an L1 beacon (consensus) endpoint, "required to read blob data". The docs' own caveat: "If you don't already know why you need your own node, you probably don't." ## Bringing Funds Onto the Chain "To move funds onto Robinhood Chain, use the canonical Arbitrum bridge or one of several cross-chain routes." The canonical route deposits in roughly 10 minutes and withdraws subject to a ~7-day challenge period; see [transaction-finality.md](transaction-finality.md) for why the withdrawal delay is not the same thing as finality. ## Related Concepts - [what-is-robinhood-chain.md](what-is-robinhood-chain.md) - [gas-and-fees.md](gas-and-fees.md) - [account-abstraction.md](account-abstraction.md) ## Sources - `raw/web_community-connecting-to-robinhood-chain-robinhood-chain-documentation.md` - `raw/web_community-add-network-to-your-wallet-robinhood-chain-documentation.md` - `raw/web_community-deploy-a-contract-robinhood-chain-documentation.md` - `raw/web_community-run-a-robinhood-chain-full-node-robinhood-chain-documentatio.md` --- title: "Cross-Chain Messaging Between Ethereum and Chain 4663" type: concept tags: [cross-chain, retryable-tickets, arbsys, arbitrum-sdk, l2] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-cross-chain-messaging-robinhood-chain-documentation.md", "raw/web_community-differences-from-ethereum-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-contracts-robinhood-chain-documentation.md", "raw/web_community-transaction-finality-robinhood-chain-documentation.md"] confidence: medium --- # Cross-Chain Messaging Between Ethereum and Chain 4663 "Robinhood Chain supports arbitrary message passing between Ethereum (L1) and Robinhood Chain (L2). This is the lower-level primitive beneath Bridging — where bridging moves assets, cross-chain messaging passes arbitrary calls and data, letting you call an L2 contract from Ethereum or trigger an L1 action from L2." Documented as of 2026-09-09. Two directions, two mechanisms: - "L1 → L2 via retryable tickets, submitted through the Delayed Inbox. Typically completes in minutes." - "L2 → L1 via the ArbSys precompile. Subject to the 7-day challenge period before it can be executed on Ethereum." "Robinhood Chain is an Arbitrum Chain, so messaging uses the standard Arbitrum Nitro mechanisms. We recommend the Arbitrum SDK (`@arbitrum/sdk`) rather than encoding messages by hand." ## Key contracts | Contract | Layer | Address | | --- | --- | --- | | Delayed Inbox | Ethereum (L1) | `0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D` | | Bridge | Ethereum (L1) | `0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3` | | Outbox | Ethereum (L1) | `0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9` | | Rollup | Ethereum (L1) | `0x23A19d23e89166adedbDcB432518AB01e4272D94` | | ArbSys | Robinhood Chain (L2) | `0x0000000000000000000000000000000000000064` | Testnet equivalents are on [protocol contracts](protocol-contracts.md). ## Registering the chain with the Arbitrum SDK "Because Robinhood Chain is a custom Arbitrum chain, register it once before using the SDK": ```js import { registerCustomArbitrumNetwork } from "@arbitrum/sdk"; registerCustomArbitrumNetwork({ name: "Robinhood Chain", chainId: 4663, parentChainId: 1, // Ethereum mainnet confirmPeriodBlocks: 45818, ethBridge: { bridge: "0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3", inbox: "0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D", sequencerInbox: "0xBd0D173EEb87D57A09521c24388a12789F33ba96", outbox: "0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9", rollup: "0x23A19d23e89166adedbDcB432518AB01e4272D94", }, }); ``` `confirmPeriodBlocks: 45818` and `sequencerInbox` appear only in this snippet — the sequencer inbox address matches the Core contracts table. ## L1 → L2: retryable tickets "To send a message from Ethereum to a contract on Robinhood Chain, create a retryable ticket through the Delayed Inbox. The Arbitrum SDK handles gas estimation and submission": ```js import { ParentToChildMessageCreator } from "@arbitrum/sdk"; const messageCreator = new ParentToChildMessageCreator(parentSigner); // an Ethereum signer const tx = await messageCreator.createRetryableTicket( { to: "0x...", // target contract on Robinhood Chain data: "0x...", // calldata l2CallValue: 0n, from: await parentSigner.getAddress(), }, childProvider // a Robinhood Chain provider ); await tx.wait(); ``` Failure handling: "If the L2 execution fails (for example, due to insufficient gas), the ticket is not lost — it can be redeemed manually within 7 days." Preserve both halves of that statement — the ticket survives, but only for a bounded window and only if someone redeems it. ## Address aliasing The single most common source of broken access control across the L1→L2 boundary: > "When an L1 contract calls an L2 contract via a retryable ticket, the > `msg.sender` seen on Robinhood Chain is not the original L1 address — it is > the aliased address (the L1 address plus a fixed offset). Account for this in > any access-control logic that checks the caller. Use the SDK's `applyAlias` / > `undoAlias` helpers to convert between the two." The Differences from Ethereum page repeats the same warning, so this is multi-source within the docs. The sources do not publish the numeric offset value; use the SDK helpers rather than hardcoding one. ## L2 → L1: ArbSys and the Outbox "Sending a message from Robinhood Chain to Ethereum is a two-step process: initiate on L2, then execute on L1 after the challenge period." ### Step 1 — initiate on Robinhood Chain ```js import { ArbSys__factory } from "@arbitrum/sdk"; const arbSys = ArbSys__factory.connect( "0x0000000000000000000000000000000000000064", childSigner // a Robinhood Chain signer ); const tx = await arbSys.sendTxToL1( destinationL1Address, // target contract on Ethereum data, // calldata { value: 0n } ); const receipt = await tx.wait(); ``` "This method removes the necessity for custom wrapper contracts." From your own contract: "it can call `ArbSys(0x…64).sendTxToL1(...)` directly." ### Step 2 — execute on Ethereum "Once the 7-day challenge period concludes, final execution occurs on L1 by claiming the message through the Outbox." ```js import { ChildTransactionReceipt } from "@arbitrum/sdk"; const childReceipt = new ChildTransactionReceipt(receipt); const [message] = await childReceipt.getChildToParentMessages(parentSigner); // This promise resolves only after the challenge window expires await message.waitUntilReadyToExecute(childProvider); await message.execute(parentSigner); ``` The comment in the source is load-bearing: `waitUntilReadyToExecute` "resolves only after the challenge window expires." There is no documented fast path. ## Timing expectations | Direction | Documented latency | | --- | --- | | L1 → L2 (retryable ticket) | "Typically completes in minutes" | | L1 → L2 failed ticket redemption window | 7 days | | L2 → L1 (ArbSys → Outbox) | 7-day challenge period, then an L1 execute transaction | **Analysis:** the asymmetry is structural, not a tuning parameter — the 7-day window is the fraud-proof challenge period of Arbitrum's rollup design, the same period that governs canonical-bridge withdrawals. A design that needs a synchronous L2→L1 round trip cannot be built on this primitive; L2→L1 is a one-way notification with a week-long settlement tail. ## Related pages - [Bridging](bridging.md) — moving assets rather than messages - [Protocol contracts](protocol-contracts.md) - [Deploying contracts](deploying-contracts.md) — aliasing in access-control code --- title: "Chainlink Data Streams on Robinhood Chain" type: concept tags: [chainlink, data-streams, verifier-proxy, pull-oracle, low-latency] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-data-streams-robinhood-chain-documentation.md", "raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md", "raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md"] confidence: medium --- # Chainlink Data Streams on Robinhood Chain ## Definition "Chainlink Data Streams are a secure, fast, and high-performance pull-based oracle solution delivering real-time market data with sub-second latency. Data is streamed and maintained offchain for speed, then cryptographically signed and verified onchain when requested. This approach provides fast, flexible, and secure access to high-frequency data." Values on this page reflect `docs.robinhood.com/chain` **as documented on 2026-09-09**. ## Push vs Pull — Why Both Exist Here Robinhood Chain documents two distinct Chainlink products, and they solve different problems: | | Data Feeds | Data Streams | | --- | --- | --- | | Model | Push-based — the network publishes onchain and consumers read the latest answer | Pull-based — data lives offchain and is fetched, then verified onchain at the moment of use | | Latency | Governed by heartbeat and deviation thresholds | "Sub-second latency for high-frequency updates" | | Onchain cost | Paid by the publisher on every update | "Pull-based architecture that reduces unnecessary onchain costs" | | Consumer call | `latestRoundData()` on a feed proxy | `verify()` on the Verifier Proxy, passing a signed report | Chainlink's Robinhood tokenized equity page confirms the feeds side is "push-based". See [oracles-and-price-feeds.md](oracles-and-price-feeds.md). **Analysis:** the design difference that matters is *who pays and when*. A push feed's cost is amortised across all readers and its freshness is fixed by the feed's own update policy; a Streams report is only paid for when a transaction actually needs it, and its freshness is bounded by how recently the caller fetched it. That makes Streams the documented fit for the workloads below and a poor fit for a contract that simply wants to read a price in a `view` function with no offchain component. ## What It Enables "Data Streams supports advanced DeFi applications such as perpetual futures, options trading, automated liquidations, and high-frequency strategies that require rapid reaction to market changes. By decoupling data delivery from onchain writes, Data Streams significantly reduces costs while enabling real-time responsiveness." The documented benefits, verbatim: - "Sub-second latency for high-frequency updates" - "Pull-based architecture that reduces unnecessary onchain costs" - "Cryptographic verification for trust-minimized data usage" - "Multi-region, high-availability infrastructure" - "Flexible integration for both onchain and offchain processes" ## The Robinhood Chain Deployment This is the one chain-specific value the page publishes: > "For the Robinhood Chain Mainnet (chain ID 4663), the verifier proxy is located at the following address:" | Network | Verifier Proxy Address | | --- | --- | | Robinhood Chain | `0xcE73c8ad08CBDEaCa6078BF0627C8fe0a9a536E7` | "Developers should invoke the `verify()` function on this specific contract to authenticate signed reports on-chain prior to execution." Two limits of this source, stated so nobody fills them in from memory: - **No testnet verifier proxy address is documented.** The table has a single row, mainnet only. The wording "Robinhood Chain Mainnet (chain ID 4663)" is specific to mainnet; nothing in the capture covers chain ID 46630. - **No `verify()` signature, report schema, feed ID, or stream ID is documented on this page.** The function name is given; its parameters and return type are not. Take those from Chainlink's Data Streams documentation. ## Developer Tooling The documented tooling, verbatim: - "Data visualization dashboards at `https://data.chain.link/streams`" - "SDKs in Go, TypeScript, and Rust" - "REST and WebSocket data access endpoints" - "Onchain verifier contract for report validation" No REST base URL, WebSocket endpoint, SDK package name, or version is given in the capture. The endpoints exist per the docs; their addresses are not published here and are not reconstructed. ## Availability "For real-time availability updates, refer to the Chainlink network status page for Robinhood Chain." **Analysis:** the phrasing is an availability pointer rather than an availability guarantee. Combined with the absence of a documented stream catalogue for this chain, the safe assumption is that *which* streams are live on Robinhood Chain must be checked against Chainlink directly — the presence of a verifier proxy establishes that report verification is deployed, not that any particular asset has a stream. ## What This Page Does Not Cover The capture is a single short overview page. It does not document: billing or fee tokens for Streams on this chain, report staleness semantics, the relationship (if any) between a Stock Token's push feed and any Streams equivalent, or whether Stock Tokens have Data Streams coverage at all. Nothing on the Stock Token pages references Data Streams. Do not infer Stock Token stream coverage from this page. ## Related Concepts - [oracles-and-price-feeds.md](oracles-and-price-feeds.md) — the push-based Data Feeds path, including the oracle pause behaviour - [building-with-stock-tokens.md](building-with-stock-tokens.md) - [what-is-robinhood-chain.md](what-is-robinhood-chain.md) — Chainlink's role in the ecosystem and on the Security Council ## Sources - `raw/web_community-data-streams-robinhood-chain-documentation.md` - `raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md` - `raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md` --- title: "Deploying Contracts to Chain 4663" type: concept tags: [deployment, foundry, hardhat, verification, evm] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-deploy-a-contract-robinhood-chain-documentation.md", "raw/web_community-differences-from-ethereum-robinhood-chain-documentation.md", "raw/web_community-connecting-to-robinhood-chain-robinhood-chain-documentation.md", "raw/web_community-gas-fees-robinhood-chain-documentation.md", "raw/web_community-about-robinhood-chain-robinhood-chain-documentation.md"] confidence: medium --- # Deploying Contracts to Chain 4663 Robinhood Chain "is fully EVM-compatible, so smart contracts written in Solidity or Vyper deploy without modification using standard Ethereum tooling." Hardhat, Foundry, ethers.js, viem and Wagmi all work. This page covers the chain-specific values and the behavioral gotchas, as documented on 2026-09-09. ## Network values | Property | Mainnet | Testnet | | --- | --- | --- | | Network | Robinhood Chain | Robinhood Chain Testnet | | Chain ID | `4663` | `46630` | | RPC URL | `https://rpc.mainnet.chain.robinhood.com` | `https://rpc.testnet.chain.robinhood.com` | | Block Explorer | `robinhoodchain.blockscout.com` | `explorer.testnet.chain.robinhood.com` | Gas is paid in ETH — "Robinhood Chain uses ETH as its native gas token." You need "A wallet with ETH on Robinhood Chain for gas" before deploying; see [bridging](bridging.md) to get it there. The docs recommend testnet first: "to deploy to testnet instead, use the testnet values above: set `RH_RPC_URL` to the testnet RPC, use chain ID 46630, and verify against `https://explorer.testnet.chain.robinhood.com/api/`." Security note from the docs, reproduced: "Never commit a real private key. Use an environment variable, and prefer a throwaway deployer key for testing." ## Foundry ```bash export PRIVATE_KEY=0x export RH_RPC_URL=https://rpc.mainnet.chain.robinhood.com forge create HelloRobinhood \ --rpc-url $RH_RPC_URL \ --private-key $PRIVATE_KEY \ --broadcast ``` Verification targets Blockscout, not Etherscan: ```bash forge verify-contract \ src/HelloRobinhood.sol:HelloRobinhood \ --chain-id 4663 \ --rpc-url $RH_RPC_URL \ --verifier blockscout \ --verifier-url https://robinhoodchain.blockscout.com/api/ ``` "After verification, view your contract at `https://robinhoodchain.blockscout.com/address/`." ## Hardhat The `customChains` block is required — Hardhat's `etherscan` plugin needs to be pointed at Blockscout, with a dummy API key: ```js module.exports = { solidity: "0.8.13", networks: { robinhood: { url: process.env.RH_RPC_URL, chainId: 4663, accounts: [process.env.PRIVATE_KEY], }, }, etherscan: { apiKey: { robinhood: "empty" }, customChains: [ { network: "robinhood", chainId: 4663, urls: { apiURL: "https://robinhoodchain.blockscout.com/api", browserURL: "https://robinhoodchain.blockscout.com/", }, }, ], }, }; ``` Then `npx hardhat run scripts/deploy.js --network robinhood` and `npx hardhat verify --network robinhood `. Note the verifier URL differs by one trailing slash between the two tools as published: Foundry's `--verifier-url` ends `/api/`, Hardhat's `apiURL` ends `/api`. Both are reproduced here exactly as documented. ## Chain-specific gotchas that affect contract code These are the documented divergences from Ethereum mainnet. "Understanding these prevents subtle bugs." ### Contract size limits are larger, not smaller "Robinhood Chain allows larger contracts than Ethereum — a maximum code size of 96 KB (vs. Ethereum's 24 KB) and a max init code size of 192 KB. Contracts that exceed Ethereum's limit can deploy here." **Analysis:** this cuts the other way for portability — a contract that fits on 4663 is not guaranteed to deploy on Ethereum L1. ### `block.number` is not the L2 block number "`block.number` returns an estimate of the L1 (Ethereum) block number, not the Robinhood Chain block number, and updates only periodically. Do not use it to measure L2 time precisely or as a per-block counter." ```solidity uint256 l2Block = ArbSys(0x0000000000000000000000000000000000000064).arbBlockNumber(); ``` ### No usable on-chain randomness "`block.prevrandao` / `block.difficulty` return a constant value on Robinhood Chain and are not a source of randomness. Never use them for randomness — use a dedicated oracle (e.g. Chainlink VRF) instead." `blockhash(n)` "is supported but is only reliable for recent blocks. Do not rely on it for older blocks or as a randomness source." ### `block.coinbase` "returns the network fee account, not a miner/validator address." ### Address aliasing breaks naive access control "When an L1 contract sends a message to a contract on Robinhood Chain, the `msg.sender` seen on L2 is the aliased L1 address (the original address plus a fixed offset), not the original. Account for this in access-control logic." See [cross-chain messaging](cross-chain-messaging.md) for `applyAlias` / `undoAlias`. ### Gas estimation behaves differently A fee has two components — L2 execution gas plus "an L1 data (calldata) fee for posting the transaction to Ethereum. Gas estimation and `gasleft()` behave differently than on Ethereum as a result." Both components "are bundled into the gas your transaction pays — you don't pay them separately," and `eth_estimateGas` "automatically accounts for both." Because the L1 data fee scales with calldata size, the documented optimizations are: "Pack function arguments tightly. Avoid unnecessary data in calls. Batch operations where possible." ### No priority-fee ordering "Robinhood Chain employs a **first-come, first-served** model based on sequencer arrival time. Priority gas auctions do not exist here; consequently, increasing your fee will not shift your transaction ahead of others already in the queue." Do not build contracts or bots that assume fee-based ordering. ### Transactions can be excluded before they execute "Robinhood Chain maintains compliance standards through sequencer-level screening. While rare, this mechanism can influence smart-contract execution; for instance, any transaction associated with a sanctioned address will be excluded from inclusion." Reads (`eth_call`, `eth_getLogs`, balance queries) "remain fully accessible and unaffected," and "a blocked transfer is never processed, it simply appears as though the event never occurred." See [access controls](access-controls-registry.md). ## Confirmation model for deploy scripts A deploy receipt is a *soft confirmation*: "The sequencer has committed to your transaction's inclusion and ordering. Reversible only if the sequencer posts a batch with a different transaction order." Full Ethereum finality arrives "~13 minutes after posting" the batch to L1. For most deploys the soft confirmation is what tooling waits on; for high-value or irreversible steps the docs advise waiting for L1 posting or Ethereum finality. ## RPC choice The public endpoints are "rate-limited and not recommended for production use." Alchemy is "the recommended infrastructure provider" (`https://robinhood-mainnet.g.alchemy.com/v2/{API_KEY}`); QuickNode, Blockdaemon, dRPC and Validation Cloud are also listed. For historical reads during scripted deployments, "use an archive endpoint." ## Related pages - [Protocol contracts](protocol-contracts.md) — precompile addresses - [Running a node](running-a-node.md) - [Doppler launches](doppler-launches.md) — launching a token without writing contracts --- title: "Differences from Ethereum" type: concept tags: [evm, arbitrum-nitro, precompiles, solidity, gotchas] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-differences-from-ethereum-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-contracts-robinhood-chain-documentation.md", "raw/web_community-cross-chain-messaging-robinhood-chain-documentation.md", "raw/web_community-about-robinhood-chain-robinhood-chain-documentation.md"] confidence: medium --- # Differences from Ethereum ## Definition "Robinhood Chain is EVM-compatible — contracts written in Solidity or Vyper deploy without modification, and standard tooling works out of the box. However, as an Arbitrum Nitro Layer-2, a few behaviors differ from Ethereum mainnet. Understanding these prevents subtle bugs." This page reflects `docs.robinhood.com/chain` **as documented on 2026-09-09**. The differences fall into three groups: EVM opcode semantics that silently return something other than what you expect, protocol-level ordering and screening behaviour, and raised limits. ## Block and Time Semantics ### `block.number` is an L1 estimate "`block.number` returns an estimate of the L1 (Ethereum) block number, not the Robinhood Chain block number, and updates only periodically. Do not use it to measure L2 time precisely or as a per-block counter." For the real L2 block number, call the `ArbSys` precompile: ```solidity uint256 l2Block = ArbSys(0x0000000000000000000000000000000000000064).arbBlockNumber(); ``` This is the highest-risk difference for ported contracts: vesting schedules, rate limiters, auction clocks and cooldowns keyed on `block.number` will tick at Ethereum's cadence, not the L2's, and will do so in irregular jumps. ### `block.prevrandao` / `block.difficulty` are constant "`block.prevrandao` / `block.difficulty` return a constant value on Robinhood Chain and are not a source of randomness. Never use them for randomness — use a dedicated oracle (e.g. Chainlink VRF) instead." The polarity here is absolute in the source — "never", not "prefer not to". A contract that seeds randomness from these values is deterministic and predictable on this chain. ### `blockhash(n)` is recent-only "`blockhash(n)` is supported but is only reliable for recent blocks. Do not rely on it for older blocks or as a randomness source." The docs do not state the exact recency window. ### `block.coinbase` "`block.coinbase` returns the network fee account, not a miner/validator address." ## Gas Semantics "Transaction fees have two components: L2 execution gas plus an L1 data (calldata) fee for posting the transaction to Ethereum. Gas estimation and `gasleft()` behave differently than on Ethereum as a result. Query gas pricing via the ArbGasInfo precompile." Full treatment in [gas-and-fees.md](gas-and-fees.md). ## Transaction Ordering "On Ethereum, miners or validators order transactions based on priority fees, where higher payments typically secure earlier inclusion. Robinhood Chain employs a **first-come, first-served** model based on sequencer arrival time. Priority gas auctions do not exist here; consequently, increasing your fee will not shift your transaction ahead of others already in the queue." **Analysis:** this removes the fee-bidding channel that a large amount of Ethereum-native tooling assumes — RBF-style fee bumps to jump a queue, priority-fee bidding for liquidation or arbitrage priority, and gas-auction-based MEV. What it does not remove is latency competition: the documented determinant of ordering is arrival time at the sequencer. ## Transaction Screening This has no Ethereum equivalent and is quoted here in full because its consequences for indexers and contract logic are specific: "Robinhood Chain maintains compliance standards through sequencer-level screening. While rare, this mechanism can influence smart-contract execution; for instance, any transaction associated with a sanctioned address will be excluded from inclusion. Standard read operations—such as `eth_call`, `eth_getLogs`, or balance queries—remain fully accessible and unaffected. Since a blocked transfer is never processed, it simply appears as though the event never occurred, ensuring indexers remain synchronized with the actual state." **Analysis:** the failure mode to design for is a submitted transaction that never appears at all, rather than a transaction that reverts. Client code that waits indefinitely for a receipt, or that treats "no receipt" as "still pending", needs a timeout path. Onchain state and logs remain consistent, so indexers do not need special handling — the docs are explicit on that point. The Differences page links onward to a page titled "Advanced Compliance Filtering". **That page is not part of this capture**, so any further detail on the screening mechanism is unavailable from these sources. ## Address Aliasing "When an L1 contract sends a message to a contract on Robinhood Chain, the `msg.sender` seen on L2 is the aliased L1 address (the original address plus a fixed offset), not the original. Account for this in access-control logic." The Cross-Chain Messaging page adds the tooling: "Use the SDK's `applyAlias` / `undoAlias` helpers to convert between the two." Note the aliasing applies to L1 *contracts*; the docs describe the offset as fixed but do not state its value. Access-control checks of the form `require(msg.sender == knownL1Owner)` will fail on this chain unless the alias is applied. ## Raised Limits "Robinhood Chain allows larger contracts than Ethereum — a maximum code size of **96 KB** (vs. Ethereum's 24 KB) and a max init code size of **192 KB**. Contracts that exceed Ethereum's limit can deploy here." This is a one-way compatibility difference: a contract that deploys here may not deploy on Ethereum. ## Arbitrum Precompiles "Robinhood Chain provides Arbitrum-specific precompiles (ArbSys, ArbGasInfo, ArbAddressTable, and others) for L2-specific functionality." The addresses are identical on mainnet and testnet: | Precompile | Address | | --- | --- | | `ArbInfo` | `0x0000000000000000000000000000000000000065` | | `ArbAddressTable` | `0x0000000000000000000000000000000000000066` | | `ArbFunctionTable` | `0x0000000000000000000000000000000000000068` | | `ArbOwnerPublic` | `0x000000000000000000000000000000000000006b` | | `ArbGasInfo` | `0x000000000000000000000000000000000000006C` | | `ArbAggregator` | `0x000000000000000000000000000000000000006D` | | `ArbRetryableTx` | `0x000000000000000000000000000000000000006E` | | `ArbStatistics` | `0x000000000000000000000000000000000000006F` | | `ArbOwner` | `0x0000000000000000000000000000000000000070` | | `ArbWasm` | `0x0000000000000000000000000000000000000071` | | `ArbWasmCache` | `0x0000000000000000000000000000000000000072` | | `ArbSys` | `0x0000000000000000000000000000000000000064` | | `NodeInterface` | `0x00000000000000000000000000000000000000C8` | Casing is reproduced exactly as published (note the lowercase `b` in `ArbOwnerPublic` and the uppercase letters elsewhere — these are not checksummed addresses and the casing carries no meaning, but it is preserved here to match the source). ## Finality "Transactions receive a fast soft confirmation from the sequencer, then achieve hard finality once posted to and confirmed on Ethereum." See [transaction-finality.md](transaction-finality.md). ## Porting Checklist 1. Replace `block.number` with `ArbSys.arbBlockNumber()` wherever L2 block counting is meant. 2. Remove any randomness derived from `prevrandao`, `difficulty`, or `blockhash`. 3. Alias L1 sender addresses in access control. 4. Re-audit `gasleft()` and fixed-gas forwarding. 5. Drop fee-priority assumptions. 6. Handle "transaction never included" as a distinct outcome from "transaction reverted". ## Related Concepts - [gas-and-fees.md](gas-and-fees.md) - [transaction-finality.md](transaction-finality.md) - [what-is-robinhood-chain.md](what-is-robinhood-chain.md) ## Sources - `raw/web_community-differences-from-ethereum-robinhood-chain-documentation.md` - `raw/web_community-robinhood-chain-contracts-robinhood-chain-documentation.md` - `raw/web_community-cross-chain-messaging-robinhood-chain-documentation.md` - `raw/web_community-about-robinhood-chain-robinhood-chain-documentation.md` --- title: "Doppler Token Launches on Chain 4663" type: concept tags: [doppler, token-launch, auctions, liquidity-migration, fees] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/llms_txt_doc-contract-addresses.md", "raw/llms_txt_doc-explainer.md", "raw/llms_txt_doc-creation-initialization.md", "raw/llms_txt_doc-price-discovery-auctions.md", "raw/llms_txt_doc-supply-curves.md", "raw/llms_txt_doc-liquidity-migration.md", "raw/llms_txt_doc-doppler-hooks.md", "raw/llms_txt_doc-fee-rehypothecation.md", "raw/llms_txt_doc-multicurve.md", "raw/llms_txt_doc-quotes-swaps.md", "raw/web_community-uniswap-v4-deployments-uniswap-developers.md"] confidence: medium --- # Doppler Token Launches on Chain 4663 Doppler is "an onchain protocol for launching tokens through various price discovery auctions." It is deployed on Robinhood Chain and is the launch mechanism behind new tokens there. Documented as of 2026-09-09. ## Scoping warning: read this first **Doppler's documentation is written multi-chain, and almost every behavioral statement and code example in it is generic or explicitly scoped to Base.** The only things the captured Doppler sources scope to Robinhood Chain (4663) are: 1. The deployment address table under the heading "Robinhood Mainnet (4663)". 2. "Robinhood Mainnet" appearing in the list of networks Doppler is "officially deployed to". 3. The Universal Router version: "`2.1.1` on Robinhood (chain ID `4663`)" — versus "`2.0` on every other supported network." Everything else on this page — auction types, migration options, hook callbacks, fee splits, the 5% protocol fee — is reproduced from chain-agnostic Doppler documentation. **The sources do not state that these behaviors are identical on 4663**, and several documented features are explicitly conditional on which contracts a chain has ("Some optional contracts … may be `0x0` on certain chains"). Verify against the deployed contracts on 4663 before relying on any of it. The docs also carry a canonicality warning: "If there are contracts not reflected here but claiming to be instances of Doppler, they are not considered canonical. Use with caution." ## Deployed contracts on Robinhood Mainnet (4663) Reproduced from the "Robinhood Mainnet (4663)" table. Addresses are given here exactly as they appear in the explorer links of that table (lowercase). Every row was deployed at commit `bda077cf`, except `Bundler`, `Quoter` and `RehypeDopplerHookInitializer` (`c333674f`) and `RehypeDopplerHookMigrator` (`6a0ff821`). | Contract | Address (chain 4663) | | --- | --- | | Airlock | `0xeb7c034704ef8dcd2d32324c1545f62fb4ad0862` | | Bundler | `0xf45588e8e0b1df9db9ae7e20ece5726ae931357c` | | DN404Factory | `0x37a9fa204a4d3a429fded7e3469ab076c854bc9d` | | DopplerCreateXDeployer | `0x103004e50bed65dfba30dd9c264b6bdf5e529b83` | | DopplerDeployer | `0x4389ad34938b14f25cff7ed983c53f5a42a2573f` | | DopplerERC20V1 | `0x3be8b97fd0e713b5abe0649fa830223b6b4bc599` | | DopplerERC20V1Factory | `0x1b37d3a72082029c44b35b604ea473617580b69a` | | DopplerHookInitializer | `0x4e3468951d49f2eea976ed0d6e75ffcb44a9a544` | | DopplerHookMigrator | `0x7bf319d8e969f7596b1bc171da9ce322f67ae0c4` | | DopplerLensQuoter | `0xf4c22465532f64777ffcd7770831aeca38f35c04` | | GovernanceFactory | `0xdeb0447dae3eb177c4dba8bbccca25c8f273b7ef` | | LaunchpadGovernanceFactory | `0xdb036746d65dd52126b1915f1adf555e6c5237cf` | | LockableUniswapV3Initializer | `0xde8886a0019ea060b8378ee37b8a23b8117f29a3` | | NoOpGovernanceFactory | `0x85f37f74ef2478a770318bc810177a9835911ad7` | | NoOpMigrator | `0xba2f330edb16cd8056f5988d8ce19bbc63475a0e` | | Quoter | `0xce6cd4e35447e05a39a50a4bcf61f2dcd93a8f0d` | | RehypeDopplerHookInitializer | `0x5f9eb5f6726fe88d5e39867967f5b833d2fa3215` | | RehypeDopplerHookMigrator | `0x660740d7d6fb2c8998fa3fff459cceb9ac12c84b` | | StreamableFeesLockerV2 | `0x7b6147ac3f615bdb764e7ebd5f517dac1ad163b8` | | SwapRestrictorDopplerHook | `0xc16c826f75338a5ea626f94f8992191b4ce5aba2` | | TimelockFactory | `0x6076fddfcac0dd980e0350dff5239fec3f86c578` | | TopUpDistributor | `0x46adee7595d48b1ec53090e9bc78e1e69fa0ef06` | | UniswapV2Locker | `0x63f6efe03f25a8c6650b38d05c5a454051d642a5` | | UniswapV2MigratorSplit | `0xb05046cea797c993fb5b583098b1c4682e9da333` | | UniswapV4Initializer | `0x6cce158b6d1747617fc218592b4d60b239b957ea` | Observations that are chain-specific facts, not inferences: the 4663 table contains `DN404Factory`, `DopplerLensQuoter` and `SwapRestrictorDopplerHook`, none of which appear in the Ethereum Mainnet table; and it contains no `UniswapV3Initializer` row (only `LockableUniswapV3Initializer`). Uniswap v4 infrastructure on 4663, from Uniswap's own deployments page under "Robinhood Chain: 4663": | Contract | Address | | --- | --- | | PoolManager | `0x8366a39cc670b4001a1121b8f6a443a643e40951` | | PositionDescriptor | `0x9639443158e8c5efa35bd45287bf2effd3d8dc06` | | PositionManager | `0x58daec3116aae6d93017baaea7749052e8a04fa7` | | Quoter | `0x8dc178efb8111bb0973dd9d722ebeff267c98f94` | | StateView | `0xf3334192d15450cdd385c8b70e03f9a6bd9e673b` | | ReservesLens | `0x0000001b173C3bbF3984D417d8614E3eed34865B` | | Universal Router | `0x8876789976decbfcbbbe364623c63652db8c0904` | | Permit2 | `0x000000000022D473030F116dDEE9F6B43aC78BA3` | Doppler warns against substituting a router: "Do not substitute a same-chain Universal Router from another address registry. Each Universal Router deployment is connected to a specific V4 `PoolManager`. Another router on the same chain may use a different `PoolManager`, where the Doppler pool is not initialized." ## The Airlock create flow All launches funnel through one contract: "Doppler's Airlock smart contract provides a unified interface for interacting with the protocol. Users pass their desired parameters into the Airlock, which then manages all interactions with downstream contracts - including token factories, hook initializers, governance factories, and any other contracts configured for a given launch." See [the Airlock entity page](../entities/doppler-airlock.md) — including what the captured sources do *not* document about it. The documented high-level flow is: "1. Configure token + economics 2. Deploy via SDK or App 3. Run price discovery auction 4. Finalize and migrate liquidity 5. Market becomes live on target AMM." ## Initializers and auction types "Doppler currently supports three different kinds of price discovery auctions": | Type | Description | Factory method | | --- | --- | --- | | Static | "allow specifying a single supply or price curve" — "Uniswap V3 style, fixed price range liquidity bootstrapping" | `sdk.factory.createStaticAuction(params)` | | Multicurve | "allow specifying multiple supply or price curves" — "Uniswap V4 initializer with multiple curves" | `sdk.factory.createMulticurve(params)` | | Dynamic | "allow specifying ranges for dynamically adjusting supply or price curves" — "Uniswap V4 hook, dynamic Dutch auction with epoch steps" | `sdk.factory.createDynamicAuction(params)` | A fourth builder exists, the Opening Auction: "An auction used to place single sided LP positions in advance of a Doppler Dynamic auction. It can be used to mitigate sniping or more effectively set the clearing price prior to other price discovery auctions." Dynamic auctions are Dutch auctions: "the price starts high and descends over time through epochs until buyers purchase or the auction ends." The initializer contracts present on 4663 are `UniswapV4Initializer`, `LockableUniswapV3Initializer`, `DopplerHookInitializer` and `RehypeDopplerHookInitializer`. ## Supply curves "In Doppler, **supply curves** define how token price changes relative to the amount sold during a price discovery auction. Instead of a single fixed price, a supply curve maps cumulative tokens sold to price." Multicurve rules, stated three times across the sources: - "First curve's `marketCap.start` = the launch price" - "Curves must be contiguous or overlapping (no gaps)" - "Shares must sum to exactly 1e18 (100%)" - "**Tail curve (recommended)**: A final curve with `end: 'max'` and `numPositions: 1` ensures price continuity beyond the bonding curve. The tail's `start` must match the previous curve's `end`." Guidance on choice: "**Multicurve** → Phased launches with differentiated pricing. Well suited for low value assets… considered a *strict* improvement over static… **Dynamic** → Demand/time-sensitive markets. Well suited for high value assets." Fee tier / tick spacing pairs: "100→1, 500→10, 3000→60, 10000→200." ## Migration and graduation "After a price discovery auction completes, the liquidity proceeds generated in the price discovery auction can be migrated into a different DeFi protocol or automated market maker." Triggers are "configurable at creation, typically based on proceeds thresholds." `MigrationConfig` is a discriminated union: ```ts export type MigrationConfig = | { type: 'noOp' } | { type: 'uniswapV2' } | { type: 'uniswapV3'; fee: number; tickSpacing: number } | { type: 'uniswapV4' fee: number tickSpacing: number streamableFees: { lockDuration: number // seconds beneficiaries: { beneficiary: Address; shares: bigint }[] // shares in WAD (1e18 = 100%) } } ``` Constraints, verbatim: - **noOp** — the docs mark non-migration "(r*ecommended*)". "Supported on: UniswapV4MulticurveInitializer, LockableUniswapV3Initializer (Static auctions only)". "**Note:** `noOp` migration is NOT supported for Dynamic auctions - the SDK will throw an error if you try to use it." - **V3** — "Ensure `tickSpacing` matches the selected `fee` tier on your chain." - **V4** — validation requires "At least one beneficiary", "Shares must sum to exactly 1e18 (100%)", and "Contract enforces: airlock owner must receive at least 5% of streamed fees". "The SDK sorts beneficiaries by address (ascending) as required by the contract." Chain-support caveat, directly relevant to 4663: "Ensure `streamableFeesLocker` and `v4Migrator` are deployed on your target chain… Some optional contracts (`noOpGovernanceFactory`, `streamableFeesLocker`) may be `0x0` on certain chains — avoid V4 migration with fee streaming where not supported." The 4663 table lists `NoOpGovernanceFactory` and `StreamableFeesLockerV2` at non-zero addresses; the sources do not confirm that `StreamableFeesLockerV2` is what the SDK resolves as `streamableFeesLocker` on this chain, so check `getAddresses(4663)` before assuming. Graduation is the hook-level event: `onGraduation` fires from `graduate` "if the graduation conditions are met (e.g. `farTick` reached)". Auction state is readable via `auction.hasGraduated()`. ## Doppler Hooks "Doppler Hooks, aka dhooks, are a set of callback functions that can be called during the lifecycle of 'locked' pools initialized by the `DopplerHookInitializer` contract." Three triggers: `initialization`, `swap`, `graduation`. | Callback | Triggered by | | --- | --- | | `onInitialization(address asset, PoolKey calldata key, bytes calldata data` | `initialize()` if a `dopplerHook` address is set in the `InitData`; `setDopplerHook()` if a Doppler Hook is set after the pool initialization | | `onSwap(address sender, PoolKey calldata key, IPoolManager.SwapParams calldata params,BalanceDelta delta, bytes calldata data) returns (Currency feeCurrency, int128 hookDelta)` | `afterSwap` before each swap happening in the Uniswap V4 pool | | `onGraduation(address asset, PoolKey calldata key, bytes calldata data)` | `graduate` if the graduation conditions are met (e.g. `farTick` reached) | (The `onInitialization` signature is reproduced exactly as published, including its unbalanced parenthesis, and the `onSwap` trigger text as published says "`afterSwap` before each swap" — an apparent inconsistency in the source that is preserved rather than corrected.) Mutability of the hook binding — permission-relevant: - "A pool initialized without a Doppler Hook can opt-in to use one later via the `setHook` function" - "A pool initialized with a Doppler Hook can opt-out of using it later by setting the hook address to `address(0)`" - "A pool can change its associated Doppler Hook to a different one at any time via the `setHook` function" - "Doppler Hooks are approved by the protocol multisig" - "A pool without a Doppler Hook cannot be initialized with a dynamic LP fee" "pools associated with a Doppler Hook can have their LP fee updated by the associated timelock governance contract or a delegated address." ## Fees "Every token can be created with a unique set of beneficiary addresses that earn earn fees on every swap in pools created by Doppler, forever. Fees can also optionally be configured to decay from the time they're created… for example, starting at 80% and decreasing linearly down to 1% over the first N seconds." Protocol fee: "The Doppler Protocol receives 5% of trading fees on EVM and 7.5% on Solana. For example, if a token is configured with a 1% trading fee, the protocol receives 0.05% of swap volume on EVM… A token configured with a 0% trading fee generates no protocol fees." (Stated generically for "EVM"; not scoped to 4663 in the source.) ### Fee rehypothecation "Rehype Pools use the **RehypeDopplerHookInitializer** to distribute trading fees across beneficiaries, LPs, and buyback destinations." Four categories that "must sum to 100%": Asset Buyback, Numeraire Buyback, Beneficiary, LP. Rules as published: - "**Distribution sum**: All four percentages must equal `WAD` (1e18)" - "**Distribution updates**: Only the fixed fee distribution controller can replace the eight-value config" - "**Beneficiary shares**: Must sum to `WAD`; protocol owner needs at least 5% … each beneficiary must collect their own fees by calling collectFees" - "**Hook whitelisting**: `hookAddress` must be enabled in `DopplerHookInitializer`" - "**Migration**: Use `noOp` - rehype pools don't migrate liquidity" - "**Pool status**: Enters 'Locked' (status = 2)" `setFeeDistribution` "replaces all eight values; it is not a partial update." The controller "is fixed at pool creation, so use an operational wallet or multisig that will remain available to sign updates" — and assigning it "to addresses such as `0xdead`" makes the config immutable. Fee collection is permissionless to trigger but not to receive: "Anyone can trigger fee collection; fees are distributed automatically to the initializer, but each address listed as a beneficiary must then claim their own fees from the initializer." ## Governance options per launch "Using OpenZeppelin's Governor, tokens can optionally be created with onchain token holder governance and treasury management." Selection: - `withGovernance({ type: 'noOp' })` — "The SDK throws if `noOpGovernanceFactory` is not deployed on the chain." - `withGovernance({ type: 'default' })` - `withGovernance({ type: 'custom', initialVotingDelay, initialVotingPeriod, initialProposalThreshold })` "Governance defaults to `noOp` on supported chains (all except Ink)." This is per-token governance and is unrelated to [chain governance](governance.md). ## Related pages - [Doppler Airlock](../entities/doppler-airlock.md) - [Deploying contracts](deploying-contracts.md) - [Token contracts](token-contracts.md) — Stock Tokens are issued by RHJ, not launched via Doppler --- title: "Gas and Fees on Robinhood Chain" type: concept tags: [gas, fees, calldata, arbgasinfo, layer-2] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-gas-fees-robinhood-chain-documentation.md", "raw/web_community-differences-from-ethereum-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-contracts-robinhood-chain-documentation.md", "raw/web_community-about-robinhood-chain-robinhood-chain-documentation.md"] confidence: medium --- # Gas and Fees on Robinhood Chain ## The Fee Model in One Paragraph "Robinhood Chain uses ETH as its native gas token. Transaction fees are denominated in ETH, the same as on Ethereum." Because it is a Layer-2 that posts its data to Ethereum, the docs state that a transaction fee has **two components** — an L2 execution fee and an L1 data fee. This page reflects `docs.robinhood.com/chain` **as documented on 2026-09-09**. ## The Two Fee Components ### L2 execution fee "the cost of executing your transaction on Robinhood Chain. This works like Ethereum gas (gas used × L2 gas price) and is typically very low and stable." ### L1 data fee "the cost of posting your transaction's data to Ethereum for data availability. This varies with Ethereum network congestion and is proportional to the size of your transaction's calldata." The Connecting page adds the data-availability mechanism: Robinhood Chain uses "Ethereum blobs for data availability." ## How the Two Components Are Charged The docs are direct about this: "Both components are bundled into the gas your transaction pays — you don't pay them separately. Standard fee estimation (`eth_estimateGas`, wallet fee previews) automatically accounts for both, so most developers don't need to handle them manually." **Analysis:** the practical implication for integrators is that you should not build your own two-part fee calculator on this chain unless you have a specific reason to. The documented default path is `eth_estimateGas`. Where you do need the raw pricing inputs, the docs point to the `ArbGasInfo` precompile. ## Reading Gas Pricing Onchain The Differences page says: "Query gas pricing via the ArbGasInfo precompile." The Protocol Contracts page gives the precompile addresses, which are the standard Arbitrum precompile addresses and are identical on mainnet and testnet: | Precompile | Address (mainnet and testnet) | | --- | --- | | `ArbGasInfo` | `0x000000000000000000000000000000000000006C` | | `NodeInterface` | `0x00000000000000000000000000000000000000C8` | | `ArbSys` | `0x0000000000000000000000000000000000000064` | | `ArbOwnerPublic` | `0x000000000000000000000000000000000000006b` | | `ArbRetryableTx` | `0x000000000000000000000000000000000000006E` | | `ArbStatistics` | `0x000000000000000000000000000000000000006F` | The Gas & Fees page's own "further reading" names exactly these two as the relevant ones: "Protocol Contracts — ArbGasInfo and NodeInterface precompiles." The captured docs do **not** publish a base fee floor, a minimum L2 gas price, a gas limit per block, or any numeric fee figure for Robinhood Chain. No such number should be quoted from this source set. ## `gasleft()` Behaves Differently From the Differences page: "Gas estimation and `gasleft()` behave differently than on Ethereum as a result" of the two-component fee model. Contracts that make assumptions about remaining gas — gas-forwarding patterns, `try`/`catch` around fixed gas stipends, gas-based griefing guards — are the code most likely to be surprised by this. ## Optimizing Fees The documented lever is calldata size, because the L1 data fee "scales with calldata size." The docs list three tactics verbatim: - "Pack function arguments tightly." - "Avoid unnecessary data in calls." - "Batch operations where possible (see Account Abstraction for batched UserOperations)." Batching via ERC-4337 UserOperations is covered in [account-abstraction.md](account-abstraction.md), which also documents gas *sponsorship* — a paymaster paying the fee on a user's behalf rather than reducing it. ## Fees Do Not Buy Ordering This is the property most likely to break an assumption carried over from Ethereum. From the About page: "Robinhood Chain utilizes a first-come, first-served sequencing model, where the order is determined strictly by the arrival time at the sequencer. The network ensures a transparent and predictable environment where no transaction can bypass others by paying higher fees." The Differences page states the consequence explicitly: "Priority gas auctions do not exist here; consequently, increasing your fee will not shift your transaction ahead of others already in the queue." **Analysis:** patterns that rely on fee-based priority — bumping the tip to win a liquidation race, replace-by-fee to jump a queue, priority-fee-based MEV bidding — have no documented effect on inclusion order here. Latency to the sequencer, not fee level, is the documented determinant. See [differences-from-ethereum.md](differences-from-ethereum.md). Note also that `block.coinbase` "returns the network fee account, not a miner/validator address," so fee-recipient-based logic will not behave as it does on Ethereum. ## Where the Fee Money Goes The captured sources do not describe fee distribution, a fee recipient policy, sequencer revenue sharing, or any fee-burn mechanism for Robinhood Chain. The only related fact documented is the `block.coinbase` behaviour above. Do not infer a fee-distribution model from these sources. ## Practical Checklist for Integrators 1. Estimate with `eth_estimateGas` rather than hand-rolling a two-part model — the docs state it already accounts for both components. 2. Expect the variable part of your fee to track Ethereum congestion, not Robinhood Chain congestion, since the L1 data fee is the congestion-sensitive half. 3. Budget by calldata size when designing contract interfaces — it is the documented cost driver you control. 4. Do not port fee-priority logic from Ethereum. 5. Re-test any contract that reads `gasleft()` or forwards a fixed gas amount. ## Related Concepts - [differences-from-ethereum.md](differences-from-ethereum.md) — the full list of Nitro behavioural differences - [transaction-finality.md](transaction-finality.md) — what the fee buys you and when - [account-abstraction.md](account-abstraction.md) — batching and gas sponsorship - [connecting.md](connecting.md) — ETH as the native gas token ## Sources - `raw/web_community-gas-fees-robinhood-chain-documentation.md` - `raw/web_community-differences-from-ethereum-robinhood-chain-documentation.md` - `raw/web_community-robinhood-chain-contracts-robinhood-chain-documentation.md` - `raw/web_community-about-robinhood-chain-robinhood-chain-documentation.md` --- title: "Chain Governance, Validators and Upgrades" type: concept tags: [governance, security-council, validators, bold, upgrades] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-governance-robinhood-chain-documentation.md", "raw/web_community-notices-upgrades-robinhood-chain-documentation.md", "raw/web_community-run-a-robinhood-chain-full-node-robinhood-chain-documentatio.md", "raw/web_community-robinhood-chain-contracts-robinhood-chain-documentation.md", "raw/web_community-about-robinhood-chain-robinhood-chain-documentation.md"] confidence: medium --- # Chain Governance, Validators and Upgrades Robinhood Chain is governed by a fixed multi-institution Security Council, not by a token vote. Documented as of 2026-09-09. ## The Security Council > "Robinhood Chain's protocol is governed by a Security Council of eight > signers. Robinhood holds two of the eight seats, and the remaining six seats > are held by independent institutions who maintain robust security protocols > and have experience and credibility within the blockchain ecosystem." ### Thresholds | Action type | Approvals required | Timelock | | --- | --- | --- | | Routine | 6 of 8 signers | "subject to a seven-day on-chain timelock before execution" | | Emergency | 7 of 8 signers | "bypass the timelock" | Both halves matter: the emergency path is *harder* to reach (7 of 8 rather than 6 of 8) but executes *immediately*. There is no documented path by which fewer than six signers can act. Every signer "is required to maintain secure signing infrastructure, support key rotation, and use institutional-grade key management." ### Seat allocation | Seats | Participant | | --- | --- | | 1 | BitGo, Inc. | | 1 | Chainlink Labs | | 1 | Fireblocks Trust Company | | 1 | Offchain Labs | | 1 | Paxos | | 2 | Robinhood | | 1 | Talos | Seven distinct participants hold eight seats. Robinhood's two seats are below the three-seat blocking minority a 6-of-8 threshold implies. **Analysis:** with 6-of-8 required for routine actions, any three seats can block a routine upgrade; Robinhood alone holds two, so it can neither pass nor unilaterally block. The sources do not document the composition or governance of the Council beyond this table, nor a process for changing seats. ## Validators and dispute resolution > "Robinhood Chain uses BoLD (Bounded Liquidity Delay) for dispute resolution, > secured by a permissioned set of validators. Validators monitor on-chain > assertions and are capable of detecting and submitting fraud-proof challenges > against invalid state assertions." > > "Robinhood Chain currently has two validators, operated by Offchain Labs and > Alchemy." Note "currently" — the count is a point-in-time fact as of 2026-09-09, not a protocol parameter. The validator set is closed: "Operating a validator necessitates being included in the allowlist and staking a 1 WETH bond (defensive validators are highly encouraged)." Both the allowlist entry and the bond are required. See [running a node](running-a-node.md). The on-chain anchor for all of this is the Rollup contract on Ethereum L1, `0x23A19d23e89166adedbDcB432518AB01e4272D94` (see [protocol contracts](protocol-contracts.md)). ## Notices and upgrades The chain publishes a dedicated Notices & Upgrades page, which "lists network upgrade notices and configuration changes for Robinhood Chain." Who needs to act: - "Node operators should monitor this page — some upgrades require you to update your node before a scheduled activation." - "Developers should review notices for any behavior changes that could affect contracts or integrations." - "End users generally don't need to take action." ### How network upgrades work > "Robinhood Chain runs Arbitrum Nitro and periodically upgrades its ArbOS > version. These upgrades activate onchain at a scheduled time. Before each > activation, node operators must run a compatible Nitro node version — an > un-upgraded node stops cleanly at the upgrade block and resumes normally once > updated, with no data loss or resync required. Most upgrades require no > action from dApp developers or end users, though some include EVM or behavior > changes worth reviewing." Preserve the hedge: *most* upgrades require no dApp action; *some* include EVM or behavior changes. The failure mode for an un-upgraded node is a clean stop, not corruption — but it is still a stop. The chain runs **ArbOS 61** as documented on the run-a-node page on 2026-09-09. ### Notice list as captured The Notices table in the capture taken on 2026-09-09 has headers — Date, Notice, Status — and **no rows**. Either no notices were published as of that capture, or the table is rendered client-side and did not populate. Check the live page rather than treating this wiki as an upgrade calendar. ## What governance does not cover There is no token-holder governance of Robinhood Chain in any captured source — no governance token, no proposal process, no voting contract for the chain itself. (OpenZeppelin `Governor`-based governance appears in the sources only as an *optional per-token* feature of the Doppler launch protocol; see [Doppler launches](doppler-launches.md). That is application-level governance over a launched token's treasury, entirely separate from chain governance.) Sequencing policy is likewise not a governance output as documented: the chain "utilizes a first-come, first-served sequencing model, where the order is determined strictly by the arrival time at the sequencer." Administrative powers outside the Security Council — issuer control of Stock Token multipliers, the oracle pause flag, sequencer-level screening — are inventoried in [access controls](access-controls-registry.md). ## Related pages - [Access controls and admin powers](access-controls-registry.md) - [Running a node](running-a-node.md) - [Protocol contracts](protocol-contracts.md) --- title: "Oracles and Price Feeds" type: concept tags: [chainlink, price-feeds, aggregatorv3, staleness, oracle-pause] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md", "raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md", "raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-stock-tokens-robinhood-chain-documentation.md"] confidence: medium --- # Oracles and Price Feeds Robinhood Chain uses Chainlink for onchain price data. Two sources are cited here: Robinhood's own Oracles & Price Feeds page, and Chainlink's "Robinhood Tokenized Equities" documentation, which is the authoritative description of how these feeds are constructed. Both were captured **2026-09-09**; where they differ, both wordings are given rather than reconciled. ## What the Feed Actually Reports This is the point most likely to be got wrong: **the feed does not report the underlying share price.** Chainlink states it directly: > "The corresponding Chainlink feed reports the Total Return Value of the token by combining the underlying equity's market price with a multiplier read directly from the Robinhood token contract, rather than the raw equity price." The formula, verbatim: ``` Token Price = Underlying Equity Market Price × Multiplier ``` - **Underlying Equity Market Price**: "Sourced from Chainlink's 24/5 equity price feeds, which aggregate data across regular, pre-market, post-market, and overnight trading sessions." - **Multiplier**: "Read from the Robinhood token contract via the `uiMultiplier()` function. The multiplier accounts for dividend reinvestments and corporate action adjustments." Robinhood's page agrees and adds the consequence: "The token price diverges from the underlying share price over time. Because dividends are reinvested into the token via the multiplier, a stock token tracks the total return of the underlying — price changes plus reinvested dividends — not just the share price… As dividends accrue, the multiplier rises and one token comes to represent more than one share, so the feed price drifts above the headline share price. **This is expected.**" Its worked example: a token tracking a $100 stock starts at multiplier 1.0 and feed price $100; after a dividend is reinvested the multiplier rises to ~1.05, and if the share price is still $100 the feed price is $105. Because the multiplier is already inside the answer, "you don't apply the multiplier yourself." Chainlink characterises the feeds' purpose as "push-based oracles intended for compliance reference pricing, protocol integration, and similar use cases." ## Reading a Price Feeds "use the standard Chainlink V3 aggregator interface (`latestRoundData()`), so any consumer reads the published price through the proxy in the same way as a crypto price feed." ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.13; interface AggregatorV3Interface { function latestRoundData() external view returns ( uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound ); function decimals() external view returns (uint8); } contract PriceConsumer { AggregatorV3Interface internal priceFeed; constructor(address feedProxy) { priceFeed = AggregatorV3Interface(feedProxy); } function getLatestPrice() public view returns (int256) { (, int256 answer, , uint256 updatedAt, ) = priceFeed.latestRoundData(); require(answer > 0, "Invalid price"); require(updatedAt > 0, "Round not complete"); return answer; } } ``` "Decimals: prices are returned as integers — call `decimals()` to scale. **Most** USD feeds use 8 decimals (e.g. 30000000000 at 8 decimals = $300.00)." The hedge "most" is the source's own; the docs' best-practice list says "Read `decimals()` — never hard-code." ## Feed Coverage: What Is Claimed and What Is Verifiable The Robinhood docs make a universal-coverage claim. The Stock Tokens page states: > "**Onchain prices** — every Stock Token has a live Chainlink price feed, so your contracts can read prices directly onchain." The Building with Stock Tokens page repeats it — "Every stock token has a per-asset Chainlink price feed" — and the Oracles page says "Each Stock Token on Robinhood Chain has its own Chainlink price feed." The Oracles page also names the authority for the actual list, and it is not Robinhood: > "Feed proxy addresses, decimals, and heartbeats are maintained by Chainlink. See the Robinhood price feeds page for the current list — **it's the source of truth, so always read addresses and parameters from there rather than hardcoding them.**" **That list is not recoverable from this capture.** Chainlink's page has a section headed "Available Robinhood tokenized equity feeds" — "The following table shows the available Robinhood tokenized equity feeds" — but the table itself is rendered client-side and survived the capture only as the fragment `Networks / Robinhood Chain Mainnet / More Details`. **Consequently: no feed proxy address, no per-feed heartbeat, no deviation threshold, and no coverage count is stated on this page, because none can be cited verbatim from raw.** Do not assume full coverage. Verify that a specific ticker has a live feed — and read its proxy address, decimals and heartbeat — from Chainlink's own Robinhood price feeds page before depending on it. ## Session Behaviour: 24/5 Feeds, 24/7 Tokens State this mismatch plainly rather than smoothing it. - Chainlink: feeds "are configured as **24/5** tokenized equity feeds (regular, pre-market, post-market, and overnight sessions), where underlying liquidity and session data quality support it." - Robinhood's Oracles page: "Stock feeds update **24/5**, following market hours." - Robinhood's Stock Tokens page, about the tokens themselves: "**Self-custodied and 24/7** — assets live in users' wallets and are accessible around the clock." So the asset is transferable and composable at all times while its price is published on a 24/5 schedule. Chainlink spells out the off-hours consequence: > "**Off-hours / closed sessions**: When underlying equity markets are closed (weekends, holidays, thin overnight windows), the feed may hold the last published price even though the contract remains callable via `latestRoundData()`. **These feeds do not have heartbeats during off-hours.**" Note that this last clause sits awkwardly against Robinhood's best-practice instruction to "compare `updatedAt` against the feed's heartbeat" — during off-hours there is no heartbeat to compare against. Chainlink's own guidance is framed by use case: "Integrators should read `updatedAt` and implement staleness bounds appropriate to their use case." ## The Oracle Pause — a Stale Price With No Error Signal The token contract exposes `oraclePaused()`, and Chainlink's page states the feed honors it: - "**Normal mode** (`oraclePaused() == false`): The feed returns the current underlying equity market price multiplied by the current `uiMultiplier`." - "**Paused mode** (`oraclePaused() == true`): The feed **stops publishing new prices and holds the last known good value.** This prevents an inconsistent token price from being published while a corporate action is in progress and the underlying price and multiplier are temporarily out of sync." **A consumer calling `latestRoundData()` during a corporate action receives a stale price and no error.** The call does not revert; it returns the frozen last-known-good answer. The only signals available to the caller are `updatedAt` ceasing to advance and the `oraclePaused()` flag on the token contract. Robinhood's page describes the same flag with a materially different emphasis, and both wordings are preserved: > "While a corporate action is being processed, the price oracle for the affected token is **paused** — feeds are expected to stop publishing fresh prices while the token's terms or multiplier are being updated — and **unpaused** once processing completes… The flag is advisory and not enforced on-chain, so a paused oracle **may still return a value** — keep your staleness check (`updatedAt` vs. heartbeat) as the primary guard rather than relying on the flag alone." **Analysis:** these are compatible if read carefully — Chainlink describes the publisher's behaviour (it stops publishing), Robinhood describes the consumer's experience (the contract still returns a value). Their practical advice converges: the flag is a hint, `updatedAt` is the guard. Robinhood adds: "Integrators reading prices on-chain should treat a paused oracle as "price temporarily unavailable" for that token, rather than as a zero or stale price." ### The pause workflow Corporate actions "are coordinated by Robinhood as the asset issuer. Chainlink does not provide corporate-action calendar data or automated pause triggers; pause timing and multiplier updates are coordinated by Robinhood." The documented sequence: Robinhood calls `pauseOracle()`, freezing the feed; the new multiplier is staged via `updateMultiplier(newMultiplier, effectiveAt)`; after confirming price and multiplier align, Robinhood calls `unpauseOracle()`; the feed resumes with the updated multiplier. Chainlink's 10:1 split table shows the intent — token price continuous at $200 while the underlying goes $200 → $20 and the multiplier goes 1.0 → 10.0. The documented fail-safe: if the stock price updates before the multiplier is effective, "the feed remains frozen at the pre-pause price until Robinhood unpauses the oracle." ## Sequencer Uptime Check Because this is an L2, "verify the sequencer is up before trusting a price — during a sequencer outage, feeds can go stale": ```solidity (, int256 sequencerStatus, uint256 startedAt, , ) = sequencerUptimeFeed.latestRoundData(); require(sequencerStatus == 0, "Sequencer down"); // 0 = up require(block.timestamp - startedAt > GRACE_PERIOD, "Grace period not over"); ``` **No sequencer uptime feed address and no `GRACE_PERIOD` value for Robinhood Chain appear in the capture.** Both must be sourced from Chainlink before use. ## Smart Value Recapture Chainlink notes: "Robinhood feeds have SVR enabled even when the primary market is not public to all participants. The liquidator set includes teams that can also access primary mint and redeem when they need to. Permissioned mint and redeem concerns the primary market; tokens can still circulate onchain and positions that use the feed can still be liquidated outside that path." ## Documented Best Practices Reproduced from Robinhood's list: check staleness against the heartbeat and reject stale prices; validate the answer and reject zero or negative values; read `decimals()` rather than hard-coding; check sequencer uptime; account for the multiplier consistently when converting to share terms, including pending `newUIMultiplier()` / `effectiveAt()`; and check `oraclePaused()`, treating `true` as "do not trust the price" while keeping the staleness check as the primary guard. ## Related Concepts - [building-with-stock-tokens.md](building-with-stock-tokens.md) — `uiMultiplier()` mechanics and conversions - [stock-token-apis.md](stock-token-apis.md) — the offchain `/prices` surface, which is *not* multiplier-adjusted - [data-streams.md](data-streams.md) — the pull-based alternative - [stock-tokens.md](stock-tokens.md) ## Sources - `raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md` - `raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md` - `raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md` - `raw/web_community-stock-tokens-robinhood-chain-documentation.md` --- title: "Protocol Contracts and Precompiles" type: concept tags: [contracts, addresses, arbitrum, precompiles, bridge] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-robinhood-chain-contracts-robinhood-chain-documentation.md", "raw/web_community-cross-chain-messaging-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-token-contracts-robinhood-chain-documentatio.md"] confidence: medium --- # Protocol Contracts and Precompiles Every address on this page is reproduced character-for-character from the Robinhood Chain Contracts page as captured on 2026-09-09. Two columns are published for every entry: **Robinhood Chain** (mainnet, chain ID 4663) and **Robinhood Chain Testnet** (chain ID 46630). Do not mix them. ## Core contracts (Ethereum L1) "The following contracts are deployed on Ethereum (L1)." | Contract | Robinhood Chain | Robinhood Chain Testnet | | --- | --- | --- | | Rollup | `0x23A19d23e89166adedbDcB432518AB01e4272D94` | `0xdc5F8E399DBd8a9F5F87AeC4C23Beb12431b386D` | | Sequencer Inbox | `0xBd0D173EEb87D57A09521c24388a12789F33ba96` | `0xA0D9dB3DC9791D54b5183C1C1866eFe1eCA7D414` | | CoreProxyAdmin | `0x1232813BDd40aa9d53066A880dE78a4Be70B90FD` | `0x20d5d542c1bF0a3c295524Eaef336fC07e890622` | ## Cross-chain messaging contracts (Ethereum L1) | Contract | Robinhood Chain | Robinhood Chain Testnet | | --- | --- | --- | | Delayed Inbox | `0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D` | `0xF2939afA86F6f933A3CE17fCAB007907B6b0B7a4` | | Bridge | `0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3` | `0x96295BDad104eaD97cC08797b3dC68efF59CcF30` | | Outbox | `0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9` | `0x8D180Caf588f3Da027BEf1F42a106Da93F90b166` | These are the contracts you use for [cross-chain messaging](cross-chain-messaging.md). ## Token bridge — core contracts (L1) | Contract | Robinhood Chain | Robinhood Chain Testnet | | --- | --- | --- | | L1 Gateway Router | `0x6a2E3a1e16FC29f27Ce61429746D558d656975bB` | `0xF6F11aAEE80875776C264d93B37B34cE437382D1` | | L1 ERC20 Gateway | `0x85001CC4867C5e1C22dA4B79BB8852B9e2a06da0` | `0x52C2976cbDEf48BcC51d07d3c523769F76ECBd09` | | L1 Arb-Custom Gateway | `0x9368EAEbFe6E063C69dcF8126711A6997E0eCeE1` | `0xFB4aa8024F70B00121723A9C923BaD0Dd2dFaf8F` | | L1 Weth Gateway | `0xF7e12b9614b509C747ab4423bC4ACF923759Cf1B` | `0x8f8A6799F2b1978c6586318543c73D8Fb12f218f` | | L1 Weth | `0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2` | `0x7b79995e5f793A07Bc00c21412e50Ecae098E7f9` | | L1 Proxy Admin | `0x1232813BDd40aa9d53066A880dE78a4Be70B90FD` | `0x20d5d542c1bF0a3c295524Eaef336fC07e890622` | | L1 Multicall | `0x7cdCB0Cc61f47B8Dd8f47C5A29edaDd84a1BDf5e` | *(no testnet value published)* | The source table publishes only a single value for L1 Multicall; no testnet address is given for that row. ## Token bridge — core contracts (L2) "The following contracts are deployed on the corresponding L2 chain." | Contract | Robinhood Chain | Robinhood Chain Testnet | | --- | --- | --- | | L2 Gateway Router | `0x1E324B9316138CA9a73F960213621AD1aaf01B89` | `0x77bF00A6A90c600f214b34BAFBB7918c0cF113A8` | | L2 ERC20 Gateway | `0xfd9b17206278C16DdaacF6AC8f05dBf97EdCb31e` | `0x8689aFB9086734e12beA6b5DF541a1da252Ea32a` | | L2 Arb-Custom Gateway | `0x912285144fC0f6e89d3Ed16F5Ab72f87A1878959` | `0xE4EE9C15e2cA44136796342e31b67d953E67a70b` | | L2 Weth Gateway | `0x1D187C3E2dA52D72BC9C41e3AbA0fdFa6a7bF055` | `0x5A8F55202A625D12FFCb76F857FE4563bC8Ce413` | | L2 Weth | `0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73` | `0x7943e237c7F95DA44E0301572D358911207852Fa` | | L2 Proxy Admin | `0xa3Acd31AFb851B4eB9DAD00F5204c01D924267dF` | `0xE743e696B00789Ef489cF617477771764E9283a0` | The mainnet **L2 Weth** address is the same value the Token Contracts page lists for the `WETH` token symbol. The **L2 Gateway Router** is where you resolve an L1 token's L2 address: "call `calculateL2TokenAddress` on the L2 Gateway Router." See [bridging](bridging.md). ## Precompiles "The following precompiles are deployed on every L2 chain and always have the same address." Mainnet and testnet values are identical. | Contract | Address | | --- | --- | | ArbAddressTable | `0x0000000000000000000000000000000000000066` | | ArbAggregator | `0x000000000000000000000000000000000000006D` | | ArbFunctionTable | `0x0000000000000000000000000000000000000068` | | ArbGasInfo | `0x000000000000000000000000000000000000006C` | | ArbInfo | `0x0000000000000000000000000000000000000065` | | ArbOwner | `0x0000000000000000000000000000000000000070` | | ArbOwnerPublic | `0x000000000000000000000000000000000000006b` | | ArbRetryableTx | `0x000000000000000000000000000000000000006E` | | ArbStatistics | `0x000000000000000000000000000000000000006F` | | ArbSys | `0x0000000000000000000000000000000000000064` | | ArbWasm | `0x0000000000000000000000000000000000000071` | | ArbWasmCache | `0x0000000000000000000000000000000000000072` | | NodeInterface | `0x00000000000000000000000000000000000000C8` | Case is reproduced as published — note `ArbOwnerPublic` is given in lowercase hex (`...6b`) while its neighbours use uppercase; the address value is identical either way. Two precompiles carry documented, load-bearing behavior: - **ArbSys** — `arbBlockNumber()` returns the real L2 block number, because "`block.number` returns an estimate of the L1 (Ethereum) block number, not the Robinhood Chain block number." `sendTxToL1(...)` initiates an L2→L1 message. - **ArbGasInfo** — "Query gas pricing via the ArbGasInfo precompile." ## Misc (L2) | Contract | Robinhood Chain | Robinhood Chain Testnet | | --- | --- | --- | | L2 Multicall | `0x2cAC2D899eCC914d704FeaAE33ac1bF36277DaD1` | `0xa432504b6F04Cafe775b09D8AA92e8dbe41Ec7a8` | | Permit2 | `0x000000000022D473030F116dDEE9F6B43aC78BA3` | `0x000000000022D473030F116dDEE9F6B43aC78BA3` | ## Arbitrum SDK network registration The Cross-Chain Messaging page publishes one more chain parameter not present in the address tables — the confirmation period: ```js registerCustomArbitrumNetwork({ name: "Robinhood Chain", chainId: 4663, parentChainId: 1, // Ethereum mainnet confirmPeriodBlocks: 45818, ethBridge: { bridge: "0xDf8755334ce7A73cCF6b581C02eA649AE3E864b3", inbox: "0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D", sequencerInbox: "0xBd0D173EEb87D57A09521c24388a12789F33ba96", outbox: "0xf0ce991ea4A0d2400A4AB49b20ae333f6Dce3DE9", rollup: "0x23A19d23e89166adedbDcB432518AB01e4272D94", }, }); ``` These five values match the L1 tables above exactly. ## Not covered here Application-layer deployments (Uniswap v4, Doppler) are not part of this page. Uniswap v4 and Doppler addresses for 4663 are in [Doppler launches](doppler-launches.md) and [the Airlock entity page](../entities/doppler-airlock.md). Stock Token and tokenized-ETF addresses are on [token contracts](token-contracts.md). ## Related pages - [Bridging](bridging.md) - [Cross-chain messaging](cross-chain-messaging.md) - [Deploying contracts](deploying-contracts.md) --- title: "Running a Robinhood Chain Full Node" type: concept tags: [node, nitro, arbos, infrastructure, sync] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-run-a-robinhood-chain-full-node-robinhood-chain-documentatio.md", "raw/web_community-connecting-to-robinhood-chain-robinhood-chain-documentation.md", "raw/web_community-notices-upgrades-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-terms-of-service-robinhood-chain-documentati.md"] confidence: medium --- # Running a Robinhood Chain Full Node "Robinhood Chain is an Arbitrum Chain running Arbitrum Nitro." The docs open with a warning worth repeating: "Running a node is time consuming, resource intensive, and potentially costly. If you don't already know why you need your own node, you probably don't." Documented as of 2026-09-09. If you only need RPC, use the public endpoint `https://rpc.mainnet.chain.robinhood.com` or a provider such as Alchemy (`https://robinhood-mainnet.g.alchemy.com/v2/{API_KEY}`). QuickNode, Blockdaemon, dRPC, Validation Cloud, Chainstack and GlobalStake are also listed as supporting the chain. ## Hardware | Component | Requirement | | --- | --- | | CPU | Modern multi-core (8+) CPU with strong single-core performance | | RAM | 64 GB RAM (128 GB recommended) | | Storage | Locally attached NVMe SSD; (2 × current chain size) + 20% buffer. Several TBs of data | | Node Type | Full node (Archive nodes require substantially more disk capacity) | ## Prerequisites: you need an Ethereum L1 too "Because Robinhood Chain posts its data to Ethereum, your node needs access to an Ethereum (L1) endpoint — your own or via a provider." You need **both**: - "An L1 execution RPC endpoint" - "An L1 beacon (consensus) endpoint — required to read blob data" "If you run your own L1 node, it must be fully synced before Robinhood Chain can finish syncing." Docker must be installed and running. ## Config files Download the config for your target network: - **Mainnet:** chain info `robinhood-chain-info.json` and genesis `robinhood-genesis.json` - **Testnet:** chain info `robinhood-chain-testnet-info.json` "Testnet does not use a custom genesis file, so its start command omits the `--init.genesis-json-file` flag." This is the main mainnet/testnet divergence in the run command. ## Running the node (mainnet) Place config files in a local directory and "mount it into the container at `/home/nitro/config`". Mount the data directory to `/home/nitro/.arbitrum` — "the `nitro-node` image runs as the `nitro` user, so mounting elsewhere leaves the node unable to persist chain data." ```bash DATA_DIR="$HOME/rh/robinhood-nitro-data" docker run --rm -it \ -v "$DATA_DIR":/home/nitro/.arbitrum \ -v "$HOME/rh/config":/home/nitro/config \ -p 8547:8547 -p 8548:8548 \ offchainlabs/nitro-node:v3.11.2-3599aca \ --chain.info-files=/home/nitro/config/robinhood-chain-info.json \ --parent-chain.connection.url=... \ --parent-chain.blob-client.beacon-url=... \ --init.genesis-json-file=/home/nitro/config/robinhood-genesis.json \ --http.addr=0.0.0.0 --http.port=8547 \ --http.api=net,web3,eth ``` Substitute your own L1 endpoints for `parent-chain.connection.url` and `parent-chain.blob-client.beacon-url`. The image tag `offchainlabs/nitro-node:v3.11.2-3599aca` is the version published on the page as fetched on 2026-09-09; the docs also say "Confirm the current Nitro/ArbOS version before starting," so verify against [notices and upgrades](governance.md#notices-and-upgrades) rather than pinning from this page indefinitely. For testnet, use `robinhood-chain-testnet-info.json` and omit `--init.genesis-json-file`. ## Sequencer feed "To subscribe to the sequencer feed for low-latency updates, add `--node.feed.input.url=wss://feed.mainnet.chain.robinhood.com`. The feed URL must be `wss://`, not `https://`." Testnet: `wss://feed.testnet.chain.robinhood.com`. ## ArbOS version "Robinhood Chain runs ArbOS 61." The chain requires the Robinhood-provided chain info file via `--chain.info-files`; mainnet additionally requires the custom genesis via `--init.genesis-json-file`. On upgrades: "un-upgraded nodes stop cleanly and resume after updating — with no data loss." The stop is clean and no resync is needed, but the node *does* halt at the upgrade block — this is why operators must watch the notices page. ## Verifying and syncing ```bash curl -d '{"id":0,"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false]}' \ -H "Content-Type: application/json" http://localhost:8547 ``` Sync status: "Check sync progress with `eth_syncing`. A fully synced node returns `false`." "Initial sync can take a long time and will consume significant L1 request quota — monitor your L1 provider usage." Gotcha: "If you try to send transactions before the node is fully synced, you may see `nonce has already been used` — wait for sync to complete." ## Database snapshots "Database snapshots let you sync a new node faster by starting from a recent state instead of from genesis." - Mainnet: `https://snapshot-explorer.arbitrum.io/?chain=Robinhood+Chain` - Testnet: `https://snapshot-explorer.arbitrum.io/?chain=Robinhood+Chain+Sepolia` "To restore from a snapshot, pass its URL to the node with `--init.url=` on first start." Important limitation: "Snapshots currently published are pruned full-node snapshots; archive nodes must sync from scratch." The Terms of Service add that snapshots are "provided 'as is' and solely as a convenience," that Robinhood makes no warranty as to their "accuracy, completeness, integrity, or availability," that "you are solely responsible for verifying any data obtained from a Full Node Snapshot against the canonical state of Robinhood Chain," and that Robinhood "may change the format, hosting location, retention, or publication cadence… or discontinue them entirely, at any time and without notice." ## Running a validator Validators are **not** open to anyone: > "Robinhood Chain utilizes BoLD for dispute resolution through a permissioned > set of validators. Operating a validator necessitates being included in the > allowlist and staking a 1 WETH bond (defensive validators are highly > encouraged)." Both conditions are required — allowlist inclusion *and* the 1 WETH bond. See [governance](governance.md) for the current validator set. ## Troubleshooting **General:** view logs with `docker logs -f `; confirm the container is healthy and not in a restart loop; verify connectivity to L1 execution and beacon endpoints from the host; confirm the L1 node is fully synced, since "an unsynced L1 will stall L2 syncing." **Syncing:** "Check the L1 connection and beacon URL; most failures are due to unreachable beacon endpoints." Ensure the server clock is accurate using `ntp` or `chrony`. **Slow sync:** "Verify disk I/O performance; networked storage will significantly throttle sync speed." **Connectivity:** verify ports 8547 (HTTP) and 8548 (WS) are mapped and open, and that `--http.addr=0.0.0.0` is set "to allow external RPC access." ## Related pages - [Governance](governance.md) — upgrade notices and the validator set - [Protocol contracts](protocol-contracts.md) - [Deploying contracts](deploying-contracts.md) --- title: "Stock Token APIs" type: concept tags: [api, rest, rate-limits, corporate-actions, assets] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-stock-token-apis-robinhood-chain-documentation.md", "raw/web_community-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md"] confidence: medium --- # Stock Token APIs "Robinhood provides a set of read-only REST endpoints under `https://api.robinhood.com/rhj/` for offchain access to Stock Token data — live prices, corporate actions, and asset metadata (including the corporate-action multiplier)." Paths and field names below are reproduced character-exact from `docs.robinhood.com/chain` **as documented on 2026-09-09**. ## Rate Limits and Caching The global statement: "All endpoints are rate-limited to **60 requests/second** and cached; respect the per-endpoint cache window to avoid stale reads." | Endpoint | Documented cache | Documented rate limit | | --- | --- | --- | | `/assets` | *not stated* | 60 req/s (global statement) | | `/prices/{symbol}` | `15s` | `60 req/s` | | `/corporate-actions` | `1 hour` | `60 req/s` | `/assets` has no per-endpoint cache table in the source. Do not assume a value for it. No authentication scheme, API key, header, or quota tier is documented for these endpoints anywhere in the capture. ## The Price-Surface Warning Quoted in full, because mixing the two surfaces is the documented failure mode: > "Prices differ between surfaces. The REST `/prices` endpoint returns the raw underlying-equity bid/ask (not multiplier-adjusted). The onchain Chainlink feed returns the multiplier-adjusted value. If you mix the two, apply `currentMultiplier` from `/assets` to convert." See [oracles-and-price-feeds.md](oracles-and-price-feeds.md) for the onchain side. ## `GET https://api.robinhood.com/rhj/assets` "Asset metadata for Stock Tokens, including the current corporate-action multiplier and per-chain deployments." | Field | Type | Notes | | --- | --- | --- | | `id` | string | "Onchain `uid()`, `0x` + 66-char lowercase hex. Same across all chains for one asset." | | `tokenSymbol` | string | "e.g. `AAPL`." | | `tokenName` | string | Display name. | | `deployments[]` | array | One entry per chain. | | `deployments[].contractAddress` | string | "EIP-55 checksummed address." | | `deployments[].chainId` | integer | "EIP-155 chain id." | | `currentMultiplier` | string (decimal) | "18-dp shares-per-token." | | `pendingMultiplier` | string (decimal) | `""` when none pending. | | `pendingMultiplierEffectiveTime` | string (RFC-3339) | "Present only when a multiplier change is pending; omitted otherwise." | | `logoUrl` | string | "Public CDN logo, derived from the representative deployment's address (lowercased): `https://cdn.robinhood.com/ncw_assets/logos/
.png`." | | `tradingCapabilities` | object | "Underlying-equity trading capabilities, echoed from the underlier verbatim. Omitted when the underlier can't be resolved." | | `status` | enum | `AssetStatus`. | `AssetStatus` values: `ASSET_STATUS_UNSPECIFIED`, `ASSET_STATUS_ACTIVE`, `ASSET_STATUS_INACTIVE`. The `id` is a 66-character string: `0x` followed by 64 lowercase hex characters (a 32-byte value). The documented width and the examples agree — read "66-char" as the whole string, not the hex portion. ### `tradingCapabilities` — two incompatible documented schemas **This field is documented two different ways in two different captured pages.** Both are reproduced; neither is preferred here, and an integrator should verify against a live response before coding against either. **Version A — the Stock Token APIs page** (the API reference itself): | Field | Type | Notes | | --- | --- | --- | | `fractionalTradability` | string \| null | "Fractional-share tradability of the underlier." | | `allDayTradability` | string \| null | "RH all-day / overnight (24/5) trading flag for the underlier." | | `extendedHoursFractionalTradability` | boolean \| null | "Whether fractional trading is enabled during extended hours." | `fractionalTradability` values: `tradable`, `untradable`, `position_closing_only`, `position_opening_only`, `null`. `allDayTradability` values: `tradable`, `untradable`, `position_closing_only`, `""` (empty string), `null`. The page is careful about null semantics: "each sub-field is independently nullable — `null` on a sub-field means Source has that equity but has not set that particular field (distinct from the value `untradable`, which is an affirmative "not tradable" state)." And for `allDayTradability`, `""` is "Source explicit "blank" state for this field (distinct from `null`)." **Version B — the Stock Tokens page**, presented as the response to the same `GET https://api.robinhood.com/rhj/assets` call: ```json "tradingCapabilities": { "market": { "whole": "TRADING_STATUS_TRADABLE", "fractional": "TRADING_STATUS_TRADABLE" }, "extended": { "whole": "TRADING_STATUS_TRADABLE", "fractional": "TRADING_STATUS_TRADABLE" }, "overnight": { "whole": "TRADING_STATUS_TRADABLE", "fractional": "TRADING_STATUS_TRADABLE" } } ``` The two share no field names and no value vocabulary. ### Example response shape The top-level key is `assets`, an array. A documented example entry: ```json { "id": "0x0000000000000000000000000000000004a960b45163413698f0f69b5454785d", "tokenSymbol": "APLD", "tokenName": "Applied Digital • Robinhood Token", "deployments": [ { "contractAddress": "0xb8DBf92F9741c9ac1c32115E78581f23509916FD", "chainId": 4663 } ], "currentMultiplier": "1.000000000000000000", "pendingMultiplier": "", "logoUrl": "https://cdn.robinhood.com/ncw_assets/logos/0xb8dbf92f9741c9ac1c32115e78581f23509916fd.png", "tradingCapabilities": { "fractionalTradability": "tradable", "allDayTradability": "untradable", "extendedHoursFractionalTradability": false }, "status": "ASSET_STATUS_ACTIVE" } ``` Treat the addresses in these examples as documentation samples, not as a canonical token list — the `/prices` example on the same page uses a visibly synthetic address (`0xAbCdEf0123456789AbCdEf0123456789AbCdEf01`). ## `GET https://api.robinhood.com/rhj/prices/{symbol}` Cache `15s`, rate limit `60 req/s`. The docs add: "Please use `/{symbol}` whenever applicable to prevent additional latency." "Live token-denominated USD bid/ask. Prices are the raw underlying-equity bid/ask passed through as-is — they are **not** multiplier-adjusted. Apply `currentMultiplier` from `/assets` if you need the token-equivalent value." | Field | Type | Notes | | --- | --- | --- | | `tokenSymbol` | string | "No `X` prefix." | | `deployments[]` | array | "Same shape as `/assets`." | | `bid` | string (decimal) | "Raw underlying-equity bid, passed through as-is (not multiplier-adjusted)." | | `ask` | string (decimal) | "Raw underlying-equity ask. Same semantics as `bid`." | | `currency` | string | `"USD"` at launch. | | `dailyTradingVolume` | string (decimal) | "Underlying daily trading volume. `"0"` when unavailable." | | `isTradingHalt` | boolean | "`true` when the asset has an active trading halt." | | `generatedAt` | string (ISO-8601) | "Server time the quote was generated." | The response wraps results in a `quotes` array. Note two unresolved points: the endpoint is described as "token-denominated" in one sentence and "raw underlying-equity … not multiplier-adjusted" in the next; and the guidance to "use `/{symbol}` whenever applicable" plus an array-shaped response implies a bulk form (`/prices` with no symbol), but **no bulk path is documented**. Do not construct one. ## `GET https://api.robinhood.com/rhj/corporate-actions` Cache `1 hour`, rate limit `60 req/s`. "Processed corporate actions for Stock Tokens, most-recent `processDate` first. Each entry's `details` object has exactly one key present, determined by `type`; all `*Rate` fields are decimal strings. Use this endpoint to reconcile why a token's multiplier changed onchain — for example, a `FORWARD_SPLIT` entry with `oldRate`/`newRate` explains a corresponding `uiMultiplier()` update." | Field | Type | Notes | | --- | --- | --- | | `id` | string | "Onchain `uid()`, `0x` + 66-char hex. Stable for dedup across chains." | | `type` | enum | `CorporateActionType`. | | `status` | enum | `CorporateActionStatus`. | | `processDate` | object `{year,month,day}` | "`ctok` scheduling date; for splits, the multiplier-effective date. Omitted/null on in-progress rows with no scheduled date. **Not the dividend payable date.**" | | `tokenSymbol` | string | "No `X` prefix." | | `deployments[]` | array | "Same shape as `/assets`." | | `details` | object | "Exactly one key set, matching `type`." | `CorporateActionStatus`: `CORPORATE_ACTION_STATUS_UNSPECIFIED` (never on the wire), `CORPORATE_ACTION_STATUS_IN_PROGRESS` ("yes (Source PENDING + READY)"), `CORPORATE_ACTION_STATUS_COMPLETED`. `CorporateActionType` — active at launch: `CORPORATE_ACTION_TYPE_FORWARD_SPLIT`, `CORPORATE_ACTION_TYPE_REVERSE_SPLIT`, `CORPORATE_ACTION_TYPE_CASH_DIVIDEND`, `CORPORATE_ACTION_TYPE_STOCK_DIVIDEND`. Marked "no (forward-compat)": `..._SPIN_OFF`, `..._CASH_MERGER`, `..._STOCK_MERGER`, `..._STOCK_AND_CASH_MERGER`, `..._REDEMPTION`, `..._NAME_CHANGE`, `..._WORTHLESS_REMOVAL`, `..._RIGHTS_DISTRIBUTION`, `..._UNIT_SPLIT`. Plus `CORPORATE_ACTION_TYPE_UNSPECIFIED`. ### `details` variants | `type` | `details` key | Fields | | --- | --- | --- | | `..._FORWARD_SPLIT` | `forwardSplit` | `underlyingSymbol`, `oldRate`, `newRate` | | `..._REVERSE_SPLIT` | `reverseSplit` | `underlyingSymbol`, `oldRate`, `newRate` | | `..._CASH_DIVIDEND` | `cashDividend` | `underlyingSymbol`, `rate` (USD per share) | | `..._STOCK_DIVIDEND` | `stockDividend` | `underlyingSymbol`, `rate` (shares per share) | | `..._SPIN_OFF` | `spinOff` | `sourceUnderlyingSymbol`, `sourceRate`, `newUnderlyingSymbol`, `newRate` | | `..._CASH_MERGER` | `cashMerger` | `acquireeUnderlyingSymbol`, `cashRate` | | `..._STOCK_MERGER` | `stockMerger` | `acquirerUnderlyingSymbol`, `acquirerRate`, `acquireeUnderlyingSymbol`, `acquireeRate` | | `..._STOCK_AND_CASH_MERGER` | `stockAndCashMerger` | `acquirerUnderlyingSymbol`, `acquirerRate`, `acquireeUnderlyingSymbol`, `acquireeRate`, `cashRate` | | `..._REDEMPTION` | `redemption` | `underlyingSymbol`, `rate` | | `..._NAME_CHANGE` | `nameChange` | `oldUnderlyingSymbol`, `newUnderlyingSymbol` | | `..._WORTHLESS_REMOVAL` | `worthlessRemoval` | `underlyingSymbol` | | `..._RIGHTS_DISTRIBUTION` | `rightsDistribution` | `sourceUnderlyingSymbol`, `newUnderlyingSymbol`, `rate` | | `..._UNIT_SPLIT` | `unitSplit` | `oldUnderlyingSymbol`, `oldRate`, `newUnderlyingSymbol`, `newRate`, `alternateUnderlyingSymbol`, `alternateRate` | The response wraps results in a `corpActions` array. **Analysis:** the 1-hour cache is far coarser than the onchain signal. If your system must react to a multiplier change promptly, the `UIMultiplierUpdated` event and `newUIMultiplier()`/`effectiveAt()` on the token are the timely sources; `/corporate-actions` is the reconciliation and explanation layer, which is exactly how the docs frame it. ## Related Concepts - [stock-tokens.md](stock-tokens.md) - [building-with-stock-tokens.md](building-with-stock-tokens.md) - [oracles-and-price-feeds.md](oracles-and-price-feeds.md) ## Sources - `raw/web_community-stock-token-apis-robinhood-chain-documentation.md` - `raw/web_community-stock-tokens-robinhood-chain-documentation.md` - `raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md` --- title: "Stock Tokens" type: concept tags: [stock-tokens, rwa, erc-20, rhj, erc-8056] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-terms-of-service-robinhood-chain-documentati.md", "raw/web_community-robinhood-chain-token-contracts-robinhood-chain-documentatio.md", "raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md"] confidence: medium --- # Stock Tokens This page documents what a Robinhood Stock Token is and how the instrument is structured. It is not investment, legal, tax or financial advice, and nothing here is a recommendation to acquire, dispose of, or hold any asset. All statements reflect `docs.robinhood.com/chain` **as documented on 2026-09-09**. ## What a Stock Token Legally Is The controlling sentence, reproduced verbatim from the Stock Tokens page: > "Stock Tokens are tokenised debt securities issued by Robinhood Assets (Jersey) Limited ("RHJ"). The Product provides economic exposure to underlying securities like US shares and ETFs, but does not grant investors any legal or beneficial rights in, or against the issuer of, those underlying securities." Three things follow from that sentence and must not be softened: 1. The instrument is a **debt security issued by RHJ**, not a share. 2. It provides **economic exposure** to the underlying. 3. It grants **no legal or beneficial rights** in the underlying security, and no rights against the underlying security's issuer. The docs' own disclaimer restates it and adds the risk language, again verbatim: "Stock Tokens carry a high level of risk and are not appropriate for all investors. Investors should be prepared for the possibility of losing some or all of their investment. Eligible investors should carefully review the Base Prospectus (together with any supplements) and the applicable Final Terms, available here: `http://docs.robinhood.com/rhj`" ## The Issuer "Robinhood Assets (Jersey) Limited is a private limited company incorporated in Jersey, with its registered address at First Floor, La Chasse Chambers, Ten La Chasse, St. Helier, JE2 4UE, Jersey. The Issuer is registered under the registration number 162428." RHJ is both issuer and tokenizer: "Stock Tokens are ERC-20s issued by RHJ. RHJ also acts as the tokenizer." ## Offering Restrictions These are stated in the source and are reproduced without alteration: > "Stock Tokens are not registered under U.S. securities laws and may not be offered, sold, or delivered, directly or indirectly, in the United States or to, or for the account or benefit of, U.S. persons. Offers and sales of Stock Tokens are subject to restrictions in other jurisdictions, including, without limitation, Canada, the United Kingdom, and Switzerland." The full jurisdiction list is published at `http://docs.robinhood.com/rhj` — that document is not part of this capture. The docs also state: "Nothing on this website constitutes investment, legal, tax or financial advice. Prospective investors should make their own assessment as to the suitability of investing in the Products." ## Approved Terminology (and a Contradiction in the Docs) The Robinhood Chain Terms of Service, §5.7(j), restricts how third parties may describe these tokens: > "You must not describe, refer to, or market "Stock Tokens" (as that term is used in connection with the Robinhood Chain network) as "tokenized stocks," "tokenized equities," or similar characterizations. Approved terminology for external-facing content is "Stock Tokens" or "tokenized real-world assets such as Stock Tokens."" **This conflicts with other captured pages.** The Building with Stock Tokens page says "Tokenized stocks trade via RFQ at launch"; the Token Contracts page is headed "Stock Tokens & Tokenized ETFs"; and Chainlink's own documentation page for these feeds is titled "Robinhood Tokenized Equities" and uses the phrase "Robinhood tokenized stocks" in its opening paragraph, though its dominant term is "Robinhood tokenized equity feeds". Both wordings are reported here rather than reconciled. Separately, ToS §5.8(d) (Name and Word Mark Usage) requires the network be called exclusively "Robinhood Chain" — the shorthand "Hood Chain" is prohibited in external-facing materials. ## The Onchain Surface - "Each Stock Token is a standard ERC-20 contract with **18 decimals**." - "Each token corresponds to a specific underlying equity or ETF, identified by its ticker symbol." - "Stock Tokens are issued as standard ERC-20 tokens that can be held, transferred, and composed into applications onchain." - Chainlink's page adds the deployment shape: "Each Robinhood tokenized stock is represented by its own ERC-20 token contract, deployed on Robinhood Chain (one contract per ticker)." The Token Contracts page carries an identity warning worth quoting: "Use the addresses on this page to identify the **canonical** Robinhood Stock Token for each underlying — a token with a matching name/ticker but a different contract address is not a Robinhood Stock Token." **No Stock Token contract addresses are recoverable from this capture.** The Token Contracts table "is generated live from the on-chain asset registry" and rendered only as "Loading tokens…" when captured. The two non-stock addresses on that page did render: | Symbol | Contract | | --- | --- | | WETH | `0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73` | | USDG | `0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168` | Addresses that appear inside the Stock Token API example payloads are illustrative documentation samples, not a published address list, and are not reproduced here as canonical. Resolve a token address from the live Token Contracts page or the `/assets` API — see [stock-token-apis.md](stock-token-apis.md). ## Self-Custody, 24/7, and the Windows That Are Not 24/7 The About and Stock Tokens pages describe the asset as "**Self-custodied and 24/7** — assets live in users' wallets and are accessible around the clock." Two documented windows qualify what "around the clock" covers: ### The tokenization window "Market makers can place orders to mint and burn Stock Tokens during the following window: **Monday 02:00 CET/CEST – Saturday 02:00 CET/CEST** (Subject to local daylight savings schedules. Outside this window, minting and burning is not supported.)" Immediately followed by: "End users may still buy and sell Stock Tokens on-chain outside the tokenization window." ### Price feed sessions Chainlink's page states the feeds are "configured as 24/5 tokenized equity feeds (regular, pre-market, post-market, and overnight sessions), where underlying liquidity and session data quality support it," and that "These feeds do not have heartbeats during off-hours." So token *transferability* is continuous while token *pricing* follows a 24/5 schedule. See [oracles-and-price-feeds.md](oracles-and-price-feeds.md). ## Primary Market Is Permissioned "Only Authorised Participants (at issuance, the only Authorised Participant is BBVI) may subscribe for Stock Tokens directly from RHJ after KYB onboarding (the primary market), so developers build by composing with existing tokens rather than minting." The Building page repeats it: "Direct mint/burn is available only to Authorized Participants / market makers and requires KYB onboarding; regular holders acquire and exit positions on the secondary market." **Analysis:** the practical consequence for a developer is that there is no mint path in your integration. Every flow starts from tokens that already exist onchain. ## Corporate Actions and the Multiplier "The platform manages dividends and stock splits through an onchain multiplier, which adjusts the shares-per-token ratio while keeping your raw balance static until redemption. You can access this value via the token's `uiMultiplier()` function, defined by ERC-8056 (Scaled UI Amount Extension). Onchain swaps remain unaffected, and the oracle automatically incorporates the multiplier into the price." Stock tokens are explicitly "**not** rebasing tokens" — `balanceOf()` and `totalSupply()` stay fixed. Mechanics, interfaces and events are in [building-with-stock-tokens.md](building-with-stock-tokens.md). ## Per-Asset Trading Capabilities "Not all Stock Tokens support trading across all sessions (market hours, extended hours, overnight)." The docs direct you to `GET https://api.robinhood.com/rhj/assets` and its `tradingCapabilities` field, adding: "Developers building applications that interact with Stock Tokens should check this field before executing trades to handle assets that are not tradable in a given session." Note that the two captured pages describe `tradingCapabilities` with **two different, incompatible schemas** — see [stock-token-apis.md](stock-token-apis.md), which sets both out side by side. ## Related Concepts - [building-with-stock-tokens.md](building-with-stock-tokens.md) - [stock-token-apis.md](stock-token-apis.md) - [oracles-and-price-feeds.md](oracles-and-price-feeds.md) - [what-is-robinhood-chain.md](what-is-robinhood-chain.md) ## Sources - `raw/web_community-stock-tokens-robinhood-chain-documentation.md` - `raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md` - `raw/web_community-robinhood-chain-terms-of-service-robinhood-chain-documentati.md` - `raw/web_community-robinhood-chain-token-contracts-robinhood-chain-documentatio.md` - `raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md` --- title: "Stock Token Contract Architecture on Robinhood Chain" type: concept tags: [stock-tokens, erc20, contracts, rwa, erc-8056] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-robinhood-chain-token-contracts-robinhood-chain-documentatio.md", "raw/web_community-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-stock-token-apis-robinhood-chain-documentation.md", "raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md"] confidence: medium --- # Stock Token Contract Architecture on Robinhood Chain Robinhood Stock Tokens are the flagship real-world asset on chain ID 4663. This page covers the on-chain contract surface as documented on 2026-09-09. ## One ERC-20 contract per ticker Chainlink's provider page states the deployment shape plainly: "Each Robinhood tokenized stock is represented by its own ERC-20 token contract, deployed on Robinhood Chain (one contract per ticker)." The Robinhood docs describe the same surface from the developer side: - "Each Stock Token is a standard ERC-20 contract with 18 decimals." - "Each token corresponds to a specific underlying equity or ETF, identified by its ticker symbol." - Stock Tokens "are standard ERC-20 tokens, so building with them uses the same patterns you already know." All standard token operations work without modification — `balanceOf`, `transfer`, `approve` are called exactly as on any ERC-20. ### What the sources do NOT say **The raw sources captured for this wiki contain no description of a beacon proxy, an upgradeable-proxy pattern, or a shared implementation contract behind the Stock Tokens.** No `UpgradeableBeacon`, `implementation()`, beacon address, or proxy-admin for the token contracts appears in any captured page. The word "beacon" appears in these sources only in the unrelated sense of an Ethereum L1 consensus (beacon-chain) endpoint for [running a node](running-a-node.md). This absence is a gap in the sources, not evidence that no such pattern exists. Do not assume upgradeability or non-upgradeability of a Stock Token contract from this page; verify on the block explorer against the specific address. ## Finding the canonical address The docs are emphatic about address provenance: > "Use the addresses on this page to identify the **canonical** Robinhood Stock > Token for each underlying — a token with a matching name/ticker but a > different contract address is not a Robinhood Stock Token." Two token addresses are listed statically on the Token Contracts page: | Symbol | Contract | | --- | --- | | WETH | `0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73` | | USDG | `0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168` | The Stock Token and tokenized-ETF table on that page is **not** static: "The table below is generated live from the on-chain asset registry." The capture taken on 2026-09-09 shows only the placeholder text `Loading tokens…`, so no per-ticker Stock Token addresses could be recorded here. Read them from the live Token Contracts page or from the `/assets` API rather than from any cached list. Note that the WETH address above matches the "L2 Weth" entry in the [protocol contracts](protocol-contracts.md) table for Robinhood Chain. ## Discovering tokens programmatically `GET https://api.robinhood.com/rhj/assets` returns asset metadata including per-chain deployments. Each asset carries: - `id` — the onchain `uid()`, `0x` + 66-char lowercase hex, "Same across all chains for one asset." - `tokenSymbol`, `tokenName` - `deployments[].contractAddress` — "EIP-55 checksummed address" - `deployments[].chainId` — "EIP-155 chain id"; the worked examples in the docs show `4663` - `currentMultiplier` — "18-dp shares-per-token" - `pendingMultiplier` — `""` when none pending - `pendingMultiplierEffectiveTime` — RFC-3339, "Present only when a multiplier change is pending; omitted otherwise" - `status` — `ASSET_STATUS_UNSPECIFIED` / `ASSET_STATUS_ACTIVE` / `ASSET_STATUS_INACTIVE` The endpoints under `https://api.robinhood.com/rhj/` are read-only and rate limited to 60 requests/second. ## The ERC-8056 extension on top of ERC-20 Beyond the plain ERC-20 surface, Stock Tokens "also implement ERC-8056 (Scaled UI Amount Extension), which defines the corporate-action multiplier (`uiMultiplier()`)." The critical property, stated directly: > "The multiplier scales the effective amount without changing raw balances or > total supply — `balanceOf()` and `totalSupply()` stay fixed. Stock tokens are > not rebasing tokens." The interfaces the docs publish are `IScaledUIAmount` (with `uiMultiplier()`, the `UIMultiplierUpdated` event and the `TransferWithScaledUI` event), `IScaledUIAmountNewUIMultiplier` (`newUIMultiplier()`, `effectiveAt()`), and `IScaledUIAmountBalances` (`balanceOfUI(address)`, `totalSupplyUI()`). See [UI multipliers](ui-multipliers.md) for the full mechanism, the update paths, and what a multiplier below 1.0 implies. The token contract also exposes `oraclePaused()`, an oracle pause flag that the Chainlink feed honors. Robinhood's own guidance calls the flag "advisory and not enforced on-chain." ## Pricing surface "Every stock token has a per-asset Chainlink price feed implementing the standard `AggregatorV3Interface` (`latestRoundData()`, read via the feed proxy — same interface as crypto feeds)." The feed already includes the multiplier: "The Chainlink price already includes the corporate-action multiplier (dividends, splits), so the value you read is the token's full price — don't apply the multiplier yourself." Feed proxy addresses are deliberately not enumerated in the Robinhood docs: "Feed proxy addresses, decimals, and heartbeats are maintained by Chainlink… it's the source of truth, so always read addresses and parameters from there rather than hardcoding them." ## Supply: who can mint Minting and burning are primary-market operations, not open contract calls: > "Stock Tokens are minted and burned directly with the issuer, Robinhood > Assets (Jersey) Limited in the primary market… Direct mint/burn is available > only to Authorized Participants / market makers and requires KYB onboarding." The Stock Tokens page adds: "Only Authorised Participants (at issuance, the only Authorised Participant is BBVI) may subscribe for Stock Tokens directly from RHJ after KYB onboarding (the primary market), so developers build by composing with existing tokens rather than minting." Minting and burning are further bounded by a tokenization window — "Monday 02:00 CET/CEST – Saturday 02:00 CET/CEST… Outside this window, minting and burning is not supported." End users "may still buy and sell Stock Tokens on-chain outside the tokenization window." **Analysis:** the combination of a permissioned primary market and a freely transferable ERC-20 secondary market is what makes the address-canonicality warning above load-bearing — anyone can deploy a contract named `AAPL` on 4663, and only the registry-listed address is the issuer's token. ## Related pages - [UI multipliers](ui-multipliers.md) - [Protocol contracts](protocol-contracts.md) - [Access controls and admin powers](access-controls-registry.md) - [Deploying contracts](deploying-contracts.md) --- title: "Transaction Finality on Robinhood Chain" type: concept tags: [finality, sequencer, confirmations, reorg, withdrawals] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-transaction-finality-robinhood-chain-documentation.md", "raw/web_community-bridging-robinhood-chain-documentation.md", "raw/web_community-cross-chain-messaging-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-lighter-domains-robinhood-chain-documentatio.md"] confidence: medium --- # Transaction Finality on Robinhood Chain ## Definition "Robinhood Chain transactions reach finality in stages. Understanding them helps you choose the right confirmation level for your application — fast soft confirmations for everyday UX, full Ethereum finality for high-value operations." This page reflects `docs.robinhood.com/chain` **as documented on 2026-09-09**. ## The Three Stages | Stage | What happens | Typical latency | Guarantee | | --- | --- | --- | --- | | Soft confirmation | "The sequencer accepts, orders, and executes your transaction and returns a receipt." | Sub-second | "The sequencer has committed to your transaction's inclusion and ordering. Reversible only if the sequencer posts a batch with a different transaction order." | | Posted to Ethereum | "The sequencer batches transactions and posts the batch to the Ethereum (L1) Inbox." | Minutes | "Ordering is now fixed — your transaction can only be reorganized if Ethereum itself reorganizes." | | Ethereum finality | "The L1 block containing the batch reaches finality on Ethereum." | "~13 minutes after posting" | "Full finality — your transaction inherits Ethereum's security and is irreversible." | Note the exact scope of the ~13 minutes: it is measured **after posting**, not from submission. Total wall-clock time to full finality is therefore the batch-posting delay ("minutes") plus roughly 13 minutes. ## Choosing a Confirmation Level The docs give two documented recommendations: - "Everyday UX (most apps): the soft confirmation from the sequencer is fast and reliable — sufficient for typical interactions." - "High-value or irreversible actions: wait until the transaction is posted to Ethereum, or for full Ethereum finality, before treating it as settled." **Analysis:** the boundary the docs draw is between reversible and irreversible off-chain consequences. If your system takes an action outside this chain in response to a transaction — crediting an off-chain ledger, releasing an asset on another network, settling with a counterparty — soft confirmation alone leaves you exposed to the one documented reversal path. Anything whose effect stays entirely onchain and can be undone by a later transaction sits comfortably at soft confirmation. ## Reorganizations: What Can Actually Reverse The docs state the reorg model precisely, and the polarity matters: "Once a transaction is posted to Ethereum, it cannot be reorganized unless Ethereum itself reorganizes. Before posting, soft-confirmed transactions rely on the sequencer for the order it returned — in normal operation this is reliable, but it is not yet backed by Ethereum's security." So there are exactly two documented reversal mechanisms: 1. **Before posting** — "Reversible only if the sequencer posts a batch with a different transaction order." The trust assumption here is the sequencer, not Ethereum. 2. **After posting** — only an Ethereum reorg. The captured docs do not quantify how often the first has occurred, nor do they document a sequencer-failover or force-inclusion procedure for Robinhood Chain specifically. The Arbitrum-standard delayed-inbox path exists as a contract (`Delayed Inbox` at `0x1A07cc4BD17E0118BdB54D70990D2158AbAD7a2D` on Ethereum L1) but the docs describe it in the context of cross-chain messaging, not censorship resistance. ## Finality Is Not the Withdrawal Delay The docs call this out under its own heading, and it is the single most commonly conflated pair on any Arbitrum-stack chain: "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 can be fully final on Ethereum and its resulting withdrawal still be seven days from being claimable. The Bridging page describes withdrawal as a three-step process: initiate on L2, wait the 7-day challenge period, then "Claim your funds by submitting a transaction on Ethereum (L1). This final step is required and incurs L1 gas costs." Deposits run the other way and are fast: "Deposits typically confirm within 10 minutes." ## L2 → L1 Messages Inherit the Same Delay Cross-chain messaging carries the same asymmetry. "L1 → L2 via retryable tickets, submitted through the Delayed Inbox. Typically completes in minutes." "L2 → L1 via the ArbSys precompile. Subject to the 7-day challenge period before it can be executed on Ethereum." The SDK exposes this as a wait: `await message.waitUntilReadyToExecute(childProvider);` — the docs note "This promise resolves only after the challenge window expires." The Arbitrum SDK registration for this chain records the challenge window in blocks: `confirmPeriodBlocks: 45818`. ## Failed L1 → L2 Legs Are Recoverable for 7 Days Both the Bridging and Cross-Chain Messaging pages state the retryable-ticket safety net: if the L2 leg fails — "for example, due to insufficient gas" — "the funds are not lost" and the deposit "can be manually redeemed from the bridge interface within 7 days." For messages: "the ticket is not lost — it can be redeemed manually within 7 days." **Analysis:** seven days is a hard deadline, not a soft one, in the docs' phrasing. An integration that submits retryable tickets should monitor for failed redemptions rather than assume eventual success. ## How Applications Use the Stages in Practice The Lighter Domains page documents a concrete product built on this distinction — two withdrawal modes on Robinhood Chain: - "**Fast Withdraw** — uses Robinhood Chain's soft finality; near-instant." - "**Secure Withdraw** — standard L2 withdrawal with full finality guarantees." This is the design pattern the finality stages enable: offer the fast path for routine amounts, reserve the slow path for cases where the counterparty risk of soft finality is unacceptable. Nothing here is a recommendation about which to use — that is an application-design and risk decision. ## Related Concepts - [differences-from-ethereum.md](differences-from-ethereum.md) — sequencer ordering and screening - [gas-and-fees.md](gas-and-fees.md) — why paying more does not speed inclusion - [what-is-robinhood-chain.md](what-is-robinhood-chain.md) — validators and BoLD dispute resolution ## Sources - `raw/web_community-transaction-finality-robinhood-chain-documentation.md` - `raw/web_community-bridging-robinhood-chain-documentation.md` - `raw/web_community-cross-chain-messaging-robinhood-chain-documentation.md` - `raw/web_community-robinhood-chain-lighter-domains-robinhood-chain-documentatio.md` --- title: "Scaled-UI Multipliers (ERC-8056) on Stock Tokens" type: concept tags: [erc-8056, multiplier, corporate-actions, stock-tokens, oracles] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md", "raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md", "raw/web_community-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-stock-token-apis-robinhood-chain-documentation.md"] confidence: medium --- # Scaled-UI Multipliers (ERC-8056) on Stock Tokens Robinhood Stock Tokens handle dividends and corporate actions with an on-chain multiplier rather than by rebasing balances. This page documents that mechanism as described on 2026-09-09. ## The standard and the core interface Stock tokens "implement ERC-8056 (Scaled UI Amount Extension), which defines the corporate-action multiplier (`uiMultiplier()`)." ```solidity interface IScaledUIAmount { // Current UI multiplier, expressed with 18 decimals (1e18 = 1.0). function uiMultiplier() external view returns (uint256); // Emitted when the multiplier changes (e.g. a dividend or split). event UIMultiplierUpdated( uint256 oldMultiplier, uint256 newMultiplier, uint256 effectiveAtTimestamp ); // Emitted on a transfer, carrying both the raw value and the UI-adjusted // (underlying-share) value. event TransferWithScaledUI( address indexed from, address indexed to, uint256 value, uint256 uiValue ); } ``` Chainlink's provider page adds a detail the Robinhood docs leave implicit: the `UIMultiplierUpdated` event "is emitted whenever the multiplier changes **or a new value is staged**." So seeing the event does not by itself mean the active multiplier has already moved — check `effectiveAtTimestamp`. ## What a multiplier update means for balances It does not change them. This is the single most important property: > "The multiplier scales the effective amount without changing raw balances or > total supply — `balanceOf()` and `totalSupply()` stay fixed. Stock tokens are > not rebasing tokens." The Stock Tokens overview puts the same thing economically: the multiplier "adjusts the shares-per-token ratio while keeping your raw balance static until redemption." The conversion is: ``` underlying shares = raw token amount × uiMultiplier ÷ 1e18 ``` `uiMultiplier()` "is fixed-point with 18 decimals — 1e18 = 1.0", and "At launch the multiplier is 1e18 (one token = one underlying share)." The token also exposes UI-adjusted views so integrators need not do the math: ```solidity interface IScaledUIAmountBalances { function balanceOfUI(address account) external view returns (uint256); function totalSupplyUI() external view returns (uint256); } ``` The Oracles page warns about the scaling factor explicitly: "Always divide by 1e18 after applying it… otherwise the result is off by a factor of 1e18." ## The two update paths Chainlink documents the exact write surface Robinhood uses: | Path | Signature | Behavior | | --- | --- | --- | | Immediate update | `updateMultiplier(uint256)` | "sets a new `uiMultiplier` effective immediately." | | Scheduled update | `updateMultiplier(uint256, uint256 effectiveAt)` | "stages the next multiplier." | For a staged update the pending value and its activation time are readable on-chain: ```solidity interface IScaledUIAmountNewUIMultiplier { // The pending UI multiplier scheduled to take effect at effectiveAt. function newUIMultiplier() external view returns (uint256); // The timestamp at which the pending multiplier becomes effective. function effectiveAt() external view returns (uint256); } ``` "The new value becomes the active `uiMultiplier` once the `effectiveAt` timestamp is reached." Before any update is scheduled, `newUIMultiplier()` "tracks the current multiplier." The contract itself enforces which path applies to which kind of event: - **Small updates** (no price discontinuity): "Applied immediately via automated processes. These handle routine dividend reinvestments." - **Large updates** (price discontinuity): "Requires a scheduled pause window and manual confirmation before unpause. These handle major corporate actions like stock splits." Off-chain, the same pending state appears in `GET /rhj/assets` as `currentMultiplier`, `pendingMultiplier` (`""` when none pending) and `pendingMultiplierEffectiveTime` (present only when a change is pending). ## Which events move the multiplier, and in which direction The multiplier is **not monotonic** — it moves both ways: | Event Type | Multiplier Behavior | Example | | --- | --- | --- | | Dividend reinvestment | Small increase | `uiMultiplier`: 1.000 → 1.008 | | Stock split (10:1 example) | Large increase | `uiMultiplier`: 1.0 → 10.0 | | Reverse split (1:10 example) | Large decrease | `uiMultiplier`: 10.0 → 1.0 | | Spin-offs | Adjustment to reflect new value | Varies by event | ## What a multiplier below 1.0 implies **Analysis (not upstream):** below 1.0, one token would represent **less than one underlying share**, and the conversion formula is unchanged — at `uiMultiplier = 0.1e18`, 1 token = 0.1 underlying shares. No captured or live source documents a sub-1.0 multiplier; upstream's only downward example takes it from 10.0 to 1.0 for a 1:10 reverse split. That the same mechanism could carry it below 1.0 is this wiki's inference from the formula, not a documented case. The sources state no floor and no special handling. Two consequences follow from the documented behavior: 1. Raw `balanceOf()` is untouched, so a holder's token count does not shrink; a naive integration that reports raw balance as "shares held" over-reports after any downward move. Use `balanceOfUI()` or apply the formula. 2. The Chainlink feed price falls with the multiplier, because `Token Price = Underlying Equity Market Price × Multiplier`. The feed, not the balance, carries the adjustment. **Analysis:** because the token drifts *upward* relative to the raw share price over time — "a stock token tracks the total return of the underlying — price changes plus reinvested dividends — not just the share price… As dividends accrue, the multiplier rises and one token comes to represent more than one share, so the feed price drifts above the headline share price. This is expected" — a multiplier below 1.0 is not the ordinary steady state and points to a specific downward corporate action rather than to accrual. The sources do not state a floor, a minimum, or any special handling below 1.0. ## Interaction with the price feed and the oracle pause The feed already applies the multiplier: `Token Price = Underlying Equity Market Price × Multiplier`, where the multiplier is "Read from the Robinhood token contract via the `uiMultiplier()` function." So "don't apply the multiplier yourself." Note the surfaces disagree deliberately: the REST `/prices` endpoint "returns the raw underlying-equity bid/ask (not multiplier-adjusted). The onchain Chainlink feed returns the multiplier-adjusted value. If you mix the two, apply `currentMultiplier` from `/assets` to convert." During a large corporate action the issuer-driven sequence is: 1. Robinhood pauses the oracle (`pauseOracle()`), "freezing the feed at the last known good value." 2. "The new multiplier is staged via `updateMultiplier(newMultiplier, effectiveAt)` (or applied at the scheduled time)." 3. "After the corporate action takes effect and Robinhood confirms that both the underlying market price and the multiplier reflect the new values correctly, the oracle is unpaused (`unpauseOracle()`)." 4. "The feed resumes publishing using the updated multiplier." Worked 10:1 split from the source — token price stays continuous at $200 throughout: before split ($200 stock × 1.0), during pause (frozen, pending 10.0), after unpause ($20 stock × 10.0). If the underlying price moves before the staged multiplier activates, the result is that the "Feed remains frozen at the pre-pause price until Robinhood unpauses the oracle" — described as "fail-safe behavior." Chainlink states the trust boundary plainly: "Chainlink does not provide corporate-action calendar data or automated pause triggers; pause timing and multiplier updates are coordinated by Robinhood." Robinhood's own guidance adds that `oraclePaused()` "is advisory and not enforced on-chain, so a paused oracle may still return a value — keep your staleness check… as the primary guard." ## Reconciling a multiplier change `GET https://api.robinhood.com/rhj/corporate-actions` exists for exactly this: "Use this endpoint to reconcile why a token's multiplier changed onchain — for example, a `FORWARD_SPLIT` entry with `oldRate`/`newRate` explains a corresponding `uiMultiplier()` update." Active types at launch are `CORPORATE_ACTION_TYPE_FORWARD_SPLIT`, `..._REVERSE_SPLIT`, `..._CASH_DIVIDEND`, and `..._STOCK_DIVIDEND`. ## Related pages - [Token contracts](token-contracts.md) - [Access controls and admin powers](access-controls-registry.md) --- title: "What Is Robinhood Chain" type: concept tags: [robinhood-chain, layer-2, arbitrum, rwa, evm] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-about-robinhood-chain-robinhood-chain-documentation.md", "raw/web_community-connecting-to-robinhood-chain-robinhood-chain-documentation.md", "raw/web_community-governance-robinhood-chain-documentation.md", "raw/web_community-run-a-robinhood-chain-full-node-robinhood-chain-documentatio.md", "raw/web_community-notices-upgrades-robinhood-chain-documentation.md"] confidence: medium --- # What Is Robinhood Chain ## Definition Robinhood Chain is described in its own documentation as "a permissionless, Ethereum-compatible Layer-2 blockchain built to support a new era of onchain financial infrastructure — one that brings traditional markets, crypto, and real-world assets together on a fast, efficient, and open network." Mainnet uses **chain ID 4663**; the testnet uses **chain ID 46630**. ETH is the native gas token on both. All statements on this page reflect `docs.robinhood.com/chain` **as documented on 2026-09-09**. ## The Stack It Runs On The docs give the stack in three overlapping phrasings, and it is worth keeping all three because they are not identical strings: - The About page: "Robinhood Chain is built on Arbitrum Dedicated Blockchains, a modular Layer-2 framework that combines Ethereum's security with high throughput and low transaction costs." - The Connecting page: "Robinhood Chain is an Arbitrum Layer-2 Chain built on Ethereum, using Ethereum blobs for data availability and ETH as the native gas token." - The full-node and Differences pages: "Robinhood Chain is an Arbitrum Chain running Arbitrum Nitro" / "an Arbitrum Nitro Layer-2". **Analysis:** the captured documentation never uses the word "Orbit". If you need to describe the stack in language traceable to the source, "Arbitrum Nitro" and "Arbitrum Dedicated Blockchains" are the terms the docs actually use. Operationally, the node software is Nitro. The full-node guide pins the container image `offchainlabs/nitro-node:v3.11.2-3599aca` and states "Robinhood Chain runs ArbOS 61". Data availability is Ethereum blobs, which is why a node operator needs both an L1 execution RPC endpoint and an L1 beacon (consensus) endpoint. ## What It Is For The chain is positioned around tokenized real-world assets. From the About page: "At its core, Robinhood Chain is optimized for tokenized real-world assets (RWAs) — including equities, ETFs, private assets, and other financial instruments — allowing them to be represented and traded onchain," supporting a vision where assets are "programmatically traded, self-custodied by users, and accessible 24/7." The flagship RWA is Stock Tokens — see [stock-tokens.md](stock-tokens.md) for what one legally is, and [building-with-stock-tokens.md](building-with-stock-tokens.md) for the developer surface. ## Distinguishing Properties ### First-come, first-served ordering "Robinhood Chain utilizes a first-come, first-served sequencing model, where the order is determined strictly by the arrival time at the sequencer. The network ensures a transparent and predictable environment where no transaction can bypass others by paying higher fees." Priority gas auctions do not exist; raising your fee will not move you ahead in the queue. See [differences-from-ethereum.md](differences-from-ethereum.md). ### Permissionless "Anyone can interact with the network, build applications, and deploy smart contracts." Note that permissionless *chain* access is a separate question from access to the Stock Token primary market, which is restricted to Authorised Participants — see [stock-tokens.md](stock-tokens.md). ### EVM compatible "Smart contracts written in Solidity or Vyper deploy without modification, and all standard developer tooling works out of the box — including Hardhat, Foundry, ethers.js, viem, and Wagmi. Any wallet or dapp that supports standard JSON-RPC can connect directly." A short list of Nitro-specific behavioural differences still applies. ### Account abstraction "Robinhood Chain has first-class support for ERC-4337 account abstraction," plus EIP-7702 support. See [account-abstraction.md](account-abstraction.md). ### Sequencer-level compliance screening The Differences page states that the chain "maintains compliance standards through sequencer-level screening" and that "any transaction associated with a sanctioned address will be excluded from inclusion," while read operations such as `eth_call`, `eth_getLogs` and balance queries "remain fully accessible and unaffected." ## Governance and Validators Governance is not token-voted. "Robinhood Chain's protocol is governed by a Security Council of eight signers. Robinhood holds two of the eight seats, and the remaining six seats are held by independent institutions." Routine actions require 6-of-8 approval and are "subject to a seven-day on-chain timelock before execution"; emergency actions "bypass the timelock but require approval from seven of eight signers." The eight seats as documented: BitGo, Inc. (1), Chainlink Labs (1), Fireblocks Trust Company (1), Offchain Labs (1), Paxos (1), Robinhood (2), Talos (1). Dispute resolution uses BoLD (Bounded Liquidity Delay) "secured by a permissioned set of validators". At capture time the chain "currently has two validators, operated by Offchain Labs and Alchemy." Running a validator "necessitates being included in the allowlist and staking a 1 WETH bond". ## Mainnet Timeline The About page states plainly: "Robinhood Chain is live." **No mainnet launch date, genesis date, or version history appears anywhere in the captured sources.** The Notices & Upgrades page — the place a timeline would live — was captured with its notices table present but empty (headers `Date / Notice / Status`, no rows). Do not infer a launch date from these sources. ## Ecosystem Partners as Listed The About page lists partners by category, including: Alchemy (RPC & AA infrastructure, "Recommended RPC provider"), Chainlink (oracles), LayerZero (cross-chain bridge), Uniswap (public DEX), Rialto (PropAMM / aggregator), Morpho (lending), Lighter and Arcus (perps), Paxos/USDG (stablecoin), Fireblocks and BitGo (institutional custody), Allium and Entropy Advisors (analytics), Zerion (wallet data), TRM Labs (compliance & risk), Coingecko (token tracking). The page carries its own disclaimer: "Inclusion on this page does not constitute an endorsement, partnership, affiliation, sponsorship, or warranty by Robinhood." ## Related Concepts - [connecting.md](connecting.md) — RPC endpoints, explorer, wallet configuration - [gas-and-fees.md](gas-and-fees.md) - [transaction-finality.md](transaction-finality.md) - [differences-from-ethereum.md](differences-from-ethereum.md) - [stock-tokens.md](stock-tokens.md) ## Sources - `raw/web_community-about-robinhood-chain-robinhood-chain-documentation.md` - `raw/web_community-connecting-to-robinhood-chain-robinhood-chain-documentation.md` - `raw/web_community-governance-robinhood-chain-documentation.md` - `raw/web_community-run-a-robinhood-chain-full-node-robinhood-chain-documentatio.md` - `raw/web_community-notices-upgrades-robinhood-chain-documentation.md` --- title: "Doppler Airlock" type: entity tags: [doppler, airlock, contract, modules, launch] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/llms_txt_doc-contract-addresses.md", "raw/llms_txt_doc-explainer.md", "raw/llms_txt_doc-sdk-api.md", "raw/llms_txt_doc-data-indexing.md", "raw/llms_txt_doc-liquidity-migration.md", "raw/llms_txt_doc-static-auctions.md"] confidence: medium --- # Doppler Airlock The Airlock is the single entry point to the Doppler protocol. This page records only what the captured sources state verbatim, and is explicit about what they do not state. ## Address on Robinhood Chain | Chain | Address | | --- | --- | | Robinhood Mainnet (4663) | `0xeb7c034704ef8dcd2d32324c1545f62fb4ad0862` | Deployment transaction: `0x8ffd957b1985578fd9bfb8ce651bf546cb262f3b157f02f93b26c585046b291a`, at commit `bda077cf`. **Resolve the Airlock per chain — never assume, in either direction.** Its address differs across most networks in Doppler's table (Ethereum Mainnet `0xde3599a2ec440b296373a983c85c365da55d9dfa`; Monad Mainnet and Base share `0x660eAaEdEBc968f8f3694354FA8EC0b4c5Ba8D12`, differing only in casing) — **but Arbitrum One (42161) carries the same Airlock address as Robinhood Mainnet (4663)**. So a match proves nothing about which chain you are on, and a mismatch is the norm rather than the exception. Resolve it via `getAddresses(chainId)` rather than carrying an address between chains. The docs add: "If there are contracts not reflected here but claiming to be instances of Doppler, they are not considered canonical. Use with caution." ## What the Airlock does > "Doppler's Airlock smart contract provides a unified interface for > interacting with the protocol. Users pass their desired parameters into the > Airlock, which then manages all interactions with downstream contracts - > including token factories, hook initializers, governance factories, and any > other contracts configured for a given launch." Source: (linked by the docs; the contract source itself was not captured). ## Modules "Smart contracts called 'modules' can be added to Doppler and used alongside the Airlock and rest of the protocol. This provides necessary customization or differentiation while still utilzing the rest of Doppler's end to end battle tested infrastructure. For example, teams could implement a custom module to migrate liquidity to a non-Uniswap AMM, or into a different DeFi protocol entirely, or teams choose to implement custom modules for specific compliance considerations or requirements." The module slots that the SDK exposes as advanced overrides — each takes an address — are, verbatim: ``` withOpeningAuctionInitializer(address) withOpeningAuctionPositionManager(address) withAirlock(address) withTokenFactory(address) withDopplerDeployer(address) withGovernanceFactory(address) withV2Migrator(address) withV4Migrator(address) withNoOpMigrator(address) ``` The concrete module contracts deployed alongside the Airlock on 4663 — `DopplerERC20V1Factory`, `UniswapV4Initializer`, `LockableUniswapV3Initializer`, `DopplerHookInitializer`, `RehypeDopplerHookInitializer`, `GovernanceFactory`, `NoOpGovernanceFactory`, `LaunchpadGovernanceFactory`, `TimelockFactory`, `NoOpMigrator`, `UniswapV2MigratorSplit`, `DopplerHookMigrator`, `RehypeDopplerHookMigrator` — are addressed in [Doppler launches](../concepts/doppler-launches.md). ## The Airlock owner and beneficiary Two SDK helpers read the Airlock's privileged party: | Method | Returns | | --- | --- | | `getAirlockOwner()` | `Promise
` | | `getAirlockBeneficiary(shares?)` | `Promise` — defaults to 5% (0.05e18 WAD) | `getAirlockOwner` is also importable standalone: `import { DopplerSDK, getAirlockOwner } from '@whetstone-research/doppler-sdk'`, called as `await getAirlockOwner(publicClient)`. The owner is not merely informational — it is contract-enforced on V4 migrations: "Contract enforces: airlock owner must receive at least 5% of streamed fees (add as a beneficiary if applicable)." The rehype rules restate it as "protocol owner needs at least 5%". ## Events The one Airlock event named in the captured sources is from the indexer's supported-events table: | Contract | Event | Protocol | Description | | --- | --- | --- | --- | | `Airlock` | `Migrate` | V2 | "A V3 pool migrating its liquidity to a new V2 pool." | **The `Create` events in that table are emitted by the initializers, not by the Airlock**: `UniswapV3Initializer` → `Create` ("Creation of a new Doppler V3 pool") and `UniswapV4Initializer` → `Create` ("Creation of a new Doppler V4 pool"). Do not attribute a `Create` event to the Airlock on the basis of these sources. No event topic hashes, indexed-parameter lists, or ABI fragments for any of these events appear in the captured sources, so none are reproduced here. ## What the captured sources do NOT document Called out explicitly because these are load-bearing for an integration: - **No `create()` signature.** No function selector, parameter struct (`CreateParams` or otherwise), argument order, or return values for an Airlock create call appears anywhere in the captured sources. Launches are documented exclusively through the SDK's builder + factory surface (`sdk.factory.createStaticAuction(params)`, `sdk.factory.createDynamicAuction(params)`, `sdk.factory.createMulticurve(params)`, `sdk.factory.createOpeningAuction(params)`), which return `{ poolAddress, tokenAddress }`, `{ hookAddress, tokenAddress, poolId }`, `{ poolId, tokenAddress }` and `{ hookAddress, tokenAddress, poolId }` respectively. - **No `getAssetData`.** The identifier does not appear in any captured source. Its return shape is therefore not recorded here. The indexer schema describes an `asset` entity — "Represents a DERC20 token in the context of its specific Doppler pool, linking it to governance, migrators, etc." — but that is the indexer's database schema, not a contract getter, and equating the two would be a guess. - **No `Create` event ABI on the Airlock** (see above). - **No module-state or module-role enum** (no `ModuleState`, no `setModuleState`). Read these from the verified contract source on Blockscout at the 4663 address above, or from `Airlock.sol` in the Doppler repository, before writing an integration against them. ## Related pages - [Doppler launches](../concepts/doppler-launches.md) - [Protocol contracts](../concepts/protocol-contracts.md) --- title: "Lighter Domains on Robinhood Chain" type: entity tags: [lighter, orderbook, perps, deposits, withdrawals] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-robinhood-chain-lighter-domains-robinhood-chain-documentatio.md", "raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-about-robinhood-chain-robinhood-chain-documentation.md", "raw/web_community-transaction-finality-robinhood-chain-documentation.md"] confidence: medium --- # Lighter Domains on Robinhood Chain Everything on this page comes from the Robinhood Chain Lighter Domains page as captured on 2026-09-09. ## What a Lighter Domain is > "Lighter Domains are independent Lighter instances with separate execution, > sequencing, blockspace, and liquidity. That separation is intentional — > allowing markets to serve different ecosystems, partners, and regulatory > requirements. Long-term, they are designed to preserve separation where it > matters while enabling future connectivity through proof aggregation and > verified messaging." Note the tense on connectivity: proof aggregation and verified messaging are described as a long-term design intent, not a present capability. ## The Robinhood Chain Instance > "The **Robinhood Chain Instance** is a dedicated Lighter instance deployed on > the Robinhood Chain. It is not the same as Lighter Core — it has its own > contracts, sequencer, blockspace, and liquidity." That distinction is load-bearing: an integration built against Lighter Core does not automatically reach this instance, and liquidity is not shared between them. ## Key information | Resource | Address | | --- | --- | | Public UI | `https://robinhoodchain.lighter.xyz` | | Lighter Contract | `0x94bAB9693Ba2f6358507eFfcbd372b0660AFfF9d` | | API Docs | `https://apidocs.rh.lighter.xyz/docs/get-started` | | API Base URL | `https://api.rh.lighter.xyz/` | One contract address is published; the page does not enumerate any other Lighter contracts, and does not give a testnet equivalent. ## Depositing ### Direct deposit (same-chain, on RH Chain) Described as "preferred for RH Wallet". Call `deposit` on the Lighter contract directly: ```solidity function deposit( address _to, uint16 _assetIndex, TxTypes.RouteType _routeType, // uint8 uint256 _amount ) external payable ``` Worked example from the page (a USDG deposit): ``` _to = _assetIndex = 3 // USDG _routeType = 0 _amount = 1000000 // 1 USDG = 1e6 (6 decimals) ``` Two permission facts, stated plainly: "Anyone can call `deposit` on behalf of any address. The account is created on the first deposit." Only `_assetIndex = 3` (USDG) is published; the page gives no index table for other assets. Note the decimal difference — USDG is treated as 6 decimals here, whereas Robinhood Stock Tokens are 18-decimal ERC-20s. Do not reuse a scaling factor across the two. ### Cross-chain / intent address deposit "For deposits originating from other chains (e.g., Ethereum → Robinhood Chain)": 1. "Call `createIntentAddress` to get a deterministic deposit address." 2. "Send USDG to that intent address (no `deposit()` call needed)." 3. "Lighter monitors the intent address and calls `deposit` on-chain via `CREATE2` (1 block + 1 round trip)." 4. "The monitoring service credits the user (1 block + 1 round trip)." Preserve the trust shape here: steps 3 and 4 are performed by a Lighter monitoring service, not by the depositor and not trustlessly by the contract. The intent-address path is documented only for USDG. ## Withdrawing "Two modes, both operational on Robinhood Chain": - **Fast Withdraw** — "uses Robinhood Chain's soft finality; near-instant." - **Secure Withdraw** — "standard L2 withdrawal with full finality guarantees." The two modes trade different guarantees. Robinhood Chain's own finality page defines a soft confirmation as: "The sequencer has committed to your transaction's inclusion and ordering. Reversible only if the sequencer posts a batch with a different transaction order." Full Ethereum finality is a separate, later stage. **Analysis:** Fast Withdraw is therefore fast because it accepts the sequencer's commitment rather than waiting for Ethereum; the sources do not quantify the residual risk or state who bears it. ## Where Lighter fits in the chain's DeFi surface Lighter is listed among the chain's ecosystem partners under "Perps", alongside Arcus. The Stock Tokens integration guidance points at it for orderbook liquidity: "Stock Tokens also trade on Lighter (spot & perps). Refer to the Lighter Domain for specific integration details." The ecosystem listings carry Robinhood's standard disclaimer: "Inclusion on this page does not constitute an endorsement, partnership, affiliation, sponsorship, or warranty by Robinhood." ## Not documented in the captured sources - Any function signature other than `deposit` and the named `createIntentAddress` (no parameters, return type, or visibility are given for `createIntentAddress`). - The `TxTypes.RouteType` enum's other values — only `_routeType = 0` appears. - Asset indices other than `3` (USDG). - Any fee, minimum, or limit for deposits or either withdrawal mode. - Whether the Lighter contract is upgradeable, and by whom. ## Related pages - [Bridging](../concepts/bridging.md) - [Token contracts](../concepts/token-contracts.md) - [Protocol contracts](../concepts/protocol-contracts.md) --- title: "Activity Log" type: log --- # Activity Log Append-only record of all wiki changes. ## 2026-09-09 — initial build - **Source/Trigger**: New wiki. Gathered via `source-pipeline/specs/robinhood-chain.json`. - **Sources captured**: 49 immutable records — 22 pre-rendered pages from `docs.robinhood.com/chain`, 24 from `docs.doppler.lol` (via its `llms.txt` index), Chainlink's Robinhood tokenized-equities page, and two Uniswap captures (the v4 deployments page and `developers.uniswap.org/llms.txt`). All fetched deterministically (httpx + BeautifulSoup) with `source_url` / `fetched` provenance. No model-generated text entered `raw/`. - **Gather note worth keeping**: the docs site is a client-rendered vocs SPA. Every bare path returns the same 535-byte application shell; only the `/index.html` form is pre-rendered. The page list was enumerated from the site's own JavaScript bundle (`chain//index.mdx` entries) rather than guessed. A naive crawl of this site captures nothing while appearing to succeed. - **Pages created**: 21 concepts, 2 entities, 2 syntheses, plus index and the documentation catalog. - **Deliberate omissions** (recorded in `syntheses/what-this-wiki-cannot-tell-you.md`): - **All per-ticker Stock Token addresses.** The Token Contracts table renders from on-chain state and captured as `Loading tokens…`. Only WETH and USDG are static in the source. The docs' own warning — that a token with a matching ticker but a different address is not a Robinhood Stock Token — makes publishing a guessed address actively dangerous, so none are published. - **All Chainlink feed proxy addresses, heartbeats and deviation thresholds.** Robinhood defers to Chainlink as source of truth; Chainlink's feed table is client-rendered and did not capture. - **No feed coverage claim.** Robinhood's Stock Tokens page states that "every Stock Token has a live Chainlink price feed". That is recorded as Robinhood's claim and attributed, not adopted, because the artifact that would confirm it is the table that did not capture. - **No role registry, beacon-proxy pattern, or blocklist.** No captured source describes any of these. The build brief presumed a beacon proxy and an access-controls registry; neither is documented upstream, so the affected pages were rewritten to inventory only the powers the docs actually disclose, with an explicit statement that absence from documentation is not absence from the chain. - **No launch date or upgrade history.** The Notices & Upgrades page captured with its column headers and zero rows. - **Upstream contradictions recorded, not resolved**: 1. `tradingCapabilities` is documented with two incompatible schemas — no shared field names, no shared value vocabulary — on two pages describing the same endpoint. Both are reproduced side by side. 2. Terms of Service §5.7(j) prohibits describing Stock Tokens as "tokenized stocks" or "tokenized equities", while Robinhood's own Building page and Chainlink's page both do exactly that. This wiki uses the approved terminology and documents that the restriction exists. 3. Oracle-pause behavior differs by source: Chainlink says the feed "stops publishing new prices and holds the last known good value"; Robinhood says the flag "is advisory and not enforced on-chain, so a paused oracle may still return a value". Both are quoted. 4. Robinhood lists staleness (`updatedAt` versus heartbeat) first among its best practices and names it the primary guard relative to the pause flag; Chainlink states these feeds "do not have heartbeats during off-hours" — precisely the window in which Stock Tokens remain tradable 24/7 but underlying equity feeds are 24/5. Analysed in `syntheses/reading-a-stock-token-price.md`. - **Doppler scoping**: only three items in the Doppler corpus are explicitly scoped to chain 4663 — the Robinhood Mainnet (4663) address table, its entry in the deployed-network list, and Universal Router `2.1.1` on chain ID `4663`. Everything else is generic or Base-scoped, and every SDK example instantiates `base`/`baseSepolia`. Those pages carry an explicit scoping warning. - **Verification**: `verify_wiki.py` reports 0 errors. Mechanical only — it checks frontmatter, links, phantom citations and size, never whether a claim is true. Every hex literal in every page was string-matched back into a cited raw file before publication. --- title: "Robinhood Chain Documentation Catalog" type: summary tags: [catalog, documentation, coverage, map] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-account-abstraction-robinhood-chain-documentation.md", "raw/web_community-add-network-to-your-wallet-robinhood-chain-documentation.md", "raw/web_community-bridging-robinhood-chain-documentation.md", "raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-connecting-to-robinhood-chain-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-token-contracts-robinhood-chain-documentatio.md", "raw/web_community-cross-chain-messaging-robinhood-chain-documentation.md", "raw/web_community-data-streams-robinhood-chain-documentation.md", "raw/web_community-deploy-a-contract-robinhood-chain-documentation.md", "raw/web_community-differences-from-ethereum-robinhood-chain-documentation.md", "raw/web_community-gas-fees-robinhood-chain-documentation.md", "raw/web_community-governance-robinhood-chain-documentation.md"] confidence: high --- # Robinhood Chain Documentation Catalog A map of the upstream documentation surface at `docs.robinhood.com/chain`, so you can tell whether a topic exists upstream before concluding this wiki does not cover it. The docs site is a client-rendered SPA: pages were captured at their `/index.html` URLs, which are pre-rendered, and several tables on those pages populate from on-chain state after load and therefore did not capture at all. **22 pages captured 2026-09-09.** Sizes are the captured text, and a small one is a signal: it usually means the page is a stub, or that its substance renders client-side and did not survive capture. | Path | Page | Captured | |---|---|---| | `/chain/account-abstraction/index.html` | Account Abstraction | 6,876b | | `/chain/add-network-to-wallet/index.html` | Add network to your wallet | 1,060b ⚠️ thin | | `/chain/bridging/index.html` | Bridging | 2,952b | | `/chain/building-with-stock-tokens/index.html` | Building with Stock Tokens | 9,805b | | `/chain/connecting/index.html` | Connecting to Robinhood Chain | 2,891b | | `/chain/contracts/index.html` | Robinhood Chain Token Contracts | 872b ⚠️ thin | | `/chain/cross-chain-messaging/index.html` | Cross-Chain Messaging | 5,303b | | `/chain/data-streams/index.html` | Data Streams | 2,092b | | `/chain/deploy-smart-contracts/index.html` | Deploy a Contract | 5,383b | | `/chain/differences-from-ethereum/index.html` | Differences from Ethereum | 3,849b | | `/chain/gas-and-fees/index.html` | Gas & Fees | 1,655b | | `/chain/governance/index.html` | Governance | 1,411b ⚠️ thin | | `/chain/index.html` | About Robinhood Chain | 5,194b | | `/chain/lighter-domains/index.html` | Robinhood Chain Lighter Domains | 2,494b | | `/chain/notices-and-upgrades/index.html` | Notices & Upgrades | 1,172b ⚠️ thin | | `/chain/oracles-and-price-feeds/index.html` | Oracles & Price Feeds | 6,533b | | `/chain/protocol-contracts/index.html` | Robinhood Chain Contracts | 4,593b | | `/chain/run-a-full-node/index.html` | Run a Robinhood Chain full node | 7,776b | | `/chain/stock-token-apis/index.html` | Stock Token APIs | 11,708b | | `/chain/stock-tokens/index.html` | Stock Tokens | 7,693b | | `/chain/terms-of-service/index.html` | Robinhood Chain Terms of Service | 79,681b | | `/chain/transaction-finality/index.html` | Transaction Finality | 2,332b | ## Thin captures 4 of 22 captures came in under 1,500 bytes: - `/chain/add-network-to-wallet/index.html` — Add network to your wallet (1,060b) - `/chain/contracts/index.html` — Robinhood Chain Token Contracts (872b) - `/chain/governance/index.html` — Governance (1,411b) - `/chain/notices-and-upgrades/index.html` — Notices & Upgrades (1,172b) For these, prefer the live page over this wiki: either the upstream page is genuinely brief, or its content is dynamic and this KB never saw it. --- title: "Reading a Stock Token Price Safely" type: synthesis tags: [oracles, chainlink, staleness, integration, corporate-actions] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md", "raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md", "raw/web_community-stock-tokens-robinhood-chain-documentation.md", "raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md"] confidence: medium --- # Reading a Stock Token Price Safely Two organisations document these price feeds, and they do not say the same thing. Robinhood issues the token and writes the multiplier; Chainlink operates the feed. Reading only one of the two leaves a real gap in an integration. This page sets their statements against each other. Everything below is quoted from sources captured **2026-09-09**. It is integration mechanics, not advice about whether to hold, trade, or price anything. ## What the feed actually reports The feed does **not** report the underlying equity's market price. Chainlink's page states the formula: > Token Price = Underlying Equity Market Price × Multiplier The multiplier is read from the token contract via `uiMultiplier()` and "accounts for dividend reinvestments and corporate action adjustments." The published value is therefore a **Total Return Value**, which will drift away from the headline share price of the same ticker over time — by design. **Analysis:** anything that compares a Stock Token feed against an ordinary equity quote for the same ticker is comparing two different quantities. The divergence is the accumulated multiplier, not a mispricing. ## The disagreement that matters Robinhood's Oracles page lists staleness first among its best practices, and elsewhere names it the primary guard *relative to the pause flag*: > Check staleness — compare `updatedAt` against the feed's heartbeat; reject > stale prices. and, on the pause flag: > The flag is advisory and not enforced on-chain, so a paused oracle may still > return a value — keep your staleness check (`updatedAt` vs. heartbeat) as the > primary guard rather than relying on the flag alone. Chainlink's page describes off-hours behavior: > When underlying equity markets are closed (weekends, holidays, thin overnight > windows), the feed may hold the last published price even though the contract > remains callable via `latestRoundData()`. **These feeds do not have heartbeats > during off-hours.** **Analysis — this is the load-bearing conflict.** The guard Robinhood names as primary is defined in terms of a heartbeat that Chainlink says does not exist during off-hours. The window where the two disagree is not an edge case: Stock Tokens are documented as "self-custodied and 24/7", while the underlying equity prices come from 24/5 session feeds. So every weekend, holiday and thin overnight window is a period in which tokens remain transferable and swappable while the recommended staleness check has no defined threshold to compare against. An implementation that literally follows the Robinhood best-practice list will either reject every price for the whole weekend, or — if it defaults a heartbeat value — accept an arbitrarily old one. Neither source resolves this; this paragraph is the wiki's reading of the two together, not an upstream statement. ## The pause flag, from both sides | | Robinhood (issuer) | Chainlink (feed operator) | |---|---|---| | What `oraclePaused()` is | "advisory and **not enforced on-chain**, so a paused oracle **may still return a value**" | the feed "honors" it | | Feed behavior when paused | not stated | "stops publishing new prices and **holds the last known good value**" | | What to do | treat as "price temporarily unavailable"; keep staleness as the primary guard | read `updatedAt`; the contract stays callable | These are reconcilable as publisher-side versus consumer-side descriptions — Chainlink describes what its publisher does, Robinhood warns that nothing on chain compels it. **Analysis:** the safe reading is the intersection, not either alone. A paused oracle can return a value, and that value can be arbitrarily stale, and `latestRoundData()` will not error in either case. ## What a defensive read has to do Drawn from both sources together; the sequence is the wiki's synthesis: 1. **Read `decimals()`.** The Oracles page says never to hard-code it. Note that the Building page's own example hard-codes `1e8` — an inconsistency within Robinhood's docs, flagged here rather than resolved. 2. **Reject non-positive answers.** Both sources call for this. 3. **Check `oraclePaused()` on the token contract** — but treat `false` as necessary, not sufficient, given that it is advisory. 4. **Bound staleness on your own terms.** Because no heartbeat is defined off-hours, a fixed `updatedAt` threshold is the only thing under your control. Decide deliberately what your protocol does when the last update is older than that: the sources give no default. 5. **Expect discontinuities around corporate actions.** A staged multiplier is visible before it is active: `newUIMultiplier()` holds the pending value and `effectiveAt()` its activation time, and `UIMultiplierUpdated` fires "whenever the multiplier changes **or a new value is staged**" — so seeing the event does not mean the active multiplier has moved yet. ## Where the addresses are This wiki publishes **no feed proxy addresses**. Robinhood's page defers to Chainlink — "it's the source of truth, so always read addresses and parameters from there rather than hardcoding them" — and Chainlink's feed table is rendered client-side and did not survive capture on 2026-09-09. The same is true of the canonical token addresses: the Token Contracts page carries the warning that "a token with a matching name/ticker but a different contract address is not a Robinhood Stock Token", and that identifying table is exactly what a capture cannot retrieve. Only WETH (`0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73`) and USDG (`0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168`) are static in the source. **Do not treat any per-ticker address or feed address as knowable from this wiki.** Resolve both from their live sources at integration time. See [what this wiki cannot tell you](what-this-wiki-cannot-tell-you.md). ## Related - [oracles and price feeds](../concepts/oracles-and-price-feeds.md) - [UI multipliers](../concepts/ui-multipliers.md) - [stock tokens](../concepts/stock-tokens.md) - [building with stock tokens](../concepts/building-with-stock-tokens.md) ## Sources - `raw/web_community-robinhood-tokenized-equities-chainlink-documentation.md` - `raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md` - `raw/web_community-stock-tokens-robinhood-chain-documentation.md` - `raw/web_community-building-with-stock-tokens-robinhood-chain-documentation.md` --- title: "What This Wiki Cannot Tell You (and Where to Get It)" type: synthesis tags: [scope, verification, abstention, provenance, addresses] created: 2026-09-09 updated: 2026-09-09 sources: ["raw/web_community-robinhood-chain-token-contracts-robinhood-chain-documentatio.md", "raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md", "raw/web_community-notices-upgrades-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-contracts-robinhood-chain-documentation.md", "raw/web_community-robinhood-chain-terms-of-service-robinhood-chain-documentati.md", "raw/llms_txt_doc-contract-addresses.md"] confidence: high --- # What This Wiki Cannot Tell You (and Where to Get It) A knowledge base is only useful if it is honest about its edges. This page is the boundary: things an agent might reasonably expect to find here, that are genuinely **not** established by the sources this wiki was built from. Each entry says where the real answer lives. Sources were captured **2026-09-09** from `docs.robinhood.com/chain`, `docs.chain.link`, `docs.doppler.lol` and `docs.uniswap.org`. ## Per-ticker Stock Token addresses — not recoverable The Token Contracts page publishes exactly two static addresses, WETH and USDG. The per-ticker table is rendered from on-chain state at page load and captured as the literal string `Loading tokens…`. This matters more than a normal gap, because the same page warns: > Use the addresses on this page to identify the **canonical** Robinhood Stock > Token for each underlying — a token with a matching name/ticker but a > different contract address is not a Robinhood Stock Token. The identifying table is precisely what a capture cannot obtain. Sample addresses do appear inside API example payloads in the docs, including an obviously synthetic `0xAbCdEf0123456789…` for AAPL; **none of them are a published canonical list** and this wiki does not reproduce them as such. **Get it from:** the live Token Contracts page, or the chain itself. ## Chainlink feed addresses, heartbeats, deviation thresholds — not recoverable Robinhood's Oracles page defers entirely: Chainlink's page "is the source of truth, so always read addresses and parameters from there rather than hardcoding them." Chainlink's feed table is client-rendered and did not survive capture — only the surrounding prose did. **Consequence:** this wiki asserts **no feed count and no coverage claim.** Robinhood's Stock Tokens page states that "every Stock Token has a live Chainlink price feed"; that is reproduced as Robinhood's claim, attributed, and not adopted as fact, because the one artifact that could confirm it is the table that did not capture. Verify a specific ticker has a feed before depending on one existing. **Get it from:** Chainlink's Robinhood tokenized equities page. ## Whether a role/permission registry exists — outside these sources Nothing in any captured source describes a role registry, a `*_ROLE` constant, `grantRole`/`hasRole`, an address blocklist, or a token-wide transfer pause. The issuer powers this wiki documents are only those the docs disclose: `updateMultiplier`, `pauseOracle`/`unpauseOracle`, sequencer-level transaction screening, the Security Council, and proxy admins whose owners are not documented. **Analysis:** absence from documentation is not absence from the chain. A contract can hold powers its public docs never mention, and the honest position is that this wiki does not know either way. Anyone reasoning about trust assumptions should read the deployed contracts rather than rely on this page. **Get it from:** verified sources on a block explorer or Sourcify, and the deployed bytecode. ## When the chain launched, and its upgrade history — not stated No captured source gives a launch date, genesis date, or version history. The Notices & Upgrades page — where a timeline would live — captured with its `Date / Notice / Status` headers and **zero rows**. This wiki therefore does not date the chain's launch and does not pose as an upgrade calendar. Point-in-time values that *were* captured (a Nitro image tag, an ArbOS version) are labelled as of 2026-09-09 on their pages. ## Doppler behavior specific to chain 4663 — mostly unscoped Of the Doppler corpus, only three things are explicitly scoped to this chain: the "Robinhood Mainnet (4663)" address table, its presence in the deployed-network list, and Universal Router version `2.1.1` on chain ID `4663`. Everything else — auction types, migration options, hook callbacks, the protocol fee, the rehypothecation model, governance defaults — is written generically, and every SDK example in the sources instantiates `base` or `baseSepolia`, never 4663. Those pages are reproduced here as chain-agnostic protocol documentation with that warning attached. **Do not assume a documented Doppler behavior applies on 4663 without checking**, and resolve addresses via the SDK's own `getAddresses(4663)` rather than transplanting them from another chain's table. ## Two upstream contradictions this wiki records but does not resolve - **`tradingCapabilities` has two incompatible schemas.** The Stock Tokens page and the Stock Token APIs page document the same field on the same endpoint with no shared field names and no shared value vocabulary. Both are reproduced side by side in [stock token APIs](../concepts/stock-token-apis.md). - **The Terms of Service forbid the terminology the rest of the docs use.** §5.7(j): "You must not describe, refer to, or market 'Stock Tokens' … as 'tokenized stocks,' 'tokenized equities,' or similar characterizations," with approved terminology being "Stock Tokens" or "tokenized real-world assets such as Stock Tokens." Robinhood's own Building page nonetheless says "Tokenized stocks trade via RFQ at launch", and Chainlink titles its page "Robinhood Tokenized Equities". This wiki uses the approved terminology and documents that the restriction exists. ## What this wiki deliberately does not do It does not give trading, investment or financial advice, and it does not evaluate any token as an opportunity. It documents how the chain and its contracts work. ## Sources - `raw/web_community-robinhood-chain-token-contracts-robinhood-chain-documentatio.md` - `raw/web_community-oracles-price-feeds-robinhood-chain-documentation.md` - `raw/web_community-notices-upgrades-robinhood-chain-documentation.md` - `raw/web_community-robinhood-chain-contracts-robinhood-chain-documentation.md` - `raw/web_community-robinhood-chain-terms-of-service-robinhood-chain-documentati.md` - `raw/llms_txt_doc-contract-addresses.md`