> ## 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.

# Adjusted Volume Methodology

> How Allium calculates organic stablecoin payment volume

## 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
* ✅ Public address tags (Etherscan, blockchain explorers)
* ✅ 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:

```sql theme={null}
-- 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

1. **Sample Inspection:** Manual review of 1000 random transfers per month
2. **Comparison to Known Benchmarks:** Cross-check with public payment processors
3. **Anomaly Detection:** Flag sudden volume changes for investigation
4. **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 Filtered Transfers

All organic transfers (after attribution filtering):

```sql theme={null}
SELECT
  chain,
  token_symbol,
  SUM(usd_amount) AS adjusted_volume
FROM crosschain.stablecoin.filtered_transfers
WHERE block_timestamp >= CURRENT_DATE - 30
GROUP BY 1, 2;
```

### Compare Raw vs Adjusted

See the impact of filtering:

```sql theme={null}
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 crosschain.stablecoin.filtered_transfers
  WHERE chain = 'ethereum'
    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

<AccordionGroup>
  <Accordion title="Use adjusted volume for payment metrics" icon="chart-line">
    Always use `filtered_transfers` table when measuring real-world payment activity. Raw volume inflates metrics by 4-5x.
  </Accordion>

  <Accordion title="Combine with transaction classification" icon="layer-group">
    Join `filtered_transfers` with `transaction_classification` to further segment by payment type (P2P, B2C, etc.).
  </Accordion>

  <Accordion title="Monitor attribution coverage" icon="magnifying-glass-chart">
    Check label coverage in your analysis window. Low coverage may indicate new protocols or chains.
  </Accordion>

  <Accordion title="Report suspicious patterns" icon="flag">
    If you notice addresses that should be labeled but aren't, contact Allium support.
  </Accordion>
</AccordionGroup>

## FAQ

<Accordion title="Why is my chain's adjusted volume much lower than raw volume?" icon="circle-question">
  This is expected. Most chains have significant CEX/DeFi activity. A 20-30% organic ratio is normal for mature chains.
</Accordion>

<Accordion title="Are bridge transfers included in adjusted volume?" icon="bridge">
  No. Bridge transfers are infrastructure operations. The payment occurs when the bridged funds are spent.
</Accordion>

<Accordion title="How often is attribution data updated?" icon="clock">
  Weekly. New exchanges, protocols, and infrastructure addresses are added continuously.
</Accordion>

<Accordion title="Can I access the raw attribution labels?" icon="lock">
  Attribution labels are internal to Allium. `filtered_transfers` provides the filtered result, but labels themselves are not exposed in marts tables.
</Accordion>

## Next Steps

<CardGroup cols={2}>
  <Card title="Table Reference" icon="table" href="/historical-data/payments/tables">
    Detailed schema for all payment pipeline tables
  </Card>

  <Card title="Pipeline Overview" icon="sitemap" href="/historical-data/payments/overview">
    Back to payments pipeline overview
  </Card>
</CardGroup>