> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dune.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Stablecoin Balances Enriched (EVM)
> Daily stablecoin balances and circulating supply with address-type enrichment across 37 supported EVM chains.
export const StablecoinBalancesSupplyNote = ({filterHint, includeCoverageGap = false, includeAddressCategoryBridge = false, hasIsCirculatingField = false}) => <>
Interpreting balances vs circulating supply
- This table records onchain balances per address per day. Totals are not equivalent to circulating supply by default — bridge-locked, issuer-escrow, and CEX proof-of-assets balances are intentionally retained so you can analyze them.
-
Two metrics, two recipes:
- Total balances — sum
balance_usd with no exclusion filter. Includes bridge-locked funds (e.g., more than $4B USDT can appear in the Tether USDT0Adapter contract on Ethereum while representing circulating USDT0 on other chains), issuer escrow, and CEX-locked balances.
{hasIsCirculatingField ? - Circulating supply — add
WHERE is_circulating = true. The flag excludes lock-and-mint / rollup-escrow / check-balance / non-minting bridges (address_subcategory in bridge_lockAndMint, bridge_rollup_escrow, bridge_check_balance, bridge_nonMinting), issuer bridge escrow, and CEX proof-of-assets wallets (e.g., Binance Stablecoin Proof of Assets). : - Circulating supply — this foundation table does not carry the
is_circulating flag. Use the enriched balances table (stablecoins_evm.balances_enriched, stablecoins_solana.balances_enriched, or stablecoins_tron.balances_enriched) and filter WHERE is_circulating = true. }
- We retain bridge / issuer-escrow / CEX-locked balances in the table itself because exclusions are not objective across bridge designs, and some bridge-held balances represent liquidity for chains not covered elsewhere. The
is_circulating flag encodes Dune's best-known classification — readable, auditable, and revisable as coverage improves.
{includeCoverageGap && - Excluding only selected bridges would also be incomplete in practice: some bridge-held balances represent liquidity for chains not covered elsewhere (for example Lighter and Hyperliquid bridge balances).
}
{includeAddressCategoryBridge && - Bridge exposure is directly analyzable with
address_category = 'bridge'. }
{filterHint && - {filterHint}
}
;
export const PremiumDatasetAccessCard = ({href = "https://dune.com/enterprise#contact-form"}) =>
This dataset is part of a premium offering and requires additional access. Contact the Dune enterprise team to request access.
;
The `stablecoins_evm.balances_enriched` table extends EVM stablecoin balances with address classification, entity tags, whale flags, and a circulating supply flag.
## Why these enriched tables matter
Stablecoin analysis comes down to two fundamental questions:
1. Where are stablecoins right now? (balances)
2. How did they get there? (activity)
This balances-enriched table answers the first question by going beyond raw balances and adding attribution for where capital sits: CEX, lending, treasury, yield, bridge, whale concentration, and more.
## Table schema
| Column | Type | Description |
| --------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `blockchain` | `VARCHAR` | Chain name |
| `day` | `DATE` | Balance date (partition column) |
| `address` | `VARBINARY` | Holder address |
| `token_symbol` | `VARCHAR` | Token symbol |
| `token_address` | `VARBINARY` | Token contract address |
| `token_standard` | `VARCHAR` | Token standard (`erc20`) |
| `token_id` | `VARCHAR` | Always `NULL` |
| `balance_raw` | `UINT256` | Raw balance |
| `balance` | `DOUBLE` | Decimals-adjusted balance |
| `balance_usd` | `DOUBLE` | USD value |
| `currency` | `VARCHAR` | ISO 4217 code |
| `address_category` | `VARCHAR` | Address category (see below) |
| `address_subcategory` | `VARCHAR` | Address subcategory |
| `address_project` | `VARCHAR` | Project/entity name (nullable) |
| `address_version` | `VARCHAR` | Project version (nullable) |
| `address_label` | `VARCHAR` | Label value (nullable) |
| `is_smart_contract` | `BOOLEAN` | Contract flag |
| `is_whale` | `BOOLEAN` | Address holds >= \$10M total stablecoins that day |
| `is_circulating` | `BOOLEAN` | `true` when the balance contributes to circulating supply. `false` for lock-and-mint / rollup-escrow / check-balance / non-minting bridge escrows, issuer bridge escrow, and CEX locked-token wallets (e.g., Binance Stablecoin Proof of Assets). Use `WHERE is_circulating = true` to compute circulating supply. |
| `last_updated` | `TIMESTAMP` | Last balance update time |
## Address categories
Every address receives exactly one `address_category` — no double counting is possible by construction. When an address matches a curated label, that label wins. Unlabeled addresses fall through: smart contract → `unidentified_smart_contract`, EOA with >= \$10M → `unidentified_whale`, otherwise → `unidentified`.
When an address appears in multiple label sets, a fixed priority order resolves the conflict (table is ordered by priority, highest first):
| `address_category` | Allowed `address_subcategory` values | Description |
| ----------------------------- | ---------------------------------------------- | -------------------------------------------------------------------------------------- |
| `erc20_contract` | `erc20_contract` | Canonical stablecoin token contracts defining supply. Not deployed capital. |
| `dex` | `dex_liquidity`, `dex_execution` | Stablecoins in decentralized exchange pools and routing contracts. |
| `lending` | `lending_liquidity`, `lending_execution` | Stablecoins deployed as credit in lending protocols. |
| `bridge` | `bridge_liquidity` | Stablecoins escrowed or locked for cross-chain transfers. |
| `yield` | `yield_liquidity`, `yield_execution` | Stablecoins in strategy or wrapper contracts earning passive yield. |
| `issuer` | `issuer_operations`, `issuer_treasury` | Stablecoin monetary infrastructure — minting, redemption, peg management. |
| `treasury_or_governance` | `treasury`, `treasury_collector`, `governance` | Protocol-controlled capital for governance, reserves, or fees. |
| `cex` | `cex` | Known exchange-controlled wallets (hot and cold). Not user deposit addresses. |
| `burn` | `burn` | Irrecoverable token sinks (dead/burn addresses). |
| `unidentified_smart_contract` | `unidentified_smart_contract` | Contracts detected onchain but not yet categorized. |
| `unidentified_whale` | `unidentified_whale` | Unlabeled EOAs holding >= \$10M total stablecoin balance that day. Recalculated daily. |
| `unidentified` | `unidentified` | Addresses with no known classification. |
As label coverage expands, new values may be added in backward-compatible fashion.
## Methodology
1. Start from daily rows in `stablecoins_evm.balances`.
2. Join curated address labels to assign `address_category`, subcategory, and project metadata where a label exists.
3. Derive `is_smart_contract` (from creation traces), `is_whale` (>= \$10M total stablecoin balance), and `is_circulating` (true unless the address is a bridge escrow / issuer bridge escrow / CEX locked-token wallet) flags per address per day.
4. Apply the priority waterfall for unlabeled addresses to maintain complete coverage.
Category totals should be interpreted as "where balances sit" rather than ownership or liability accounting. Labels represent the best-known economic function of an address and can evolve as coverage improves.
## Sample query
```sql theme={null}
SELECT
b.address_category
, b.token_symbol
, SUM(b.balance_usd) AS total_usd
FROM stablecoins_evm.balances_enriched AS b
WHERE b.blockchain = 'ethereum'
AND b.day = CURRENT_DATE
AND b.balance > 0
GROUP BY b.address_category, b.token_symbol
ORDER BY total_usd DESC
```
## Notes
* For performance, filter by `blockchain` and `day`.
* For circulating supply, filter `WHERE is_circulating = true`. For bridge exposure, filter `WHERE address_category = 'bridge'`. Both are intentionally retained in the table.