Skip to main content

​
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_transfersenriched_transfers (filter on is_adjusted_volume)
transaction_classificationorganic_activity_classification
payment_categorizationpayment_categorization
wallet_classificationwallet 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:
MetricRaw VolumeAdjusted 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

StepDescriptionTable
1. Raw Stablecoin TransfersAll chains, all stablecoins, all addressessource feeds
2. Enriched TransfersPer-transfer registry metadata, address labels, flow categories, activity taxonomy, and the is_adjusted_volume gateenriched_transfers
3. Organic Activity ClassificationWallet 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 CategorizationGranular 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 typeProfile
ConsumerRetail-sized balances and tickets, P2P-style activity
BusinessCommercial throughput — sustained volume backed by a real working balance
InstitutionalTreasury / 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):
IntentAssigned whenExamples
Investment/TradeLarge business-to-business transfers above the payment band, very high average ticket sizes, short-term round-trip (“wash”/routing) patterns, or institutional/exchange-style flowsTreasury settlement, market-making, large B2B value transfer
Store as ValueReceiver accumulates an inflow that is large relative to its balance and typical ticket size, with little subsequent outflowSavings, balance build-up
Real-World PaymentA consumer or business is involved and the amount sits within payment-sized bands below the large-ticket trade thresholdRemittance, retail purchase, payroll, supplier payment
UnclassifiedNo rule matched with sufficient confidenceAmbiguous 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 NameDescription
stablecoins.intelligence.enriched_transfersPer-transfer intelligence: registry metadata, activity classification, directional flow categories, and the is_adjusted_volume flag.
stablecoins.intelligence.organic_activity_classificationSender/receiver wallet types, balance tiers, transaction intent, and wallet-type combination.
stablecoins.intelligence.payment_categorizationCore 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;

​
Next Steps

Adjusted Volume Methodology

Learn how we calculate adjusted volume and filter non-organic activity

Table Reference

Detailed schema documentation for all pipeline tables