Senders

Every active-user figure in the daily asset tables 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 user_* 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 user_* figures published in the daily tables.

Tables

Senders
Senders HLL

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.

Column	Type	Description
`timestamp`	`TIMESTAMP`	Day the address sent the deployment. The partition column.
`asset_token_id`	`STRING`	Deployment the address sent, formatted `{asset_id}-{token_address}-{chain_id}`.
`asset_id`	`STRING`	Asset the deployment belongs to.
`token_id`	`STRING`	Key of the deployment in `dimensions.tokens`.
`chain_id`	`STRING`	Chain the deployment lives on.
`symbol`	`STRING`	Ticker symbol of the asset.
`asset_type`	`STRING`	Classification of the asset.
`bridged_status`	`STRING`	Issuance classification of the deployment: `native`, `bridged` or `unclassified`.
`token_address`	`STRING`	Address of the token contract.
`sender_address`	`STRING`	Address that sent the token that day.

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.

Column	Type	Description
`timestamp`	`TIMESTAMP`	Day the sketch summarizes. The partition column.
`asset_token_id`	`STRING`	Deployment the sketch summarizes, formatted `{asset_id}-{token_address}-{chain_id}`.
`asset_id`	`STRING`	Asset the deployment belongs to.
`token_id`	`STRING`	Key of the deployment in `dimensions.tokens`.
`chain_id`	`STRING`	Chain the deployment lives on.
`symbol`	`STRING`	Ticker symbol of the asset.
`asset_type`	`STRING`	Classification of the asset.
`bridged_status`	`STRING`	Issuance classification of the deployment: `native`, `bridged` or `unclassified`.
`token_address`	`STRING`	Address of the token contract.
`senders_hll`	`BYTES`	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.

Sample queries

One deployment, one day
Monthly active senders
Weekly senders by chain

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.

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')

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.

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')

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.

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

Overview

Popular datasets

Market verticals

Chain ecosystems

Core entities

Tables

Sample queries

​Tables

​Sample queries

Tables

Sample queries