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

Layers

LayerSinceWhat it holds
Raw2015-07Blocks, transactions, logs and internal calls, plus two tables only Ethereum carries.
Projects2020-05Daily trading and bridge volume for each tracked app and project, broken out to Ethereum.
Assets2017-11Every curated asset issued on Ethereum, with daily supply, holders and transfer activity.
Tokens2015-10Every 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.
Stablecoins2017-11Every stablecoin issued on Ethereum: supply, holders and transfers.
Tokenized assets2018-09Tokenized stocks, funds and commodities issued on Ethereum, tracked against their underlying instruments.
DEX2020-05Trading pools, their daily volume, value locked and fees.
LendingIn progressThe lending markets deployed on Ethereum, the asset each one lends, and the lending facts.
Bridges2022-09Cross-chain transfers that left Ethereum or arrived on it, matched leg to leg.

Filtering

chain_id reads ethereum in every catalog table that mentions a chain, so the same filter selects Ethereum everywhere. Bridge transfers are the one exception: a transfer has a chain on each end and carries source_chain_id and destination_chain_id instead.
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.