Metrics - Allium Documentation Hub

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, and have their own section below.

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.

How we keep a dollar from being counted twice

The same purchase can be visible twice: once as a program’s own spend event, and again when its issuer settles up afterwards. Spend volume resolves this by choosing one source per issuer and reading every row of that issuer from it. spend_source records the choice. Wirex, UR and Bridge are read from their spend feeds, which already cover every purchase on the issuer. Gnosis Pay, MetaMask and Ready are read from the spends of their single program. Rain and Immersve are read from settlements instead, which means the spend data that Ether.fi, Exa, Plasma One and Ethena Pay produce is deliberately set aside, since those programs run on Rain and are already inside Rain’s settlements. The choice is made per issuer rather than per program on purpose. When a program changes the address it settles from, its settlements fall into other_rain while its own spend data keeps reporting the same purchases, and a per-program basis would count that volume twice. The same reasoning makes it crosschain: Ether.fi’s purchases on Scroll were settled through Rain on Optimism and later Ethereum. Publicly available reports can fall into this trap by adding a program’s own spend events to its issuer’s settlements. The Allium datasets pick one source per issuer, so the same purchase is never counted twice.

Counting accounts

Two things make account counts different from everything else here. The first is that a distinct count cannot be summed. The same cardholder active on Monday and Tuesday is one person, so adding daily counts over a month double-counts them. Each account column therefore carries companions that can be summed, and which one you want depends on the question:

_new_to_month and _new_to_week count a cardholder on their first active day inside that calendar month or week. Summed over the matching period, they give that period’s distinct count, which is monthly active accounts rather than new ones. Pair them only with a date_trunc of the same width.
_new_to_lifetime counts a cardholder on the first active day in their entire history. Summed over any range, it gives the accounts that showed up for the first time in that range, which is the new ones.

The second is that the by-chain table counts accounts per chain. A cardholder who exists on several chains under the same address is counted once on each, so summing across chains overcounts: roughly 2.11M all-time active accounts against a true 1.98M. An Ether.fi cardholder deployed on both Scroll and Optimism is the usual case, and a RedotPay deposit wallet can appear on many EVM chains at once. Cardholders can also appear more than once across kinds of chain. If someone uses a card on an EVM chain and on Solana or Tron, and we have nothing that links the addresses, we cannot tell they are one person, so they show up as one account on each. Account counts are therefore best read as accounts we can identify, which can run slightly above the number of people.

Use the by-chain table to see how a program’s volume is spread, and the crosschain crypto_card_programs_overview for any account figure. It deduplicates cardholders who share an address across chains. The _new_to_* companions are per chain in the by-chain table and overcount in the same way.

Monthly active accounts and new accounts together, per program:

select
  date_trunc('month', date) as month,
  card_program,
  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;

Keep the grouping on card_program. Adding accounts across programs counts a cardholder once per program they use.

Reading the columns

The columns with _event_ in their name are the raw per-event numbers underneath the headline series. They are useful for drilling into one program, and they sit together at the end of the table.

Do not add an _event_ column to a headline column. For a program that has both kinds of event the same money appears in each, so spend_event_amount_usd + settlement_event_amount_usd double-counts it. Use spend_amount_usd, and topup_amount_usd for the funding equivalent.

The exception is issuer_network_settlement_event_*, which is the issuer paying the card network. That happens downstream of the purchase and is never a spend_source, so it stands on its own. A null count means the metric is not measured for that program, so a zero is always a real zero. spend_count is where this shows up most: it is null wherever one row is not reliably one purchase, which covers programs that settle in treasury batches, programs whose senders are not fully mapped, and programs whose rows can each cover several authorizations. The matching spend_amount_usd stays exact in all of those cases.

Data caveats

A few things worth knowing before reading too much into a number. Settlements arrive in batches. A single settlement row can cover many cardholders and many purchases at once, so a settlement count is a count of settlements rather than of purchases. Coverage follows the issuers we support. A card program can run part of its business through an issuer we do not track, and that part stays invisible here. The issuers column lists every issuer we have seen for a program, which is the best guide to what a program’s row actually covers. Account counts can sit above the number of people. Cardholders are matched by their on-chain address, so someone who appears on an EVM chain and on Solana or Tron counts once on each. This shows up most in the topup series for programs built on deposit addresses, such as RedotPay, Kast and Takenos, where each cardholder is handed a separate address per chain. Read unique_topup_accounts as an upper bound on people. Small topups are dropped. Deposit addresses attract spam and address-poisoning transfers, so a topup counts only from $0.01 upwards, and transfers we cannot price are left out. Only the on-chain side is here. These tables describe what card programs put on a blockchain. Whatever a program handles internally stays off the record, so the figures here describe on-chain activity rather than the whole business. Some chains are missing from programs we otherwise cover. The gaps we know about today are MetaMask spend on Solana, RedotPay topups on Bitcoin and XRP, and Kast topups on Stellar and XRP. Those three series read below the programs’ real activity until the chains are added.

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.

​Terminology

​Why every program looks different on-chain

​The metrics

​The tables

​Which table to reach for

​How we keep a dollar from being counted twice

​Counting accounts

​Reading the columns

​Data caveats

​Example queries

​Frequently asked questions

​Table Columns

Terminology

Why every program looks different on-chain

The metrics

The tables

Which table to reach for

How we keep a dollar from being counted twice

Counting accounts

Reading the columns

Data caveats

Example queries

Frequently asked questions

Table Columns