blocks, transactions, transaction_messages, message_events and block_events, in one dataset per chain.
The Tables section below says what each table holds and lists the columns once for the whole family.
Chains
| Chain | chain_id | blocks | transactions | transaction_messages | message_events | block_events |
|---|---|---|---|---|---|---|
| Celestia | celestia | β | β | β | β | β |
| Cosmos Hub | cosmoshub | β | β | β | β | β |
| dYdX | dydx | β | β | β | β | β |
| Injective | injective | β | β | β | β | β |
Tables
Cosmos chains are built from the same toolkit, so they all carry the same five tables with the same columns. The schemas below are read fromcosmoshub, and apply to every chain listed on the Cosmos overview.
One thing to know before the tables. On these chains a transaction does not do one thing: it carries a list of messages, each one a typed request such as βsend these coinsβ or βvote on this proposalβ. Running those messages emits events, which are the chainβs own notes about what happened, so the sequence is transaction, then messages, then events.
Every table except blocks is split by day on block_timestamp, and blocks on timestamp. Filter on that column in every query: with a filter the query reads only the days you asked for, without one it reads the whole table.
- blocks
- transactions
- transaction_messages
- message_events
- block_events
A block is a batch of transactions added to the chain, and the validator that put it forward is its proposer.
blocks contains one row per block.| Column | Type | Description |
|---|---|---|
timestamp | TIMESTAMP | The time the block was produced. Partition column. |
block_height | INT64 | The block height. |
transaction_count | INT64 | The number of transactions in the block. |
validators_hash | STRING | The hash of the validator set. |
proposer_address | STRING | The address of the block proposer. |
- Daily blocks and transactions
Count blocks and total transactions per day over one week.