Payments Pipeline Overview

What is the Payments Pipeline?

The Payments Pipeline is Allium’s comprehensive framework for identifying, classifying, and analyzing real-world payments across blockchain networks. It transforms raw stablecoin transfer data into actionable insights about payment behavior, distinguishing genuine economic activity from noise. The pipeline is delivered through the stablecoins.intelligence schema as a set of per-transfer tables enriched with registry metadata, wallet typing, an organic-activity taxonomy, and granular payment categories.

Migrating from crosschain.stablecoin? The pipeline moved to the stablecoins.intelligence schema. Table mapping:

Legacy `crosschain.stablecoin.*`	New `stablecoins.intelligence.*`
`filtered_transfers`	`enriched_transfers` (filter on `is_adjusted_volume`)
`transaction_classification`	`organic_activity_classification`
`payment_categorization`	`payment_categorization`
`wallet_classification`	wallet typing is now embedded in `organic_activity_classification` (`from_wallet_type` / `to_wallet_type`, `from_balance_tier` / `to_balance_tier`)

The standalone adjusted-volume table is replaced by the is_adjusted_volume flag on enriched_transfers.

Core Concept: Adjusted Volume

Adjusted Volume represents stablecoin transaction volume after filtering out non-organic activity. This provides a more accurate measure of real economic utility by removing:

CEX (Centralized Exchange) activity - Internal exchange operations and market making
DeFi Protocol activity - Smart contract interactions, liquidity provision, and automated trading
Infrastructure activity - Bridge contracts, multisigs, and other operational addresses

In the new schema, adjusted volume is exposed as the is_adjusted_volume boolean on enriched_transfers — filter WHERE is_adjusted_volume for economically meaningful activity.

Why Adjusted Volume Matters

Raw blockchain volume includes significant noise that inflates the actual payment activity:

Metric	Raw Volume	Adjusted Volume
Includes CEX	✅ Yes	❌ No
Includes DeFi	✅ Yes	❌ No
Includes Infrastructure	✅ Yes	❌ No
Real-world payments	✅ Yes	✅ Yes
Reflects true utility	❌ No	✅ Yes

Pipeline Architecture

Step	Description	Table
1. Raw Stablecoin Transfers	All chains, all stablecoins, all addresses	source feeds
2. Enriched Transfers	Per-transfer registry metadata, address labels, flow categories, activity taxonomy, and the `is_adjusted_volume` gate	`enriched_transfers`
3. Organic Activity Classification	Wallet typing (Consumer / Business / Institutional) and transaction intent (Real-World Payment / Investment-Trade / Store-as-Value) with wallet-type combinations (C2C, C2B, B2C, B2B, …)	`organic_activity_classification`
4. Payment Categorization	Granular purpose: P2P, Retail, Payroll, B2B, etc. (Real-World Payment transfers only)	`payment_categorization`

How Organic Activity Classification Works

Once non-organic activity is filtered out (see Adjusted Volume), each remaining transfer is classified along two axes — who is transacting (wallet types) and why (transaction intent). This is the organic_activity_classification stage.

Wallet typing (who)

Every sender and receiver is assigned a wallet type from a daily behavioral profile:

Wallet type	Profile
Consumer	Retail-sized balances and tickets, P2P-style activity
Business	Commercial throughput — sustained volume backed by a real working balance
Institutional	Treasury / protocol / market-maker scale: very high volume, large or multi-token balances, multi-chain presence

Typing combines an address’s balance tier, 30-day volume, average ticket size, activity cadence, and entity labels. A key guardrail: a wallet must hold a genuine working stablecoin balance to be typed Business — high-velocity wallets that move large volume while holding near-zero balance (e.g. routing / pass-through addresses) are treated as Consumer, not Business. This prevents over-counting business-to-business volume. Sender × receiver types produce the wallet_type_combination (C2C, C2B, B2C, B2B, plus institutional pairs I2C, I2B, I2I, C2I, B2I).

Transaction intent (why)

A prioritized rule stack assigns each transfer a transaction_type (first match wins):

Intent	Assigned when	Examples
Investment/Trade	Large business-to-business transfers above the payment band, very high average ticket sizes, short-term round-trip (“wash”/routing) patterns, or institutional/exchange-style flows	Treasury settlement, market-making, large B2B value transfer
Store as Value	Receiver accumulates an inflow that is large relative to its balance and typical ticket size, with little subsequent outflow	Savings, balance build-up
Real-World Payment	A consumer or business is involved and the amount sits within payment-sized bands below the large-ticket trade threshold	Remittance, retail purchase, payroll, supplier payment
Unclassified	No rule matched with sufficient confidence	Ambiguous flows

Because Investment/Trade rules run before payment rules, large speculative and treasury flows are removed before the payment mix is computed — so payment_categorization reflects genuine real-world payments rather than large-ticket value transfer. Only transfers typed Real-World Payment flow into payment_categorization for granular purpose labeling.

Tables

The pipeline produces three primary tables in the stablecoins.intelligence schema:

Table Name	Description
`stablecoins.intelligence.enriched_transfers`	Per-transfer intelligence: registry metadata, activity classification, directional flow categories, and the `is_adjusted_volume` flag.
`stablecoins.intelligence.organic_activity_classification`	Sender/receiver wallet types, balance tiers, transaction intent, and wallet-type combination.
`stablecoins.intelligence.payment_categorization`	Core payment category and payment purpose for Real-World Payment transfers.

Access tiers. The full-history tables above are gated (available to entitled customers). Each is also published as a rolling last-30-days view that is broadly shared — start with these for evaluation and rolling analytics:

stablecoins.intelligence.enriched_transfers_last_30d

Same schema as the full table, filtered to block_timestamp >= dateadd('day', -30, current_timestamp()). Contact Allium for full-history access.

Use Cases

1. Payment Volume Analytics

Track real-world stablecoin payment adoption across chains (adjusted volume):

SELECT
  chain,
  token_symbol,
  DATE_TRUNC('week', block_timestamp) AS week,
  SUM(usd_amount) AS weekly_adjusted_volume
FROM stablecoins.intelligence.enriched_transfers
WHERE is_adjusted_volume
GROUP BY 1, 2, 3
ORDER BY 3 DESC;

2. Payment Type Distribution

Understand how stablecoins are being used:

SELECT
  transaction_type,
  COUNT(*) AS transfer_count,
  SUM(usd_amount) AS total_volume_usd
FROM stablecoins.intelligence.organic_activity_classification
GROUP BY 1;

3. Payment Purpose Breakdown

Analyze granular payment categories:

SELECT
  core_payment_category,
  payment_purpose,
  COUNT(*) AS payment_count,
  SUM(usd_amount) AS total_usd
FROM stablecoins.intelligence.payment_categorization
GROUP BY 1, 2
ORDER BY 4 DESC;

4. Wallet-Type Segmentation

Profile payment activity by counterparty type:

SELECT
  wallet_type_combination,
  COUNT(*) AS transfer_count,
  SUM(usd_amount) AS total_volume_usd
FROM stablecoins.intelligence.organic_activity_classification
WHERE transaction_type = 'Real-World Payment'
GROUP BY 1
ORDER BY 3 DESC;

Overview

Data Verticals

Solana

Hyperliquid

Lighter

Bitcoin Ecosystem

EVM

Cosmos Ecosystem

Move Ecosystem

Other Ecosystems

What is the Payments Pipeline?

Core Concept: Adjusted Volume

Why Adjusted Volume Matters

Pipeline Architecture

How Organic Activity Classification Works

Wallet typing (who)

Transaction intent (why)

Tables

Use Cases

1. Payment Volume Analytics

2. Payment Type Distribution

3. Payment Purpose Breakdown

4. Wallet-Type Segmentation

Next Steps

Adjusted Volume Methodology

Table Reference

​What is the Payments Pipeline?

​Core Concept: Adjusted Volume

​Why Adjusted Volume Matters

​Pipeline Architecture

​How Organic Activity Classification Works

​Wallet typing (who)

​Transaction intent (why)

​Tables

​Use Cases

​1. Payment Volume Analytics

​2. Payment Type Distribution

​3. Payment Purpose Breakdown

​4. Wallet-Type Segmentation

​Next Steps

Adjusted Volume Methodology

Table Reference

What is the Payments Pipeline?

Core Concept: Adjusted Volume

Why Adjusted Volume Matters

Pipeline Architecture

How Organic Activity Classification Works

Wallet typing (who)

Transaction intent (why)

Tables

Use Cases

1. Payment Volume Analytics

2. Payment Type Distribution

3. Payment Purpose Breakdown

4. Wallet-Type Segmentation

Next Steps