Most of the catalog is queryable for Robinhood Chain, from the blocks themselves to the daily activity of the projects that run on it.
The chainβs own record sits in the robinhoodchain dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Robinhood Chain rows are selected with chain_id = 'robinhoodchain'.
The section mirrors the catalog itself: the core entities, then the market verticals with data on Robinhood Chain.
| Layer | Since | What it holds |
|---|
| Raw | 2026-04 | Blocks, transactions, logs and internal calls. |
| Projects | 2026-04 | Daily Fees and Revenue for each tracked project, broken out to Robinhood Chain. |
| Apps | 2026-06 | Daily Trading volume, TVL, Fees and Revenue for each tracked app, broken out to Robinhood Chain. |
| Assets | 2021-02 | Every curated asset issued on Robinhood Chain, with daily supply, holders and transfer activity. |
| Tokens | In progress | Every ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices. |
| Accounts | In progress | Wallets and contracts labeled with the projects that own them. |
| Stablecoins | 2026-05 | Every stablecoin issued on Robinhood Chain: supply, holders and transfers. |
| Tokenized assets | 2024-01 | Tokenized stocks, funds and commodities issued on Robinhood Chain, tracked against their underlying instruments. |
| DEX | 2026-05 | Trading pools, their daily volume, value locked and fees. |
| Bridges | 2026-05 | Cross-chain transfers that left Robinhood Chain or arrived on it, matched leg to leg. |
Filtering
chain_id reads robinhoodchain wherever a catalog table carries a chain, so the same filter selects Robinhood Chain everywhere. Some shapes ask for something else. The asset tables key on the asset or its deployment, so the chain comes from dimensions.asset_tokens, as the query below does. Project and app totals span every chain a project runs on, so one chainβs share reads from metrics_project_chains and metrics_app_chains. A bridge transfer has a chain on each end and carries source_chain_id and destination_chain_id.
Every table splits by day: the raw and event tables on block_timestamp, the daily tables on timestamp. Bound that column in every query; without a bound the query reads the whole table.