Chains
Robinhood Chain today, more coming. How chain scoping works, and what stays separate per chain.
Every data route is chain-scoped. The chain is part of the path, and it is required:
GET /index/v1/{chain}/tokens/{address}{chain} is a slug the deployment is configured to serve, not a raw chain id. Asking for a slug it does not serve returns a typed refusal that lists the slugs it does serve. It never quietly falls back to a default chain, because answering the wrong chain's data is worse than answering nothing.
Available today
| Chain | Slug | Chain id | Native asset | Status |
|---|---|---|---|---|
| Robinhood Chain | robinhood | 4663 | ETH (18 decimals) | Serving |
More chains are planned. The boundary was designed up front so adding one is configuration and an ingest adapter, not a rewrite.
The current Robinhood deployment ingests from the chain's sequencer feed, with sequencer-ordered finality and a bounded maximum reorg depth. These are deployment properties, not assumptions a client should duplicate; read the snapshot and coverage fields returned by each response.
What a chain declares
A chain is not just an id. Each one declares the following, and the deployment refuses to start if a chain is only half-declared. A half-declared chain would not return no answers, it would return plausible wrong ones.
| Property | Meaning |
|---|---|
| Ingest adapter | How blocks arrive, whether a sequencer feed or plain JSON-RPC |
| Finality model | Whether the chain exposes tiers beyond its head |
| Reorg depth | How far the chain may rewind, which bounds cursor validity |
| Native asset | Symbol and decimals |
| Wrapped native | The ERC-20 wrapper, required for USD marking |
| AMM authorities | Which pool-creating protocols this build recognises |
| Launchpad table | Which launchpads this build decodes |
Anything not declared is absent rather than assumed. A deployment with no AMM authorities configured serves no pool identity at all, and the routes that depend on it say so instead of inventing a venue.
What stays separate per chain
This is the part that matters when the second chain arrives, and it is worth building against now.
Separate stores. Each chain has its own index, its own reorg state, and its own cursors. A cursor minted against one chain is not valid on another and will be refused.
Separate snapshots. Each chain has its own head and its own reorg timeline, so there is no such thing as one (block, hash) spanning two chains. A multi-chain response carries one snapshot per chain plus a per-chain status.
No silent omission. A response that was asked for three chains covers exactly three chains. A chain that could not be reached is a typed unavailable, never dropped from the result. An omitted chain would read as a chain with no data, which is a different and false claim.
If you are writing a client today against one chain, the thing to get right now is that the chain segment is not decorative and the snapshot is per chain. Code that assumes a single global head will need changing later; code that reads the snapshot off each chain's own block will not.
Indexer overview
A read-only chain node, indexer, and HTTP read API. Stores canonical chain records and serves searchable views over them, without ever signing or sending a transaction.
What it stores
How a number was derived, and the rules that decide what a value means. Absence, quote units, transfer-derived balances, labelled approximations, and trace coverage.