Crypto Card Statistics

What this tracker measures

SpendNode tracks card-payment activity that can be tied to a specific crypto card program with a reproducible onchain method. Depending on the program, that may be a decoded card-spend event, a merchant settlement, or an issuer settlement batch. The measurement label beside every program explains which one applies.

The headline figure is observed measured spend, not the size of the entire crypto card market. It excludes programs we cannot measure reliably and does not combine card spending with money merely loaded onto a card account.

Reading the numbers correctly

Measured card spend and top-up proxies answer different questions. Spend shows value associated with purchases or their settlement. A top-up proxy shows value moving into card infrastructure before a purchase occurs. Top-ups can be retained, withdrawn, or spent later, so adding the two would double count activity and overstate the market.

Transaction and wallet counts also depend on the settlement architecture. A program that emits one event per purchase can support purchase and active-wallet analysis. KAST, by contrast, settles through issuer batches. Its volume is measurable, but its 32 August transactions are settlement batches rather than 32 purchases, and they reveal no cardholder count.

How programs enter the dataset

A program is published only after its addresses, contracts, event logic, asset filters, date boundaries, and known exclusions are documented. Test transactions, direct chain queries, public explorers, and independent external datasets can all be used as controls. A matching number alone is not enough if the underlying flow cannot be explained.

Coverage changes are treated as methodology changes. When a new collector or chain is discovered, SpendNode either rebuilds the comparable history or withholds the growth percentage until both periods use the same basis.

How we actually build a mapping

There is no complete public registry of crypto card settlement addresses. Each program in this dataset has a documented mapping assembled from direct chain research, SpendNode queries, public explorers, or a combination of those sources. We publish the working method because other researchers should be able to inspect the same evidence and test our conclusions.

It often starts with a real purchase. We hold cards from most of the programs we track, so we can buy something, note the exact amount and timestamp, and then look for the corresponding chain activity. A single reconciled transaction is worth more than address guessing: one test purchase settled as two liquidations on different chains that summed to the receipt amount to the cent, and that single match exposed the program's settlement architecture.

From the anchor purchase we work outward. Whose contract emitted the event? Is the card debiting the user's wallet at authorization time, settling merchant batches daily, or moving issuer-level lump sums? Those are three different measurements, and the label next to each program records which one it is. Where the contract source is verified we decode it properly, including the failure flags: some card contracts emit a status bitmap per batch, and entries the contract itself marked as failed are excluded from our totals.

Programs also rotate their settlement addresses without notice, and a tracker can mistake a rotation for a collapse in volume. One recovery method is repeat-sender tracing: take wallets that verifiably used the old address and examine where those same wallets send funds later. Convergence on a new address is treated as a discovery lead, then checked against transaction structure, assets, timing, and independent controls before the new route is accepted.

Rules that keep the numbers honest

A few principles guide every program, while the exact checks depend on its settlement architecture:

• Use the strongest available transaction test. Direct decoded-contract series can require agreement between calldata, status logs, token transfers, and the expected recipient. Settlement-address and indexed-query series use their documented address, asset, direction, and exclusion rules. Ambiguous activity is left out rather than estimated.
• Reject irrelevant assets. Where arbitrary tokens can reach a tracked address, explicit asset allowlists prevent airdrop spam and spoof tokens from inflating the current closed-month result.
• Reconcile independently where possible. A mapping may be checked through raw RPC reads, another indexer, a known cardholder transaction, or an external aggregate. Disagreements are investigated and disclosed rather than averaged away.
• State the valuation method. Direct series value USD stablecoins at par, euro assets at daily ECB reference rates, and volatile assets at hourly market prices. A series that still relies on an indexed provider's valuation is labelled that way until the direct replacement is adopted.
• Do not copy vendor totals into the headline. Current values come from SpendNode's direct collectors or SpendNode-authored chain queries, including queries run through Dune where that remains the production index. Other public trackers are reconciliation controls, not calculation inputs.

Reproduce it, challenge it, improve it

We want more independent work on stablecoin payments. Public settlement rails offer a practical way to improve payment-data and stablecoin literacy, but only when measurement boundaries remain visible. If you rebuild one of our mappings and get a different result, find a settlement route we missed, or want to suggest another program, write to hello@spendnode.io. Verified corrections are applied with a dated revision note, and contributors can be credited if they wish.

Revisions and reproducibility

Blockchain data is public, but classifying it is research. Card programs rotate settlement addresses, migrate chains, add issuers, and mix payment flows with treasury transfers or account funding. We preserve those boundaries in the program methodology and revise historical figures when stronger evidence changes the correct interpretation.

The downloadable files contain the same program-week and program-month values used by this dashboard and its reports. Researchers and publishers citing the data should include the measurement label, reporting period, and access date, and should avoid describing the observed total as total market volume.