Metrics

A crypto card is a payment card that can be funded with crypto. The cardholder pays at a shop the usual way, with a Visa or Mastercard, and the money behind the payment comes from stablecoins or other tokens instead of a bank balance. There are two common designs. In a self-custodial card, the cardholder’s tokens stay in an account they control, and the card program draws on that balance when a payment is made. In a custodial card, the cardholder tops up a balance held by the program or its partner, and the card spends from that. Both are in these tables. The payment itself is approved off-chain on the normal card networks, so no blockchain shows the purchase. What does leave a trail on-chain is the money around it: the cardholder funding the card, the program recording or collecting a spend, and the program paying back its issuer afterwards. Allium indexes those events and turns them into daily metrics for every card program we track.

Terminology

Term	Meaning
Card program	The branded product a cardholder sees, such as Ether.fi or Gnosis Pay.
Issuer	The company that provides the card rails behind one or more programs, such as Rain or Wirex.
Spend	A card purchase.
Topup	Money added to the card so it can be spent.
Settlement	The program paying its issuer for the purchases made, usually in batches.
Account	A cardholder, identified by the account address or account ID we resolved for them.

Programs we cannot name individually are grouped under other_<issuer>, for example other_rain, so their volume is still counted.

Why every program looks different on-chain

There is no shared standard for how a card program operates on-chain, and the differences affect the numbers. Some programs deploy a contract for each cardholder and emit an event for every purchase. Others keep their ledger internal and only touch a chain when they settle up with their issuer, often once a day. Some report a topup when money reaches the cardholder’s account, others once the balance becomes spendable, and a few report both for the same money. Adding up whatever each program emits would produce figures that cannot be compared. A program that reports two topup steps would look twice the size of one that reports one. A program that settles in batches would show 850 purchases behind $833M of spend. A cardholder who exists on four chains would be counted as four customers. Allium reconciles this activity program by program. We study how each program works on-chain, pick the events that represent a purchase and a topup for that particular design, and publish them as curated metrics on a common definition. The result is a set of figures that hold up on their own and can be compared, summed and charted across programs and issuers. The raw per-event numbers stay available underneath for drilling in, and the curated columns are the ones to build on.

The metrics

Metric	What it tells you	Main columns
Spend	How much was spent on cards, in USD, and in how many purchases	`spend_amount_usd`, `spend_count`
Topups	How much money was added to cards	`topup_amount_usd`, `topup_count`
Settlements	How much the programs paid their issuers	`settlement_event_*` columns
Accounts	How many cardholders were active, and how many are new	`unique_active_accounts` and its companions

The tables

Table	One row per	Use it for
`crypto_card_spend_volume`	date, chain, issuer, card_program	Total card spend, and spend per issuer
`crypto_card_programs_overview`	date, card_program	Spend, topups and accounts for a named program
`crypto_card_programs_overview_by_chain`	date, chain, card_program	The same program metrics, split by chain

Every table has one row per day. Amounts and counts add up across rows, so a weekly or monthly view is a date_trunc and a group by:

select
  date_trunc('month', date) as month,
  sum(spend_amount_usd) as spend_usd
from payments.metrics.crypto_card_spend_volume
group by 1
order by 1 desc;

Account counts need more care: they are not additive across days or chains. The methodology covers how to roll them up.

Which table to reach for

crypto_card_spend_volume is the source of truth for total card spend. It counts each dollar once and includes the volume that no named program claims, which is what makes it a total. Reach for it when you are sizing the market, splitting spend by issuer, or comparing crypto card spend against something external. crypto_card_programs_overview covers named programs only. It is where the purchase counts, account counts and funding metrics live, so it is the right table for any question about a particular program.

Summing crypto_card_programs_overview gives named-program volume, not total card spend. The two tables are not meant to reconcile. The gap between them is the unattributed other_* volume, plus programs that run on two issuers and so appear once per issuer in spend volume and once in total in the overview.Ether.fi shows the difference well. The program tables report its own spend events, because they carry the purchase counts and active accounts. The spend volume table reports what Rain actually settled for Ether.fi. These are two different series, built for different questions, and their totals are expected to differ.

Methodology

Example queries

Program overview by month
Total card spend

Spend, topups and accounts for each program, one row per month.

select
  date_trunc('month', date) as month,
  card_program,
  sum(spend_amount_usd) as spend_usd,
  sum(spend_count) as purchases,
  sum(topup_amount_usd) as topup_usd,
  sum(topup_count) as topups,
  sum(unique_active_accounts_new_to_month) as monthly_active_accounts,
  sum(unique_active_accounts_new_to_lifetime) as new_accounts
from payments.metrics.crypto_card_programs_overview
where date >= dateadd('month', -6, current_date())
group by 1, 2
order by 1 desc, 3 desc;

A null count means the metric is not measured for that program. Programs with no topup or purchase coverage show nulls in those columns.

Total card spend by issuer, program and chain. Each dollar is counted once, so any subset of these rows sums correctly.

select
  issuer,
  card_program,
  chain,
  sum(spend_amount_usd) as spend_usd
from payments.metrics.crypto_card_spend_volume
where date >= dateadd('month', -1, current_date())
group by 1, 2, 3
order by 4 desc;

Drop card_program and chain from the grouping for spend per issuer.

Frequently asked questions

How much of the crypto card market do these tables cover?

We track more than 50 named card programs, the widest coverage we are aware of, plus the issuer volume we have not yet tied to a named program, which is reported under other_<issuer> rather than dropped. What is missing falls into two groups.Issuers we have not added yet. We index a growing list of issuers and add more over time, so at any moment there are programs whose rails we do not read — Reap and StraitsX are two examples. A program that runs only on an issuer we have not added does not reach these tables at all.Cards run by centralized exchanges, such as Crypto.com, Binance, OKX and Bybit. A purchase on these can draw on a spot balance held on the exchange’s own ledger, so nothing about it touches a blockchain and there is no on-chain trail for us to index. We expect the volume is substantial, but we have no way today to put a figure on how much of the market it represents.

Why is total spend volume lower than figures published elsewhere?

Our aim is to report what cardholders actually spent, which usually puts us below headline numbers built from raw on-chain activity. Every figure in these tables traces back to on-chain activity that anyone can audit, so we also leave out figures that programs report about themselves. Three examples of where the difference comes from:RedotPay. Public reports usually quote around $6.6B of RedotPay spend, which would be more than half of all the card spend we can track on-chain. Those figures come from the company and cannot be verified on-chain, so RedotPay spend stays out of our metrics.Wirex. We count card spends only. Reports built on raw activity also count outgoing bank transfers from Wirex accounts, which are not card purchases, and count Wirex settling with Visa on Stellar. That Stellar leg is the same money as the purchases it pays for, so counting both reports it twice.Ether.fi. We take Ether.fi’s volume from the settlements Rain makes on its behalf, which are net of refunds. Most published figures come from Ether.fi’s own on-chain spend events, which still include purchases that were later refunded. We cannot tell which individual Ether.fi spend events were refunded, so we rely on settlements for the headline number. The gross spend-event figure is still available in the per-program tables as spend_event_amount_usd if you want to compare against those reports.

Why is volume on the UR programs (SafePal, Bitget Wallet, imToken) falling?

These cards run on Fiat24, the Swiss institution behind the ur issuer in these tables. On 14 July 2026 Fiat24 paused crypto deposits and new user registrations while it upgrades its risk and compliance controls, and it has not announced when they resume.The tables show that cleanly. The last on-chain topup for all three programs lands on 2026-07-14, new accounts drop to roughly zero from August, and spend carries on as cardholders draw down balances they had already funded. SafePal and Bitget Wallet each ran about $4M to $5M of topups a month through the first half of 2026, then nothing. Spend has been decaying since, from around $4M a month to a few hundred thousand.Our coverage of these programs is unchanged over this period, so the decline reflects real activity on the cards.

Table Columns

Total spend volume
Program overview
Program overview by chain

Table name: payments.metrics.crypto_card_spend_volumeUnique key: unique_id

Column Name	Data Type	Description
date	DATE	Day the spend happened, UTC. The only time grain, and `spend_amount_usd` is additive, so a weekly or monthly figure is a `SUM` grouped on `date_trunc('<period>', date)`. Today is excluded until it is complete.
chain	VARCHAR	Blockchain this row’s activity happened on (`ethereum`, `base`, `avalanche`, `solana`, …).
issuer	VARCHAR	Card-rails issuer this row’s volume is read from (`rain`, `wirex`, `ur`, `immersve`, `bridge`, `gnosis_pay`, `baanx`, `kulipa`). A grain column here: a program on two issuers has one row per issuer and the two never overlap. RedotPay has no row — it exposes topups only.
card_program	VARCHAR	Branded program (`coca`, `gnosis_pay`, `phantom_cash`, …), or the issuer catch-all (`other_rain`, `other_wirex`, …) for cardholder volume not yet tied to a named program.
spend_source	VARCHAR	Which hop the issuer’s volume is read from: `spend` for issuers with a spend feed, `program_issuer_settlement` for those read from settlements. Chosen once per issuer and applied across every chain and day.
spend_amount_usd	FLOAT	Card spend in USD. Each dollar appears on exactly one row, so any subset of rows sums correctly. Unpriced rows contribute nothing, so this is a floor. On a settlement-based issuer it is settled volume, a few percent below gross and sometimes landing a day late.
unique_id	VARCHAR	Allium’s deterministic row identifier. Stable across full refreshes.
_created_at	TIMESTAMP_NTZ(9)	When the row was first written to Allium.
_updated_at	TIMESTAMP_NTZ(9)	When the row was last updated, for example by USD price hydration.

Table name: payments.metrics.crypto_card_programs_overviewUnique key: unique_id

Column Name	Data Type	Description
date	DATE	Day the activity happened, UTC. The only grain — for a weekly or monthly figure, group on `date_trunc('<period>', date)`, summing the additive columns and the matching `_new_to_week` / `_new_to_month` / `_new_to_lifetime` companion for account counts. Weeks start on Monday.
card_program	VARCHAR	Branded program (`coca`, `gnosis_pay`, `phantom_cash`, …), or the issuer catch-all (`other_rain`, `other_wirex`, …) for cardholder volume not yet tied to a named program.
spend_source	VARCHAR	Which hop stands in for a purchase on this program: `spend` where the program has a spend feed, `program_issuer_settlement` where a settlement is its only on-chain purchase signal. Null when it has neither. Use `spend_amount_usd` and `spend_count` rather than adding the `_event_` columns together.
spend_amount_usd	FLOAT	Card spend in USD, taken from the hop named by `spend_source` so no dollar is counted twice. Unpriced rows contribute nothing, so this is a floor. Populated even where `spend_count` is null.
spend_count	NUMBER	Number of purchases. Null means purchases cannot be counted here, not that there were none. It is withheld wherever one row is not reliably one purchase: settlements batched from a treasury, senders we have not mapped, and feeds whose rows can each cover several authorizations. `spend_amount_usd` is exact in all those cases. For the underlying row count use `program_issuer_settlement_event_count`.
topup_source	VARCHAR	Which hop stands in for funding: `card_balance_topup` where the program credits a spendable balance, otherwise `account_topup`. Only one is counted, so money passing through both is not double-counted. Null is a coverage gap, not a zero.
topup_amount_usd	FLOAT	Money added to cards in USD, from the hop named by `topup_source`. Transfers under $0.01 and transfers we cannot price are excluded.
topup_count	NUMBER	Number of topups on the hop named by `topup_source`, with the same exclusions as the amount.
issuers	ARRAY	Every issuer ever seen for this program — all-time metadata, not a per-day value. Issuer is deliberately not a grain column, since a program can run through several. Empty where no issuer is visible on-chain, as on RedotPay.
chains	ARRAY	Every chain this program has been seen on — all-time metadata. Crosschain table only.
unique_active_accounts	NUMBER	Distinct cardholders who spent or funded on this day. An account that does both is counted once. Not additive across days — sum `unique_active_accounts_new_to_week`, `_new_to_month` or `_new_to_lifetime` to roll up to a period. Null where no cardholder can be resolved.
unique_active_accounts_new_to_week	NUMBER	Active accounts counted on their first active day of the calendar week. Sum it over a `date_trunc('week', date)` group for that week’s distinct active accounts.
unique_active_accounts_new_to_month	NUMBER	Active accounts counted on their first active day of the calendar month. Sum it over a `date_trunc('month', date)` group for that month’s distinct active accounts.
unique_active_accounts_new_to_lifetime	NUMBER	Active accounts counted on the first active day in their whole history — genuinely new accounts. Sum it over any range for the accounts that first appeared in that range, or over the whole table for the program’s all-time distinct active accounts.
unique_spending_accounts	NUMBER	Distinct cardholders who spent on this day. Treasuries and pooled settlement addresses are not cardholders, so they add volume but no account. Null where no cardholder can be resolved — the volume is still in `spend_amount_usd`. Not additive; sum the `_new_to_*` companions instead.
unique_spending_accounts_new_to_week	NUMBER	Spending accounts counted on their first spending day of the calendar week. Sum it over a `date_trunc('week', date)` group for that week’s distinct spenders.
unique_spending_accounts_new_to_month	NUMBER	Spending accounts counted on their first spending day of the calendar month. Sum it over a `date_trunc('month', date)` group for that month’s distinct spenders.
unique_spending_accounts_new_to_lifetime	NUMBER	Spending accounts counted on the first spending day in their whole history — genuinely new spenders. Tracks `accounts_created_first_spend` closely without matching it row for row.
unique_topup_accounts	NUMBER	Distinct cardholders who funded a card on this day. Null where the program has no funding hop, or none that resolves to a cardholder. Not additive; sum the `_new_to_*` companions instead.
unique_topup_accounts_new_to_week	NUMBER	Funded accounts counted on their first funding day of the calendar week. Sum it over a `date_trunc('week', date)` group for that week’s distinct funded accounts.
unique_topup_accounts_new_to_month	NUMBER	Funded accounts counted on their first funding day of the calendar month. Sum it over a `date_trunc('month', date)` group for that month’s distinct funded accounts.
unique_topup_accounts_new_to_lifetime	NUMBER	Funded accounts counted on the first funding day in their whole history — genuinely new funded accounts. Tracks `accounts_created_first_topup` closely without matching it row for row.
accounts_created_first_spend_or_topup	NUMBER	Accounts whose first spend or first topup, whichever came earlier, falls on this day — the headline new-customer series. Not the sum of the two columns below: an account that funds and spends the same day appears once here and once in each of those.
accounts_created_first_spend	NUMBER	Accounts whose first spend falls on this day. Measured on first activity rather than on-chain deployment, which for most programs is a batch pre-deploy rather than a customer arriving.
accounts_created_first_topup	NUMBER	Accounts whose first funding falls on this day. Dust is excluded, so a tiny transfer to a precomputed address cannot claim the slot.
transaction_count	NUMBER	All spend, settlement and topup rows on this day — the program’s overall row count across the three hop families.
spend_event_amount_usd	FLOAT	Raw card spend rows in USD. Unpriced rows contribute nothing, so this is a floor.
spend_event_count	NUMBER	Raw card spend rows. For the comparable series across programs use `spend_count`.
settlement_event_amount_usd	FLOAT	All settlement rows in USD, both kinds. Unpriced rows contribute nothing, so this is a floor.
settlement_event_count	NUMBER	All settlement rows, both kinds — the two splits below summed.
program_issuer_settlement_event_amount_usd	FLOAT	Settlements where the program paid its issuer, in USD. Unpriced rows contribute nothing, so this is a floor.
program_issuer_settlement_event_count	NUMBER	Settlements where the program paid its issuer. This is the hop behind `spend_source = program_issuer_settlement`.
issuer_network_settlement_event_amount_usd	FLOAT	Settlements where the issuer paid the card network, in USD. Its own series, never part of `spend_amount_usd` — it sits one hop downstream of the purchase. Wirex on Stellar is the only material source today (~$406M all-time) and carries no program attribution, so it all lands on `other_wirex` rather than splitting across Wirex’s programs.
issuer_network_settlement_event_count	NUMBER	Settlements where the issuer paid the card network. Never a purchase proxy, so it is excluded from `spend_source`.
card_balance_topup_event_amount_usd	FLOAT	Card balance topups in USD — credits that made funds spendable. Excludes transfers under $0.01 and transfers we cannot price.
card_balance_topup_event_count	NUMBER	Card balance topup rows, with the same exclusions as the amount.
account_topup_event_amount_usd	FLOAT	Account topups in USD — funds arriving at the upstream account, before or without a card-ledger credit. Excludes transfers under $0.01 and transfers we cannot price.
account_topup_event_count	NUMBER	Account topup rows, with the same exclusions as the amount.
topup_event_count	NUMBER	All topup rows, card balance and account topups combined.
unique_id	VARCHAR	Allium’s deterministic row identifier. Stable across full refreshes.
_created_at	TIMESTAMP_NTZ(9)	When the row was first written to Allium.
_updated_at	TIMESTAMP_NTZ(9)	When the row was last updated, for example by USD price hydration.

Table name: payments.metrics.crypto_card_programs_overview_by_chainUnique key: unique_id

Column Name	Data Type	Description
date	DATE	Day the activity happened, UTC. The only grain — for a weekly or monthly figure, group on `date_trunc('<period>', date)`, summing the additive columns and the matching `_new_to_week` / `_new_to_month` / `_new_to_lifetime` companion for account counts. Weeks start on Monday.
chain	VARCHAR	Blockchain this row’s activity happened on (`ethereum`, `base`, `avalanche`, `solana`, …).
card_program	VARCHAR	Branded program (`coca`, `gnosis_pay`, `phantom_cash`, …), or the issuer catch-all (`other_rain`, `other_wirex`, …) for cardholder volume not yet tied to a named program.
spend_source	VARCHAR	Which hop stands in for a purchase on this program: `spend` where the program has a spend feed, `program_issuer_settlement` where a settlement is its only on-chain purchase signal. Null when it has neither. Use `spend_amount_usd` and `spend_count` rather than adding the `_event_` columns together.
spend_amount_usd	FLOAT	Card spend in USD, taken from the hop named by `spend_source` so no dollar is counted twice. Unpriced rows contribute nothing, so this is a floor. Populated even where `spend_count` is null.
spend_count	NUMBER	Number of purchases. Null means purchases cannot be counted here, not that there were none. It is withheld wherever one row is not reliably one purchase: settlements batched from a treasury, senders we have not mapped, and feeds whose rows can each cover several authorizations. `spend_amount_usd` is exact in all those cases. For the underlying row count use `program_issuer_settlement_event_count`.
topup_source	VARCHAR	Which hop stands in for funding: `card_balance_topup` where the program credits a spendable balance, otherwise `account_topup`. Only one is counted, so money passing through both is not double-counted. Null is a coverage gap, not a zero.
topup_amount_usd	FLOAT	Money added to cards in USD, from the hop named by `topup_source`. Transfers under $0.01 and transfers we cannot price are excluded.
topup_count	NUMBER	Number of topups on the hop named by `topup_source`, with the same exclusions as the amount.
issuers	ARRAY	Every issuer ever seen for this program — all-time metadata, not a per-day value. Issuer is deliberately not a grain column, since a program can run through several. Empty where no issuer is visible on-chain, as on RedotPay.
unique_active_accounts	NUMBER	Distinct cardholders who spent or funded on this day. An account that does both is counted once. Not additive across days — sum `unique_active_accounts_new_to_week`, `_new_to_month` or `_new_to_lifetime` to roll up to a period. Null where no cardholder can be resolved.
unique_active_accounts_new_to_week	NUMBER	Active accounts counted on their first active day of the calendar week. Sum it over a `date_trunc('week', date)` group for that week’s distinct active accounts.
unique_active_accounts_new_to_month	NUMBER	Active accounts counted on their first active day of the calendar month. Sum it over a `date_trunc('month', date)` group for that month’s distinct active accounts.
unique_active_accounts_new_to_lifetime	NUMBER	Active accounts counted on the first active day in their whole history — genuinely new accounts. Sum it over any range for the accounts that first appeared in that range, or over the whole table for the program’s all-time distinct active accounts.
unique_spending_accounts	NUMBER	Distinct cardholders who spent on this day. Treasuries and pooled settlement addresses are not cardholders, so they add volume but no account. Null where no cardholder can be resolved — the volume is still in `spend_amount_usd`. Not additive; sum the `_new_to_*` companions instead.
unique_spending_accounts_new_to_week	NUMBER	Spending accounts counted on their first spending day of the calendar week. Sum it over a `date_trunc('week', date)` group for that week’s distinct spenders.
unique_spending_accounts_new_to_month	NUMBER	Spending accounts counted on their first spending day of the calendar month. Sum it over a `date_trunc('month', date)` group for that month’s distinct spenders.
unique_spending_accounts_new_to_lifetime	NUMBER	Spending accounts counted on the first spending day in their whole history — genuinely new spenders. Tracks `accounts_created_first_spend` closely without matching it row for row.
unique_topup_accounts	NUMBER	Distinct cardholders who funded a card on this day. Null where the program has no funding hop, or none that resolves to a cardholder. Not additive; sum the `_new_to_*` companions instead.
unique_topup_accounts_new_to_week	NUMBER	Funded accounts counted on their first funding day of the calendar week. Sum it over a `date_trunc('week', date)` group for that week’s distinct funded accounts.
unique_topup_accounts_new_to_month	NUMBER	Funded accounts counted on their first funding day of the calendar month. Sum it over a `date_trunc('month', date)` group for that month’s distinct funded accounts.
unique_topup_accounts_new_to_lifetime	NUMBER	Funded accounts counted on the first funding day in their whole history — genuinely new funded accounts. Tracks `accounts_created_first_topup` closely without matching it row for row.
accounts_created_first_spend_or_topup	NUMBER	Accounts whose first spend or first topup, whichever came earlier, falls on this day — the headline new-customer series. Not the sum of the two columns below: an account that funds and spends the same day appears once here and once in each of those.
accounts_created_first_spend	NUMBER	Accounts whose first spend falls on this day. Measured on first activity rather than on-chain deployment, which for most programs is a batch pre-deploy rather than a customer arriving.
accounts_created_first_topup	NUMBER	Accounts whose first funding falls on this day. Dust is excluded, so a tiny transfer to a precomputed address cannot claim the slot.
transaction_count	NUMBER	All spend, settlement and topup rows on this day — the program’s overall row count across the three hop families.
spend_event_amount_usd	FLOAT	Raw card spend rows in USD. Unpriced rows contribute nothing, so this is a floor.
spend_event_count	NUMBER	Raw card spend rows. For the comparable series across programs use `spend_count`.
settlement_event_amount_usd	FLOAT	All settlement rows in USD, both kinds. Unpriced rows contribute nothing, so this is a floor.
settlement_event_count	NUMBER	All settlement rows, both kinds — the two splits below summed.
program_issuer_settlement_event_amount_usd	FLOAT	Settlements where the program paid its issuer, in USD. Unpriced rows contribute nothing, so this is a floor.
program_issuer_settlement_event_count	NUMBER	Settlements where the program paid its issuer. This is the hop behind `spend_source = program_issuer_settlement`.
issuer_network_settlement_event_amount_usd	FLOAT	Settlements where the issuer paid the card network, in USD. Its own series, never part of `spend_amount_usd` — it sits one hop downstream of the purchase. Wirex on Stellar is the only material source today (~$406M all-time) and carries no program attribution, so it all lands on `other_wirex` rather than splitting across Wirex’s programs.
issuer_network_settlement_event_count	NUMBER	Settlements where the issuer paid the card network. Never a purchase proxy, so it is excluded from `spend_source`.
card_balance_topup_event_amount_usd	FLOAT	Card balance topups in USD — credits that made funds spendable. Excludes transfers under $0.01 and transfers we cannot price.
card_balance_topup_event_count	NUMBER	Card balance topup rows, with the same exclusions as the amount.
account_topup_event_amount_usd	FLOAT	Account topups in USD — funds arriving at the upstream account, before or without a card-ledger credit. Excludes transfers under $0.01 and transfers we cannot price.
account_topup_event_count	NUMBER	Account topup rows, with the same exclusions as the amount.
topup_event_count	NUMBER	All topup rows, card balance and account topups combined.
unique_id	VARCHAR	Allium’s deterministic row identifier. Stable across full refreshes.
_created_at	TIMESTAMP_NTZ(9)	When the row was first written to Allium.
_updated_at	TIMESTAMP_NTZ(9)	When the row was last updated, for example by USD price hydration.

Overview

Data Verticals

Solana

Hyperliquid

Lighter

Bitcoin Ecosystem

EVM

Cosmos Ecosystem

Move Ecosystem

Other Ecosystems

Skeleton group placeholder 4

Terminology

Why every program looks different on-chain

The metrics

The tables

Which table to reach for

Methodology

Example queries

Frequently asked questions

Table Columns

Overview

Data Verticals

Solana

Hyperliquid

Lighter

Bitcoin Ecosystem

EVM

Cosmos Ecosystem

Move Ecosystem

Other Ecosystems

Skeleton group placeholder 4

​Terminology

​Why every program looks different on-chain

​The metrics

​The tables

​Which table to reach for

​Methodology

​Example queries

​Frequently asked questions

​Table Columns

Terminology

Why every program looks different on-chain

The metrics

The tables

Which table to reach for

Methodology

Example queries

Frequently asked questions

Table Columns