> ## Documentation Index
> Fetch the complete documentation index at: https://tokenterminal.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> To query the Token Terminal data catalog, read https://tokenterminal.com/docs/catalog/agents-manual.md first. It is the whole catalog as one page: table naming grammar, key columns, partition and cluster rules, units, additivity, and the tables that are documented but not served yet.
> Never query a catalog table on a time bound alone. Also filter its cluster key, which you read from INFORMATION_SCHEMA.COLUMNS; an empty result means the object is a view, whose pruning contract is on its page. Compute is billed to the caller's own Google Cloud project.

# Cosmos ecosystem

> Standardized blocks, transactions, messages and events for every Cosmos chain.

These chains are all built with the same toolkit, the Cosmos SDK. On them a transaction is a bundle: it holds a list of messages, each one a typed request such as "send these coins" or "vote on this proposal". Running those messages makes the chain write events, its own notes on what happened, and the chain writes more of them at the start and end of each block, on its own account rather than for a transaction.

So each chain gets five tables, `blocks`, `transactions`, `transaction_messages`, `message_events` and `block_events`, in one dataset per chain.

The [Tables](#tables) section below says what each table holds and lists the columns once for the whole family.

## Chains

<table>
  <thead>
    <tr>
      <th width="160">Chain</th>
      <th width="130">`chain_id`</th>
      <th width="80">blocks</th>
      <th width="110">transactions</th>
      <th width="160">transaction\_messages</th>
      <th width="130">message\_events</th>
      <th width="110">block\_events</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>Celestia</td>
      <td>`celestia`</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
    </tr>

    <tr>
      <td>Cosmos Hub</td>
      <td>`cosmoshub`</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
    </tr>

    <tr>
      <td>dYdX</td>
      <td>`dydx`</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
    </tr>

    <tr>
      <td>Injective</td>
      <td>`injective`</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
      <td>✓</td>
    </tr>
  </tbody>
</table>

## Tables

Cosmos chains are built from the same toolkit, so they all have the same five tables with the same columns. The schemas below are read from `cosmoshub`, and apply to every chain listed on the [Cosmos overview](https://tokenterminal.com/docs/catalog/chain-verticals/cosmos/index.md).

One thing to know before the tables. On these chains a transaction is a bundle: it holds 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**

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.

<table>
  <thead>
    <tr>
      <th width="280">Column</th>
      <th width="130">Type</th>
      <th>Description</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`timestamp`</td>
      <td>`TIMESTAMP`</td>
      <td>The time the block was produced. Partition column.</td>
    </tr>

    <tr>
      <td>`block_height`</td>
      <td>`INT64`</td>
      <td>The block height.</td>
    </tr>

    <tr>
      <td>`transaction_count`</td>
      <td>`INT64`</td>
      <td>The number of transactions in the block.</td>
    </tr>

    <tr>
      <td>`validators_hash`</td>
      <td>`STRING`</td>
      <td>The hash of the validator set.</td>
    </tr>

    <tr>
      <td>`proposer_address`</td>
      <td>`STRING`</td>
      <td>The address of the block proposer.</td>
    </tr>
  </tbody>
</table>

**Daily blocks and transactions**

**Count blocks and total transactions per day over one week.**

```sql theme={null}
select
    timestamp_trunc(timestamp, day) as day,
    count(*) as blocks,
    sum(transaction_count) as transactions
from `cosmoshub.blocks`
where timestamp >= timestamp('2026-08-16')
  and timestamp < timestamp('2026-08-23')
group by day
order by day
```

**transactions**

A transaction is one signed submission to the chain, holding the messages that say what to do. `transactions` contains one row per transaction, with the fee it paid and whether it worked.

<table>
  <thead>
    <tr>
      <th width="280">Column</th>
      <th width="130">Type</th>
      <th>Description</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`block_height`</td>
      <td>`INT64`</td>
      <td>The height of the containing block.</td>
    </tr>

    <tr>
      <td>`block_timestamp`</td>
      <td>`TIMESTAMP`</td>
      <td>The time of the containing block. Partition column.</td>
    </tr>

    <tr>
      <td>`transaction_hash`</td>
      <td>`STRING`</td>
      <td>The hash of the transaction.</td>
    </tr>

    <tr>
      <td>`transaction_index`</td>
      <td>`INT64`</td>
      <td>The position of the transaction within the block.</td>
    </tr>

    <tr>
      <td>`transaction_info`</td>
      <td>`STRING`</td>
      <td>The transaction info string returned by the node.</td>
    </tr>

    <tr>
      <td>`transaction_log`</td>
      <td>`STRING`</td>
      <td>The execution log.</td>
    </tr>

    <tr>
      <td>`transaction_code`</td>
      <td>`INT64`</td>
      <td>The result code. Zero marks success.</td>
    </tr>

    <tr>
      <td>`transaction_fee`</td>
      <td>`INT64`</td>
      <td>The fee paid.</td>
    </tr>

    <tr>
      <td>`gas_wanted`</td>
      <td>`STRING`</td>
      <td>The gas requested.</td>
    </tr>

    <tr>
      <td>`gas_used`</td>
      <td>`STRING`</td>
      <td>The gas consumed.</td>
    </tr>
  </tbody>
</table>

**Daily success rate and fees**

**Count daily transactions, their success rate and average fee over one week.**

```sql theme={null}
select
    timestamp_trunc(block_timestamp, day) as day,
    count(*) as transactions,
    countif(transaction_code = 0) as successful,
    avg(transaction_fee) as avg_fee
from `cosmoshub.transactions`
where block_timestamp >= timestamp('2026-08-16')
  and block_timestamp < timestamp('2026-08-23')
group by day
order by day
```

**transaction\_messages**

A message is one typed request inside a transaction: send coins, delegate a stake, vote. Its type is the best single column for asking what users were doing on the chain. `transaction_messages` contains one row per message.

<table>
  <thead>
    <tr>
      <th width="280">Column</th>
      <th width="130">Type</th>
      <th>Description</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`block_timestamp`</td>
      <td>`TIMESTAMP`</td>
      <td>The time of the containing block. Partition column.</td>
    </tr>

    <tr>
      <td>`block_height`</td>
      <td>`INT64`</td>
      <td>The height of the containing block.</td>
    </tr>

    <tr>
      <td>`transaction_hash`</td>
      <td>`STRING`</td>
      <td>The hash of the containing transaction.</td>
    </tr>

    <tr>
      <td>`transaction_index`</td>
      <td>`INT64`</td>
      <td>The position of the transaction within the block.</td>
    </tr>

    <tr>
      <td>`message_index`</td>
      <td>`INT64`</td>
      <td>The position of the message within the transaction.</td>
    </tr>

    <tr>
      <td>`message_type`</td>
      <td>`STRING`</td>
      <td>What kind of request this is, written as a full type path such as `/cosmos.bank.v1beta1.MsgSend`.</td>
    </tr>

    <tr>
      <td>`message`</td>
      <td>`STRING`</td>
      <td>The message payload.</td>
    </tr>
  </tbody>
</table>

**Message types**

**Rank message types by count over one week.**

```sql theme={null}
select
    message_type,
    count(*) as messages
from `cosmoshub.transaction_messages`
where block_timestamp >= timestamp('2026-08-16')
  and block_timestamp < timestamp('2026-08-23')
group by message_type
order by messages desc
limit 20
```

**message\_events**

An event is a note the chain writes while it runs a message: coins moved, a stake changed. `message_events` contains one row per event a transaction produced.

<table>
  <thead>
    <tr>
      <th width="280">Column</th>
      <th width="130">Type</th>
      <th>Description</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`block_timestamp`</td>
      <td>`TIMESTAMP`</td>
      <td>The time of the containing block. Partition column.</td>
    </tr>

    <tr>
      <td>`block_height`</td>
      <td>`INT64`</td>
      <td>The height of the containing block.</td>
    </tr>

    <tr>
      <td>`transaction_hash`</td>
      <td>`STRING`</td>
      <td>The hash of the emitting transaction.</td>
    </tr>

    <tr>
      <td>`event_type`</td>
      <td>`STRING`</td>
      <td>The event type.</td>
    </tr>

    <tr>
      <td>`transaction_index`</td>
      <td>`INT64`</td>
      <td>The position of the transaction within the block.</td>
    </tr>

    <tr>
      <td>`event_index`</td>
      <td>`INT64`</td>
      <td>The position of the event within the transaction.</td>
    </tr>

    <tr>
      <td>`event_attributes`</td>
      <td>`JSON`</td>
      <td>The event attributes, as key-value pairs.</td>
    </tr>
  </tbody>
</table>

**Event types**

**Rank event types by count over one week.**

```sql theme={null}
select
    event_type,
    count(*) as events
from `cosmoshub.message_events`
where block_timestamp >= timestamp('2026-08-16')
  and block_timestamp < timestamp('2026-08-23')
group by event_type
order by events desc
limit 20
```

**block\_events**

Some things happen because the chain itself does them at the start or end of a block, with no transaction behind them: paying out staking rewards, for instance. `block_events` contains one row per event of that kind, and `source` says whether it came at the beginning of the block or the end.

<table>
  <thead>
    <tr>
      <th width="280">Column</th>
      <th width="130">Type</th>
      <th>Description</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`block_timestamp`</td>
      <td>`TIMESTAMP`</td>
      <td>The time of the block. Partition column.</td>
    </tr>

    <tr>
      <td>`block_height`</td>
      <td>`INT64`</td>
      <td>The block height.</td>
    </tr>

    <tr>
      <td>`event_type`</td>
      <td>`STRING`</td>
      <td>The event type.</td>
    </tr>

    <tr>
      <td>`event_index`</td>
      <td>`INT64`</td>
      <td>The position of the event within its source.</td>
    </tr>

    <tr>
      <td>`event_attributes`</td>
      <td>`JSON`</td>
      <td>The event attributes, as key-value pairs.</td>
    </tr>

    <tr>
      <td>`source`</td>
      <td>`STRING`</td>
      <td>The emission point, begin block or end block.</td>
    </tr>
  </tbody>
</table>

**Block event types by source**

**Rank block-level event types by source, begin block or end block, over one week.**

```sql theme={null}
select
    source,
    event_type,
    count(*) as events
from `cosmoshub.block_events`
where block_timestamp >= timestamp('2026-08-16')
  and block_timestamp < timestamp('2026-08-23')
group by source, event_type
order by events desc
limit 20
```

## Exceptions

Injective runs two layers, and the catalog files them as two chains. `injective` is the Cosmos layer described here, and it is where the chain's tokens and the tokenized assets issued on it sit. Its EVM layer is a dataset of its own, `injectiveevm`, documented under [EVM](https://tokenterminal.com/docs/catalog/chain-verticals/evm/index.md); that is where the app activity sits, along with the value bridged in from other chains.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.