Adjusted Volume Methodology - Allium Documentation Hub

Overview

Adjusted Volume isolates real-world economic activity by filtering out non-organic transfers that inflate raw blockchain metrics. This methodology provides accurate payment volume measurements for business intelligence, regulatory compliance, and market analysis.

Filtering Methodology

Step 1: Attribution Labeling

Every blockchain address is classified using Allium’s proprietary attribution engine:

Attribution Category	Description	Examples
CEX	Centralized exchange addresses	Binance, Coinbase, Kraken hot/cold wallets
DeFi	Decentralized finance protocols	Uniswap, Aave, Compound smart contracts
Infrastructure	Operational/system addresses	Bridge contracts, multisigs, treasury addresses
Organic	Individual wallets and businesses	Consumer wallets, merchant addresses

Attribution Sources:

✅ Allium’s curated address label database
✅ On-chain behavior analysis
✅ Known contract deployments

Step 2: Transfer Filtering

Transfers are excluded if either the sender OR recipient is labeled as CEX/DeFi/Infrastructure:

-- Filtering logic
WHERE
  from_attribution NOT IN ('CEX', 'DeFi', 'Infrastructure')
  AND to_attribution NOT IN ('CEX', 'DeFi', 'Infrastructure')

Result: Only transfers between organic addresses remain (the “adjusted volume”).

Step 3: Crosschain Aggregation

Adjusted transfers are aggregated across all supported chains:

EVM Chains: Ethereum, Polygon, Arbitrum, Optimism, Base, BSC, Avalanche, etc.
Non-EVM: Solana, Tron, Bitcoin (via wrapped assets)
Stablecoins: USDC, USDT, DAI, BUSD, USDP, and others

Attribution Impact Analysis

Sample Volume Breakdown (30-day period)

Category	Raw Volume	% of Total	Excluded from Adjusted?
Organic Transfers	$2.1B	21%	❌ No (included)
CEX Activity	$5.8B	58%	✅ Yes
DeFi Protocols	$1.6B	16%	✅ Yes
Infrastructure	$0.5B	5%	✅ Yes
Total Raw	$10.0B	100%	-
Adjusted Volume	$2.1B	21%	-

Key Insight: ~79% of raw volume represents non-payment activity.

Why Exclude CEX/DeFi/Infrastructure?

CEX Exclusions

Problem: CEX addresses represent internal operations, not economic payments. Examples of excluded CEX activity:

User deposits → Exchange hot wallet (operational, not payment)
Exchange hot wallet → Cold storage (operational)
Market maker wallets ↔ Exchange (trading, not payment)

Retained: CEX → Individual wallet (withdrawal = potential payment destination)

DeFi Exclusions

Problem: DeFi interactions are investment/trading, not payments. Examples of excluded DeFi activity:

User → Uniswap (swap, not payment)
User → Aave (lending, not payment)
Yield farm ↔ User (farming rewards, not payment)

Retained: DeFi profits → User → Merchant (the final payment leg)

Infrastructure Exclusions

Problem: Infrastructure addresses represent system operations. Examples of excluded infrastructure:

Bridge contracts (cross-chain transfers)
Multisig treasuries (organizational management)
Protocol-owned liquidity (POL)

Edge Cases & Considerations

Case 1: CEX Withdrawals for Payments

Scenario: User withdraws USDC from Coinbase → Pays merchant Handling:

❌ CEX → User: Excluded (withdrawal, not payment)
✅ User → Merchant: Included (this is the actual payment)

Result: The payment is captured, but the withdrawal noise is removed.

Case 2: DeFi Yield → Real Payment

Scenario: User earns yield on Aave → Withdraws → Pays service provider Handling:

❌ Aave → User: Excluded (DeFi distribution)
✅ User → Service Provider: Included (payment)

Result: The payment is captured accurately.

Case 3: Cross-Chain Bridge Transfers

Scenario: User bridges USDC from Ethereum → Polygon via bridge Handling:

❌ User → Bridge Contract (Ethereum): Excluded (infrastructure)
❌ Bridge Contract → User (Polygon): Excluded (infrastructure)
The bridge transfer is NOT counted as payment volume

Why: Cross-chain transfers are asset movements, not payments. The payment occurs when the user spends the bridged funds.

Case 4: Merchant Payment Processors

Scenario: Customer pays merchant via payment processor (e.g., BitPay, Coinbase Commerce) Handling:

If payment processor is labeled as infrastructure → Excluded
If payment processor is organic → Included

Note: Payment processor addresses are continually reviewed for accurate classification.

Data Quality & Updates

Attribution Accuracy

Metric	Value
Labeled addresses	500M+ addresses
CEX coverage	100 exchanges, 10k+ addresses
DeFi coverage	5000+ protocols
Update frequency	Weekly
False positive rate	<0.5%

Continuous Improvement

Attribution updates:

✅ New CEX addresses added weekly
✅ New DeFi protocols added on deployment
✅ Community-reported labels reviewed
✅ Behavioral patterns analyzed for unlabeled addresses

Validation & Verification

Independent Verification Methods

Sample Inspection: Manual review of 1000 random transfers per month
Comparison to Known Benchmarks: Cross-check with public payment processors
Anomaly Detection: Flag sudden volume changes for investigation
User Feedback: Customers report suspicious patterns

Known Limitations

Limitation	Impact	Mitigation
Newly deployed DEX	May not be labeled immediately	Automated contract detection
Privacy wallets	Hard to attribute	Behavioral analysis
Unlabeled CEX	May be included erroneously	Community reporting
Complex smart contracts	May be misclassified	Manual review queue

Accessing Adjusted Volume

Query Adjusted Volume

All organic transfers (filter enriched_transfers on the is_adjusted_volume flag):

SELECT
  chain,
  token_symbol,
  SUM(usd_amount) AS adjusted_volume
FROM stablecoins.intelligence.enriched_transfers
WHERE is_adjusted_volume
  AND block_timestamp >= CURRENT_DATE - 30
GROUP BY 1, 2;

The full enriched_transfers table is gated. For a rolling 30-day window, use the broadly-shared stablecoins.intelligence.enriched_transfers_last_30d view (same schema).

Compare Raw vs Adjusted

See the impact of filtering:

WITH raw_volume AS (
  SELECT
    SUM(amount_usd) AS raw
  FROM ethereum.assets.fungible_token_transfers
  WHERE token_symbol IN ('USDC', 'USDT', 'DAI')
    AND block_timestamp >= CURRENT_DATE - 30
),
adjusted_volume AS (
  SELECT
    SUM(usd_amount) AS adjusted
  FROM stablecoins.intelligence.enriched_transfers
  WHERE chain = 'ethereum'
    AND is_adjusted_volume
    AND block_timestamp >= CURRENT_DATE - 30
)
SELECT
  r.raw AS raw_volume,
  a.adjusted AS adjusted_volume,
  (a.adjusted / r.raw) * 100 AS organic_percentage
FROM raw_volume r, adjusted_volume a;

Best Practices

Use adjusted volume for payment metrics

Always filter enriched_transfers on is_adjusted_volume when measuring real-world payment activity. Raw volume inflates metrics by 4-5x.

Combine with classification tables

Join enriched_transfers with organic_activity_classification and payment_categorization (on chain + transaction_hash) to segment by transaction intent and payment purpose (P2P, B2C, payroll, etc.).

Monitor attribution coverage

Check label coverage in your analysis window. Low coverage may indicate new protocols or chains.

Report suspicious patterns

If you notice addresses that should be labeled but aren’t, contact Allium support.

FAQ

Why is my chain's adjusted volume much lower than raw volume?

This is expected. Most chains have significant CEX/DeFi activity. A 20-30% organic ratio is normal for mature chains.

Are bridge transfers included in adjusted volume?

No. Bridge transfers are infrastructure operations. The payment occurs when the bridged funds are spent.

How often is attribution data updated?

Weekly. New exchanges, protocols, and infrastructure addresses are added continuously.

Can I access the raw attribution labels?

Attribution labels are internal to Allium. enriched_transfers exposes the filtered result via is_adjusted_volume plus flow categories, but the raw labels themselves are not exposed in marts tables.

​Overview

​Filtering Methodology

​Step 1: Attribution Labeling

​Step 2: Transfer Filtering

​Step 3: Crosschain Aggregation

​Attribution Impact Analysis

​Sample Volume Breakdown (30-day period)

​Why Exclude CEX/DeFi/Infrastructure?

​CEX Exclusions

​DeFi Exclusions

​Infrastructure Exclusions

​Edge Cases & Considerations

​Case 1: CEX Withdrawals for Payments

​Case 2: DeFi Yield → Real Payment

​Case 3: Cross-Chain Bridge Transfers

​Case 4: Merchant Payment Processors

​Data Quality & Updates

​Attribution Accuracy

​Continuous Improvement

​Validation & Verification

​Independent Verification Methods

​Known Limitations

​Accessing Adjusted Volume

​Query Adjusted Volume

​Compare Raw vs Adjusted

​Best Practices

​FAQ

​Next Steps

Table Reference

Pipeline Overview

Overview

Filtering Methodology

Step 1: Attribution Labeling

Step 2: Transfer Filtering

Step 3: Crosschain Aggregation

Attribution Impact Analysis

Sample Volume Breakdown (30-day period)

Why Exclude CEX/DeFi/Infrastructure?

CEX Exclusions

DeFi Exclusions

Infrastructure Exclusions

Edge Cases & Considerations

Case 1: CEX Withdrawals for Payments

Case 2: DeFi Yield → Real Payment

Case 3: Cross-Chain Bridge Transfers

Case 4: Merchant Payment Processors

Data Quality & Updates

Attribution Accuracy

Continuous Improvement

Validation & Verification

Independent Verification Methods

Known Limitations

Accessing Adjusted Volume

Query Adjusted Volume

Compare Raw vs Adjusted

Best Practices

FAQ

Next Steps