Commerce Flows - Dune Docs

Not every stablecoin transfer is a payment. payments.commerce_flows is a transfer-level dataset that identifies the ones that are — every transfer that is a legitimate commerce transaction, tagged with its flow type (party_pair, purpose), a confidence level, and the protocol where one is known. The table is intentionally conservative: transfers that don’t match a rule are excluded, not bucketed as “unclear”. It is not a universal stablecoin classifier and does not try to label everything. Commerce Flows feeds back into the stablecoins dataset — payments are a sub-category of stablecoin activity. Matched transfers have their category updated from unidentified to payment in stablecoins_evm.activity_enriched.

Why this dataset matters

Most stablecoin volume is not payments — it is trading, bridging, and treasury movement. Commerce Flows isolates the slice that is genuine commercial settlement, attaching an explicit rule and a confidence level to every row. It makes it possible to:

Measure onchain commerce volume by flow type (B2B, C2B, B2C) and protocol.
Separate protocol-verified settlement (Tier A) from behavioural inference (Tier B).
Label stablecoin transfers as payment-related for downstream analytics.

Coverage

Chains: EVM chains only. Protocol-verified sources (Tier A):

Crypto cards — sourced from payments.card_transactions.
Agentic payments (x402 / MPP) — sourced from payments.agentic_payments.
Stripe, Shopify Commerce Payments Protocol, Coinbase Commerce, Request Network, and stablecoin payment processors (e.g. BVNK).

Behavioural flows (Tier B): B2C payroll-style distributions, C2B merchant aggregation, and recurring B2B commerce.

Output taxonomy

Party pair	Purpose	Meaning
B2B	Commerce	Business pays business for goods or services.
C2B	Commerce	Consumer pays a merchant or service (checkout, subscriptions where detectable).
B2C	Payroll	Recurring business-to-many-individuals payouts.

Methodology

The pipeline runs in ordered stages: a strict exclusion layer removes non-commerce and non-final activity, then Tier A captures protocol-explicit matches (confidence = high), and finally Tier B applies a small set of high-signal behavioural heuristics to the residual (confidence = medium). Each transfer maps to one output row, and Tier A always takes precedence over Tier B.

1. Exclusion layer

Fires before any classification. A transfer matching any rule is dropped from the eligible universe.

Via upstream stablecoin labels: issuer mechanics (mint / burn), bridge and wrap infrastructure, CEX legs, DEX / AMM / routing, and DeFi vaults / lending / yield.
Via behavioural shape: same-entity / self-transfers, round-trip and reverse transfers (treasury reshuffling, wash patterns), A→B→C pass-through routing (avoids double-counting intermediary legs), high-frequency bot wallets, and large one-off treasury repositioning.

2. Wallet classification

Each address is typed from its full transaction history, with a wallet_balance_tier derived from its rolling 30-day average USD balance.

Wallet type	Balance tiers	Profile
Consumer	dust (under $100), micro ($ 100– $1K), small ($ 1K–$10K)	Retail-sized transfers, low counterparty diversity
Business	medium ( $10K–$ 100K)	Recurring inflows from many senders, or outflows to many receivers
Institutional	large ( $100K–$ 1M), whale (over $1M)	High-value counterparties, treasury / corporate flow shapes
Unclassified	any	Average balance under $10 or sparse history — excluded from classified output

3. B2B commerce

Tier	Detector	What it captures
A (labels)	Agentic payments	Agent-to-agent settlement (x402 / MPP), from `payments.agentic_payments`.
A (labels)	Processor deposits	Stablecoin payment-processor settlement legs (e.g. BVNK).
B (behavioural)	Recurring B2B	Business / institutional sender → receiver, ticket ≥ $2K, directional, low recurrence.

4. B2C payroll

Tier	Detector	What it captures
A (labels)	Request Network	Protocol-mediated payouts through Request payment proxies.
B (behavioural)	Payroll batch	Business-tier sender distributing to ≥5 recipients on a regular cadence, mid-size tickets, no return flow.

5. C2B commerce

Tier	Detector	What it captures
A (labels)	Crypto cards	Card purchase settlements, from `payments.card_transactions`.
A (labels)	Stripe	Stablecoin checkout settlement into the Stripe MerchantFactory contract.
A (labels)	Shopify CPP	Final settlement legs of the Shopify Commerce Payments Protocol (captures / charges only).
A (labels)	Coinbase Commerce	Final settlement into the merchant / operator.
B (behavioural)	Merchant aggregation	Merchant-like receiver aggregating many payers, then settling out to 1–2 wallets.

Table schema

Each row is one classified stablecoin transfer. Non-applicable fields are NULL. Every row carries tx_hash + transfer_evt_index + transfer_unique_key to join back to the upstream stablecoin transfer.

Column	Type	Description
`blockchain`	varchar	Chain name
`block_month`	date	Block month (partition key)
`block_date`	date	Block date
`block_time`	timestamp	Block timestamp
`tx_hash`	varbinary	Transaction hash of the classified transfer
`activity_evt_index`	bigint	Event index of the protocol anchor event for Tier A matches; `NULL` for Tier B
`transfer_evt_index`	bigint	Event index of the underlying token transfer
`transfer_unique_key`	varchar	Unique transfer identifier; merge key and join key back to upstream
`token_address`	varbinary	Token contract address
`token_symbol`	varchar	Token symbol, e.g. `USDC`, `USDT`
`amount_raw`	uint256	Raw token amount
`amount`	double	Normalized token amount
`amount_usd`	double	USD value at block time
`sender`	varbinary	Raw transfer sender
`receiver`	varbinary	Raw transfer receiver
`payment_uuid`	varchar	Identifier grouping the legs of a single payment; populated only where a multi-leg payment can be reconstructed, `NULL` otherwise
`sender_wallet_type`	varchar	`consumer`, `business`, `institutional`, or `unclassified`
`sender_wallet_balance_tier`	varchar	`dust` (under $100), `micro` ($ 100– $1K), `small` ($ 1K– $10K), `medium` ($ 10K– $100K), `large` ($ 100K– $1M), `whale` (over$ 1M)
`receiver_wallet_type`	varchar	Same vocabulary as `sender_wallet_type`
`receiver_wallet_balance_tier`	varchar	Same vocabulary as `sender_wallet_balance_tier`
`party_pair`	varchar	`b2b`, `c2b`, or `b2c`
`purpose`	varchar	`commerce` or `payroll`
`heuristic_type`	varchar	`labels_based` (Tier A) or `activity_based` (Tier B)
`heuristic_id`	varchar	Specific rule that matched, e.g. `crypto_card`, `stripe`, `shopify_cpp`, `coinbase_commerce`, `request_network`, `agentic_payments`, `b2b_processor_deposits`, `c2b_commerce_h3_aggregation`, `b2c_payroll_h1_batch`, `b2b_commerce_h_recurring`
`confidence`	varchar	`high` (Tier A) or `medium` (Tier B)
`protocol`	varchar	Protocol or provider for Tier A matches (e.g. `x402`, `stripe`, `shopify_base_cpp`, `coinbase_commerce`, `request_network`, or the card brand for crypto cards); `NULL` for Tier B
`dataset_version`	varchar	Methodology version; bumped when classification logic changes
`_updated_at`	timestamp	Pipeline load time (when the row was last written)

Sample queries

Commerce flow volume by party pair and purpose

SELECT
    party_pair,
    purpose,
    heuristic_type,
    SUM(amount_usd)        AS volume_usd,
    COUNT(*)               AS tx_count,
    COUNT(DISTINCT sender) AS unique_senders
FROM payments.commerce_flows
WHERE block_date >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2, 3
ORDER BY 4 DESC

Protocol-verified flows only

SELECT
    protocol,
    blockchain,
    SUM(amount_usd) AS volume_usd,
    COUNT(*)        AS tx_count
FROM payments.commerce_flows
WHERE confidence = 'high'
  AND block_date >= NOW() - INTERVAL '30' DAY
GROUP BY 1, 2
ORDER BY 3 DESC

payments.card_transactions — Tier A source for crypto card matches.
payments.agentic_payments — Tier A source for x402 and MPP matches.
stablecoins_evm.activity_enriched — downstream consumer; exposes category = 'payment' for matched transfers.

Documentation Index

​Why this dataset matters

​Coverage

​Output taxonomy

​Methodology

​1. Exclusion layer

​2. Wallet classification

​3. B2B commerce

​4. B2C payroll

​5. C2B commerce

​Table schema

​Sample queries

​Commerce flow volume by party pair and purpose

​Protocol-verified flows only

​Related tables