The chain’s own record is queryable for ApeChain, with its eligible catalog layers above it.
The chain’s own record sits in the apechain dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the ApeChain rows are selected with chain_id = 'apechain'.
The section mirrors the catalog itself: the core entities, then the market verticals with data on ApeChain.
Layers
| Layer | Since | What it holds |
|---|
| Raw | 2024-08 | Blocks, transactions, logs and internal calls. |
| 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. |
Filtering
chain_id reads apechain wherever a catalog table has a chain column, so the same filter selects ApeChain 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.
