> ## 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.

# Other ecosystems

> Standardized tables for chains that match none of the other families.

These chains work differently enough inside that they match none of the other families, and they share nothing with each other beyond that. Each one keeps its own set of tables, documented on its own page along with the month its history starts.

## Chains

<table>
  <thead>
    <tr>
      <th width="200">Chain</th>
      <th width="180"><code>chain\_id</code></th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td><a href="/docs/catalog/chain-verticals/other/algorand">Algorand</a></td>
      <td><code>algorand</code></td>
    </tr>

    <tr>
      <td><a href="/docs/catalog/chain-verticals/other/cardano">Cardano</a></td>
      <td><code>cardano</code></td>
    </tr>

    <tr>
      <td><a href="/docs/catalog/chain-verticals/other/flow">Flow</a></td>
      <td><code>flow</code></td>
    </tr>

    <tr>
      <td><a href="/docs/catalog/chain-verticals/other/hedera">Hedera</a></td>
      <td><code>hedera</code></td>
    </tr>

    <tr>
      <td><a href="/docs/catalog/chain-verticals/other/near">NEAR</a></td>
      <td><code>near</code></td>
    </tr>

    <tr>
      <td><a href="/docs/catalog/chain-verticals/other/ripple">Ripple</a></td>
      <td><code>ripple</code></td>
    </tr>

    <tr>
      <td><a href="/docs/catalog/chain-verticals/other/starknet">Starknet</a></td>
      <td><code>starknet</code></td>
    </tr>

    <tr>
      <td><a href="/docs/catalog/chain-verticals/other/stellar">Stellar</a></td>
      <td><code>stellar</code></td>
    </tr>

    <tr>
      <td><a href="/docs/catalog/chain-verticals/other/ton">TON</a></td>
      <td><code>ton</code></td>
    </tr>

    <tr>
      <td><a href="/docs/catalog/chain-verticals/other/tron">Tron</a></td>
      <td><code>tron</code></td>
    </tr>
  </tbody>
</table>

## Conventions

Two habits hold across every chain here, whatever its tables are called.

A table with one row per transaction or per event is split by day on `block_timestamp`, and a table of blocks on `timestamp`. Filter on that column in every query: without a filter the query reads the whole table.

Identifiers reuse the familiar names wherever the chain has a matching idea: `block_number`, `transaction_hash`, and `*_index` for a position within something.