> ## 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.
# Payment Pipeline Tables
> Schema reference for stablecoin payment classification tables
## Table Overview
All tables are located in the **`stablecoins.intelligence`** schema. Each table is per-transfer grain and cross-chain.
| Table | Purpose | Row Grain |
| ------------------------------------- | ------------------------------------------------ | ------------------------------ |
| **enriched\_transfers** | Per-transfer intelligence + adjusted-volume flag | One row per transfer leg |
| **organic\_activity\_classification** | Wallet typing + transaction intent | One row per organic transfer |
| **payment\_categorization** | Granular payment purpose | One row per real-world payment |
**Access tiers.** The full-history tables are **gated** (entitled customers). Each is also published as a rolling **last-30-days** view that is broadly shared, identical schema, filtered to `block_timestamp >= dateadd('day', -30, current_timestamp())`:
* `stablecoins.intelligence.enriched_transfers_last_30d`
Use the `*_last_30d` view for evaluation and rolling analytics; contact Allium for full-history access.
***
## 1. enriched\_transfers
**Purpose:** Cross-chain stablecoin transfers enriched with registry metadata, an activity taxonomy, directional flow categories, and the adjusted-volume gate.
**Use Case:** Adjusted payment volume, organic-vs-noise analysis, flow analysis by counterparty sector.
### Schema
| Column Name | Data Type | Description |
| --------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `chain` | VARCHAR | Blockchain network (ethereum, solana, tron, …) |
| `unique_id` | VARCHAR | Chain-scoped surrogate key for the transfer leg |
| `transaction_hash` | VARCHAR | On-chain transaction identifier |
| `block_timestamp` | TIMESTAMP | UTC timestamp of the transfer |
| `activity_date` | DATE | `block_timestamp` truncated to day (UTC) |
| `block_number` | NUMBER | Chain-native block index |
| `from_address` / `to_address` | VARCHAR | Sender / recipient |
| `token_address` | VARCHAR | On-chain token identifier (registry join key) |
| `token_symbol` | VARCHAR | Display ticker (USDC, USDT, …) |
| `product_id` / `product_name` / `product_symbol` | VARCHAR | Canonical registry product identity |
| `issuer_id` | VARCHAR | Issuing entity (circle, tether, …) |
| `stablecoin_type` | VARCHAR | native / bridged / yield\_bearing / lending\_receipt / vault\_share / unclassified |
| `currency` | VARCHAR | Peg currency (usd, eur, …) |
| `amount` | NUMBER | Decimal-normalized token quantity |
| `usd_amount` | NUMBER | USD notional at transfer time |
| `classification` | VARCHAR | Activity bucket: dust, mint\_burn, infra\_automation, cex\_flow, defi, short\_term\_pair, gambling, payments, store\_of\_value, investment\_trade, organic\_activity, unclassified |
| `subcategory` | VARCHAR | Finer label within `classification` |
| `classification_source` | VARCHAR | Which rule family won the priority stack |
| `sender_classification` / `receiver_classification` | VARCHAR | Primary label category for each side (`unlabeled` if none) |
| `from_primary_category` / `to_primary_category` | VARCHAR | Raw label vertical (exchange, decentralized\_finance, …) |
| `cex_flow_category` | VARCHAR | Directional CEX flow tag |
| `defi_flow_category` | VARCHAR | Directional DeFi flow tag |
| `payment_services_flow_category` | VARCHAR | Directional payment-processor flow tag |
| `infrastructure_flow_category` | VARCHAR | Directional infrastructure flow tag |
| `is_adjusted_volume` | BOOLEAN | **Passes Visa-methodology organic-volume filters.** Primary gate for "economically meaningful" activity |
| `is_inorganic_sender` / `is_inorganic_receiver` | BOOLEAN | Flagged automated/test/bot wallet on each side |
| `is_mev_transfer` | BOOLEAN | Either party matches MEV/searcher heuristics |
| `is_short_term_routing` | BOOLEAN | Outbound leg of a short-term round-trip pattern |
### Example Queries
#### Total Adjusted Volume by Chain (30d)
```sql theme={null}
SELECT
chain,
SUM(usd_amount) AS adjusted_volume_30d
FROM stablecoins.intelligence.enriched_transfers_last_30d
WHERE is_adjusted_volume
GROUP BY 1
ORDER BY 2 DESC;
```
#### Top Stablecoins by Organic Volume
```sql theme={null}
SELECT
token_symbol,
COUNT(*) AS transfer_count,
SUM(usd_amount) AS total_volume
FROM stablecoins.intelligence.enriched_transfers
WHERE is_adjusted_volume
AND block_timestamp >= CURRENT_DATE - 30
GROUP BY 1
ORDER BY 3 DESC;
```
***
## 2. organic\_activity\_classification
**Purpose:** Assigns each organic transfer a sender/receiver wallet type, balance tier, and high-level transaction intent.
**Use Case:** Who is transacting (consumer vs business vs institutional) and why (payments vs trading vs savings).
### Schema
| Column Name | Data Type | Description |
| --------------------------------------------- | --------- | --------------------------------------------------------------------- |
| `chain` | VARCHAR | Blockchain network |
| `transaction_hash` | VARCHAR | On-chain transaction identifier |
| `token_symbol` / `token_address` | VARCHAR | Stablecoin moved |
| `activity_date` | DATE | UTC date of the transfer |
| `block_timestamp` | TIMESTAMP | UTC timestamp |
| `from_address` / `to_address` | VARCHAR | Sender / recipient |
| `usd_amount` | NUMBER | USD notional |
| `from_wallet_type` / `to_wallet_type` | VARCHAR | Consumer / Business / Institutional |
| `from_balance_tier` / `to_balance_tier` | VARCHAR | whale / large / medium / small / micro / dust |
| `transaction_type` | VARCHAR | Real-World Payment / Investment/Trade / Store as Value / Unclassified |
| `wallet_type_combination` | VARCHAR | C2C, C2B, B2C, B2B, I2C, I2B, I2I, C2I, B2I, … |
| `from_30d_volume` / `to_30d_volume` | NUMBER | Rolling 30-day USD volume per side |
| `from_avg_txn_size` / `to_avg_txn_size` | NUMBER | 30-day average transaction size per side |
| `to_total_outflow_1m` / `to_total_outflow_3m` | NUMBER | Receiver rolling outflow (store-of-value signal) |
### Transaction Types
| Type | Description |
| ---------------------- | --------------------------------------------------------------------------------------- |
| **Real-World Payment** | Consumer/business payment-sized flows below large-ticket trade thresholds |
| **Investment/Trade** | Large B2B/I transfers, short-term pairs, outlier ticket sizes, chain-specific overrides |
| **Store as Value** | Receiver accumulating stablecoins relative to balance and typical ticket size |
| **Unclassified** | No rule matched with sufficient confidence |
### Wallet Types
| Type | Description |
| ----------------- | ----------------------------------------- |
| **Consumer** | Retail-sized activity |
| **Business** | Commercial volume patterns |
| **Institutional** | Treasury, protocol, or market-maker scale |
### Example Query — Transaction Type Distribution
```sql theme={null}
SELECT
transaction_type,
COUNT(*) AS tx_count,
SUM(usd_amount) AS total_volume
FROM stablecoins.intelligence.organic_activity_classification
WHERE activity_date >= CURRENT_DATE - 30
GROUP BY 1
ORDER BY 3 DESC;
```
***
## 3. payment\_categorization
**Purpose:** Granular payment category and purpose for transfers classified as `Real-World Payment`.
**Use Case:** Payment-use-case analytics, merchant insights, payroll/remittance tracking.
### Schema
Includes the wallet-type/balance-tier context from `organic_activity_classification`, plus:
| Column Name | Data Type | Description |
| ----------------------- | --------- | ----------------------------------------------------------------------------------------- |
| `core_payment_category` | VARCHAR | C2C / C2B / B2C / B2B Payment, I2C / I2B, Institutional Payment, Deposit to Institutional |
| `payment_purpose` | VARCHAR | Granular purpose within the category |
| `classification_tier` | VARCHAR | Core / Extended / Fallback confidence |
Only transfers with `transaction_type = 'Real-World Payment'` are present in this table. Deposits to institutional wallets and I2C flows are treated as Investment/Trade and excluded from the real-world payment mix.
### Core Payment Categories
| Category | Description |
| ---------------------------- | ---------------------------------------------------------------------- |
| **C2C Payment** | Consumer-to-Consumer transfers |
| **C2B Payment** | Consumer-to-Business purchases/services |
| **B2C Payment** | Business-to-Consumer payouts/refunds |
| **B2B Payment** | Business-to-Business settlements |
| **I2C / I2B Payment** | Institutional to consumer / business |
| **Institutional Payment** | Institutional-to-Institutional (I2I) |
| **Deposit to Institutional** | C2I / B2I inflows to institutional wallets (excluded from payment mix) |
### Payment Purposes (by flow)
| Flow | Example purposes |
| ------------------- | -------------------------------------------------------------------- |
| **C2C** | P2P Micro Payment, P2P Remittance, P2P Large Transfer |
| **C2B** | Retail Purchase, Service Payment, Large Purchase |
| **B2C** | Micro Payout, Gig/Creator Payout, Salary/Payroll, Large Disbursement |
| **B2B** | Service Fee, Supplier Payment, Large B2B Settlement |
| **I2C / I2B / I2I** | Institutional Settlement and related |
### Example Query — Payment Purpose Breakdown
```sql theme={null}
SELECT
core_payment_category,
payment_purpose,
COUNT(*) AS payment_count,
SUM(usd_amount) AS total_usd
FROM stablecoins.intelligence.payment_categorization
WHERE activity_date >= CURRENT_DATE - 30
GROUP BY 1, 2
ORDER BY 4 DESC;
```
***
## Table Relationships
```mermaid theme={null}
graph TD
A[enriched_transfers] -->|transaction intent| B[organic_activity_classification]
B -->|transaction_type = 'Real-World Payment'| C[payment_categorization]
```
`enriched_transfers` is the per-transfer base (adjusted-volume gate + flow categories). `organic_activity_classification` adds wallet typing and intent; `payment_categorization` adds purpose for the real-world-payment subset. Join across them on `chain` + `transaction_hash` (+ `unique_id` where a transaction has multiple legs).
***
## Next Steps
Learn how organic volume is calculated
Back to payments pipeline overview