> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allium.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Metrics

> Daily metrics for crypto card programs - spend, topups, settlements and account counts.

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`:

```sql theme={null}
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.

<Warning>
  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.
</Warning>

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

<Warning>
  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.
</Warning>

Monthly active accounts and new accounts together, per program:

```sql theme={null}
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.

<Warning>
  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.
</Warning>

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

<Tabs>
  <Tab title="Program overview by month">
    Spend, topups and accounts for each program, one row per month.

    ```sql theme={null}
    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.
  </Tab>

  <Tab title="Total card spend">
    Total card spend by issuer, program and chain. Each dollar is counted once,
    so any subset of these rows sums correctly.

    ```sql theme={null}
    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.
  </Tab>
</Tabs>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

### Table Columns

<Tabs>
  <Tab title="Total spend volume">
    Table name: `payments.metrics.crypto_card_spend_volume`

    Unique 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. |
  </Tab>

  <Tab title="Program overview">
    Table name: `payments.metrics.crypto_card_programs_overview`

    Unique 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. |
  </Tab>

  <Tab title="Program overview by chain">
    Table name: `payments.metrics.crypto_card_programs_overview_by_chain`

    Unique 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. |
  </Tab>
</Tabs>