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

# Senders

> Every sending address behind every active-user count.

Every active-user figure in the [daily asset tables](https://tokenterminal.com/docs/catalog/assets/metrics.md) is worked out from these two tables. `facts_asset_tokens.senders` records one row for each day, each deployment and each address that sent it; `facts_asset_tokens.senders_hll` summarizes the same addresses as one sketch per day per deployment.

Counts of distinct addresses behave differently from amounts. If 100 addresses sent USDC on Monday and 100 sent it on Tuesday, the figure over the two days sits somewhere between 100 and 200, and the counts alone leave the answer open; the same holds across chains, deployments and assets. So a daily `*_active_users` column describes the day it is stamped with, and a wider figure comes from the addresses or from the sketches.

A sketch is a small summary of a set of addresses, a few kilobytes however large the set, and two sketches combine into one before anything is counted. Combine the sketches for a stretch of days, a group of chains or a basket of assets and count once, and every address counts once. The technique is called HyperLogLog++, hence the `_hll` in the table name, and a count off a sketch is an estimate that agrees with the `*_active_users` figures published in the daily tables.

## Tables

**Senders**

One row per `(timestamp, asset_token_id, sender_address)`. The addresses themselves answer questions of identity: how far two assets' users overlap, or whether the addresses that showed up in March are still active in June.

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

  <tbody>
    <tr>
      <td>`timestamp`</td>
      <td>`TIMESTAMP`</td>
      <td>Day the address sent the deployment. The partition column.</td>
    </tr>

    <tr>
      <td>`asset_token_id`</td>
      <td>`STRING`</td>
      <td>Deployment the address sent, formatted `{asset_id}-{token_address}-{chain_id}`.</td>
    </tr>

    <tr>
      <td>`asset_id`</td>
      <td>`STRING`</td>
      <td>Asset the deployment belongs to.</td>
    </tr>

    <tr>
      <td>`token_id`</td>
      <td>`STRING`</td>
      <td>Key of the deployment in `dimensions.tokens`.</td>
    </tr>

    <tr>
      <td>`chain_id`</td>
      <td>`STRING`</td>
      <td>Chain the deployment lives on.</td>
    </tr>

    <tr>
      <td>`symbol`</td>
      <td>`STRING`</td>
      <td>Ticker symbol of the asset.</td>
    </tr>

    <tr>
      <td>`asset_type`</td>
      <td>`STRING`</td>
      <td>Classification of the asset.</td>
    </tr>

    <tr>
      <td>`bridged_status`</td>
      <td>`STRING`</td>
      <td>Issuance classification of the deployment: `native`, `bridged` or `unclassified`.</td>
    </tr>

    <tr>
      <td>`token_address`</td>
      <td>`STRING`</td>
      <td>Address of the token contract.</td>
    </tr>

    <tr>
      <td>`sender_address`</td>
      <td>`STRING`</td>
      <td>Address that sent the token that day.</td>
    </tr>
  </tbody>
</table>

**Senders HLL**

One row per `(timestamp, asset_token_id)`, the sketch of that day's senders. The key columns match the address table exactly, so any filter that works there works here, over a fraction of the data.

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

  <tbody>
    <tr>
      <td>`timestamp`</td>
      <td>`TIMESTAMP`</td>
      <td>Day the sketch summarizes. The partition column.</td>
    </tr>

    <tr>
      <td>`asset_token_id`</td>
      <td>`STRING`</td>
      <td>Deployment the sketch summarizes, formatted `{asset_id}-{token_address}-{chain_id}`.</td>
    </tr>

    <tr>
      <td>`asset_id`</td>
      <td>`STRING`</td>
      <td>Asset the deployment belongs to.</td>
    </tr>

    <tr>
      <td>`token_id`</td>
      <td>`STRING`</td>
      <td>Key of the deployment in `dimensions.tokens`.</td>
    </tr>

    <tr>
      <td>`chain_id`</td>
      <td>`STRING`</td>
      <td>Chain the deployment lives on.</td>
    </tr>

    <tr>
      <td>`symbol`</td>
      <td>`STRING`</td>
      <td>Ticker symbol of the asset.</td>
    </tr>

    <tr>
      <td>`asset_type`</td>
      <td>`STRING`</td>
      <td>Classification of the asset.</td>
    </tr>

    <tr>
      <td>`bridged_status`</td>
      <td>`STRING`</td>
      <td>Issuance classification of the deployment: `native`, `bridged` or `unclassified`.</td>
    </tr>

    <tr>
      <td>`token_address`</td>
      <td>`STRING`</td>
      <td>Address of the token contract.</td>
    </tr>

    <tr>
      <td>`senders_hll`</td>
      <td>`BYTES`</td>
      <td>Compact summary of the day's sending addresses, built at precision 15. Combine these with `hll_count.merge`, which lands within a fraction of a percent of the exact count. The raw bytes mean nothing read directly.</td>
    </tr>
  </tbody>
</table>

## Sample queries

**One deployment, one day**

`count(distinct sender_address)` over the addresses is exact, and over one deployment and one day it reads a single partition. Widen either bound and it reads every row in the range.

```sql theme={null}
select
    count(distinct sender_address) as senders
from `facts_asset_tokens.senders`
where asset_token_id = 'usdc-0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48-ethereum'
  and timestamp >= timestamp('2026-08-01')
  and timestamp < timestamp('2026-08-02')
```

**Monthly active senders**

`hll_count.merge` combines the sketches first and counts once, so an address active on three chains counts as one. The answer is an estimate, taken off a fraction of the data the address table holds.

```sql theme={null}
select
    hll_count.merge(senders_hll) as monthly_active_senders
from `facts_asset_tokens.senders_hll`
where asset_id = 'usdc'
  and timestamp >= timestamp('2026-07-01')
  and timestamp < timestamp('2026-08-01')
```

**Weekly senders by chain**

Combining within each group keeps every group's count correct, at any level the group-by asks for. Summing the per-chain figures counts an address once per chain it was active on.

```sql theme={null}
select
    chain_id,
    hll_count.merge(senders_hll) as weekly_active_senders
from `facts_asset_tokens.senders_hll`
where asset_id = 'usdc'
  and timestamp >= timestamp('2026-08-01')
  and timestamp < timestamp('2026-08-08')
group by chain_id
order by weekly_active_senders desc
```


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