Most of the catalog is queryable for X Layer, from the blocks themselves to the daily activity of the projects that run on it.
The chain’s own record sits in the xlayer dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the X Layer rows are selected with chain_id = 'xlayer'.
The section mirrors the catalog itself: the core entities, then the market verticals with data on X Layer.
Layers
| Layer | Since | What it holds |
|---|
| Raw | 2024-03 | Blocks, transactions, logs and internal calls. |
| Projects | 2024-03 | Daily Fees and Revenue for each tracked project, broken out to X Layer. |
| Assets | 2024-03 | Every curated asset issued on X Layer, 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. |
| Contracts | 2024-03 | Every contract deployed on X Layer, with the account that created it. |
| Stablecoins | 2024-03 | Every stablecoin issued on X Layer: supply, holders and transfers. |
| Bridges | 2025-10 | Cross-chain transfers that left X Layer or arrived on it, matched leg to leg. |
Filtering
chain_id reads xlayer wherever a catalog table has a chain column, so the same filter selects X Layer 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, named by 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.
