Skip to main content
Most of the catalog is queryable for Celo, from the blocks themselves to the daily activity of the projects that run on it. The chain’s own record sits in the celo dataset: one row per block, transaction, log and internal call. Everything above that sits in the catalog, where the Celo rows are selected with chain_id = 'celo'. The section mirrors the catalog itself: the core entities, then the market verticals with data on Celo.

Layers

LayerSinceWhat it holds
Raw2020-04Blocks, transactions, logs and internal calls.
Projects2022-07Daily trading and bridge volume for each tracked app and project, broken out to Celo.
Assets2020-04Every curated asset issued on Celo, with daily supply, holders and transfer activity.
TokensIn progressEvery ERC-20 transfer, both sides of every balance move, holder balances at query time, and daily prices.
AccountsIn progressWallets and contracts labeled with the projects that own them.
Stablecoins2020-04Every stablecoin issued on Celo: supply, holders and transfers.
Tokenized assets2021-09Tokenized stocks, funds and commodities issued on Celo, tracked against their underlying instruments.
DEX2022-07Trading pools, their daily volume, value locked and fees.
LendingIn progressThe lending markets deployed on Celo, the asset each one lends, and the lending facts.
Bridges2023-04Cross-chain transfers that left Celo or arrived on it, matched leg to leg.

Filtering

chain_id reads celo wherever a catalog table carries a chain, so the same filter selects Celo 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.