metrics.chains_daily contains one row per chain per day. It carries the fees a chain earns in its own right: fees, revenue and fees_supply_side, all in USD.
Columns
| Column | Type | Description |
|---|---|---|
timestamp | TIMESTAMP | The day, truncated to UTC midnight. Partition column. |
chain_id | STRING | Chain the row measures. |
fees | FLOAT64 | Gas and sequencer fees users paid to the chain, in USD. |
revenue | FLOAT64 | The part of those fees the chain kept, in USD. |
fees_supply_side | BIGNUMERIC | The part of those fees the chain passed on to builders or operators, in USD. |
Sample queries
- One chain's series
- Monthly fees
Read one chainβs daily fees and revenue.
Notes
fees is the total users paid to transact on the chain. fees_supply_side is the part the chain passes on to builders or operators, and revenue is the part it keeps, so fees equals revenue plus fees_supply_side. HyperEVM gas is passed on to nobody, so its fees_supply_side reads zero and its revenue equals its fees.
Only chains that earn fees in their own right appear. HyperCore runs Hyperliquidβs order books and charges no gas, so it has no row here by design; its activity shows up as trading fees in the app tables. This table carries no project column, so join dimensions.chains when you need to attribute a chain to a project.
Active addresses are not in this table. Chains βΈ Transactions has one row per transaction, which is enough to work them out, minding that a count of distinct addresses never adds up across days or across chains.