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

# Overview

> Classify wallets by balance tier, behavior, engagement, and risk from their stablecoin activity, across all supported chains.

Wallet Classification turns raw stablecoin activity into a compact wallet profile: a balance tier, a wallet type, a behavioral segment, and 0–100 engagement and risk scores. Use it to size cohorts, segment users, and screen for volatile or anomalous wallets without building the feature pipeline yourself.

Each row is a **daily snapshot of one wallet on one chain** — `(chain, address, snapshot_date)` is the unique key.

<Note>
  Classification is derived from **stablecoin transfers and balances** (the top stablecoins per chain), not from a wallet's full on-chain footprint. A wallet's tier and scores describe its *stablecoin* behavior. A heavy NFT or DEX trader who rarely touches stablecoins will look small here. For a wallet's broader activity, see [Wallet 360](/historical-data/wallet-360).
</Note>

<Tip>
  **Always filter by `chain`.** The crosschain table unions 30+ chains, so an unfiltered scan reads every chain at once. Filtering by `chain` (and, where possible, `snapshot_date`) keeps queries fast and cheap — the table is clustered on `snapshot_date`, and `chain` is the natural partition. Every sample query below filters by chain for this reason.
</Tip>

### Where it lives

The dataset is exposed as a single all-chains table:

| Table                                        | Notes                                                                                                    |
| -------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| `crosschain.wallet360.wallet_classification` | All chains in one view. **Always filter by `chain`** (and ideally `snapshot_date`) to keep queries fast. |

A wallet active on several chains appears as **one row per chain** — aggregate across rows (`group by address`) for a wallet's multi-chain view.

### How addresses are selected

The address universe is built from **filtered stablecoin transfers**, then snapshotted to each wallet's most recent activity day.

<Steps>
  <Step title="Start from top stablecoins">
    Transfers of the top stablecoins per chain (the largest by volume) are the raw input. Activity in non-tracked tokens does not contribute.
  </Step>

  <Step title="Keep only organic, real-payment transfers">
    A transfer is included only when it is the **largest USD leg** of its transaction that day, the sender is **organic**, and the transfer is **not a mint or burn**. An address is flagged inorganic (and dropped) when it moves **≥ \$10M** or makes **≥ 1,000 transfers** in a rolling 31-day window, or carries a bot/MEV label.
  </Step>

  <Step title="Exclude non-end-user addresses">
    Addresses labeled as exchanges, DeFi protocols, infrastructure, bridges, treasuries, tokens/contracts, or sanctioned are excluded, along with **dust** (max balance \< $10 and 30-day volume &lt; $100) and obvious **bot/test** wallets (active nearly every day with an average transfer \< \$3).
  </Step>

  <Step title="Snapshot to the latest activity day">
    `snapshot_date` is the wallet's **last day of recorded stablecoin activity**. Models run daily with a 30-day lookback so the rolling 30-day metrics stay correct. Downstream consumers typically take the latest snapshot per wallet.
  </Step>
</Steps>

<Note>
  No attribution labels (CEX / DeFi / infrastructure / entity names) are exposed in this table by design. Labels are used internally to assign `wallet_type`, but are not output as columns.
</Note>

### Classification dimensions

| Dimension      | Column(s)                                                               | What it answers                                                    |
| -------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------ |
| **Size**       | `balance_tier`                                                          | How large is the wallet? (whale → dust, by max stablecoin balance) |
| **Type**       | `wallet_type`                                                           | Consumer, Business, or Institutional behavior                      |
| **Lifecycle**  | `behavioral_segment`, `combined_segment`                                | New, active, dormant, or churned                                   |
| **Engagement** | `engagement_score`, `engagement_tier` (+ recency/frequency/consistency) | How consistently active is the wallet? (0–100)                     |
| **Risk**       | `risk_score`, `risk_flag` (+ volatility/anomaly)                        | How volatile or anomalous is its balance? (0–100)                  |

See [Wallet Classification Attributes](/historical-data/wallet-classification/table-columns) for every column, its formula, and exact thresholds.

### Sample queries

<Tabs>
  <Tab title="Cohort sizing (one chain)">
    Distribution of wallets by balance tier and lifecycle on Ethereum, latest snapshot per wallet.

    ```sql theme={null}
    with latest as (
        select *
        from crosschain.wallet360.wallet_classification
        where chain = 'ethereum'                      -- always filter by chain
        qualify row_number() over (
            partition by address order by snapshot_date desc
        ) = 1
    )
    select
        balance_tier,
        behavioral_segment,
        count(*) as wallets
    from latest
    group by all
    order by wallets desc
    ```
  </Tab>

  <Tab title="High-value active users">
    Engaged whales and large wallets currently active on Base.

    ```sql theme={null}
    select address, balance_tier, engagement_tier, engagement_score, current_balance_usd
    from crosschain.wallet360.wallet_classification
    where chain = 'base'                              -- always filter by chain
        and balance_tier in ('whale', 'large')
        and behavioral_segment = 'active'
        and engagement_score >= 60
    qualify row_number() over (partition by address order by snapshot_date desc) = 1
    order by current_balance_usd desc
    limit 100
    ```
  </Tab>

  <Tab title="Risk screen">
    Wallets flagged high risk on Polygon in the last 7 days.

    ```sql theme={null}
    select address, risk_score, volatility_risk_score, anomaly_risk_score, current_balance_usd
    from crosschain.wallet360.wallet_classification
    where chain = 'polygon'                           -- always filter by chain
        and snapshot_date >= current_date - 7         -- and bound the date range
        and risk_flag = 'high'
    order by risk_score desc
    ```
  </Tab>

  <Tab title="Multi-chain footprint">
    Wallets present on more than one chain (aggregate across the per-chain rows).

    ```sql theme={null}
    with latest as (
        select chain, address, balance_tier
        from crosschain.wallet360.wallet_classification
        where chain in ('ethereum', 'base', 'polygon', 'arbitrum')  -- scope the chains
        qualify row_number() over (
            partition by chain, address order by snapshot_date desc
        ) = 1
    )
    select address, count(distinct chain) as chains, array_agg(chain) as chain_list
    from latest
    group by address
    having count(distinct chain) > 1
    order by chains desc
    ```
  </Tab>
</Tabs>

<Note>
  On chains without native end-of-day stablecoin balances, `current_balance_usd` and the balance-derived fields are reconstructed from net transfer flow and are best-effort rather than exact. Tiering and engagement signals remain directionally reliable.
</Note>