# Chains

Source: https://www.solscanner.app/docs/indexer/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 [#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 [#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 [#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.