> ## 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 Activity Enriched (EVM)

> Transfer-level stablecoin activity classification across 37 supported EVM chains

export const PremiumDatasetAccessCard = ({href = "https://dune.com/enterprise#contact-form"}) => <Card title="Premium dataset access" icon="info" href={href}>
    This dataset is part of a premium offering and requires additional access. Contact the Dune enterprise team to request access.
  </Card>;

The `stablecoins_evm.activity_enriched` table classifies each stablecoin transfer into an activity category (for example DEX, CEX, bridge, lending, issuer).

<PremiumDatasetAccessCard />

## 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 activity-enriched table answers the second question by tracing the economic path of transfers across categories such as DEX trading, lending, borrowing, bridging, internal transfers, and payment-like flows.

### What this dataset is designed to do

* Explain how stablecoin balances move through the ecosystem.
* Attribute transfer activity with transparent, reproducible logic.
* Provide a defensible foundation for flow analysis.

The goal is to turn stablecoin flow data from noise into structured economic insight.

## Table schema

| Column               | Type        | Description                             |
| -------------------- | ----------- | --------------------------------------- |
| `blockchain`         | `VARCHAR`   | Chain name                              |
| `block_month`        | `DATE`      | First day of month (partition column)   |
| `block_date`         | `DATE`      | Transaction date                        |
| `block_time`         | `TIMESTAMP` | Transaction timestamp                   |
| `block_number`       | `BIGINT`    | Block number                            |
| `tx_hash`            | `VARBINARY` | Transaction hash                        |
| `evt_index`          | `BIGINT`    | Transfer event index                    |
| `activity_evt_index` | `BIGINT`    | Matched activity event index (nullable) |
| `trace_address`      | `VARCHAR`   | Trace address (nullable)                |
| `token_standard`     | `VARCHAR`   | Token standard (`erc20`)                |
| `token_address`      | `VARBINARY` | Token contract address                  |
| `token_symbol`       | `VARCHAR`   | Token symbol                            |
| `currency`           | `VARCHAR`   | ISO 4217 code                           |
| `amount_raw`         | `UINT256`   | Raw transfer amount                     |
| `amount`             | `DOUBLE`    | Decimals-adjusted amount                |
| `price_usd`          | `DOUBLE`    | USD price used for valuation            |
| `amount_usd`         | `DOUBLE`    | USD amount                              |
| `from_address`       | `VARBINARY` | Sender                                  |
| `to_address`         | `VARBINARY` | Recipient                               |
| `category`           | `VARCHAR`   | Activity category                       |
| `activity`           | `VARCHAR`   | Activity label                          |
| `project_address`    | `VARBINARY` | Matched project address (nullable)      |
| `project_name`       | `VARCHAR`   | Matched project name (nullable)         |
| `project_version`    | `VARCHAR`   | Matched project version (nullable)      |
| `unique_key`         | `VARCHAR`   | Unique transfer identifier              |

## Value possibilities

The `category` and `activity` columns are intentionally standardized so downstream models, dashboards, and monitoring can rely on deterministic value vocabularies.

| `category`      | Allowed `activity` values                                               | Description                                                                                |
| --------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| `dex_swap`      | `dex_swap`                                                              | Direct swaps on decentralized exchanges and DEX aggregators (Uniswap, Curve, 1inch, etc.). |
| `flashloan`     | `flashloan_borrow`, `flashloan_repay`                                   | Atomic borrow-and-repay within a single transaction.                                       |
| `issuer`        | `issuer_peg_rebalance`                                                  | Peg stability module operations (e.g. Sky PSM, Spark PSM). Ethereum only.                  |
| `yield`         | `yield_deposit`, `yield_withdraw`                                       | Deposits and withdrawals from yield strategy contracts. Ethereum only.                     |
| `cex`           | `cex_deposit`, `cex_withdraw`, `cex_internal_transfer`                  | Transfers to/from known centralized exchange wallets.                                      |
| `lending`       | `lending_supply`, `lending_borrow`, `lending_repay`, `lending_withdraw` | Supply, borrow, repay, and withdraw on lending protocols.                                  |
| `bridge`        | `bridge_deposit`, `bridge_withdraw`                                     | Cross-chain transfers via bridge contracts.                                                |
| `dex_liquidity` | `dex_liquidity_supply`, `dex_liquidity_withdraw`                        | Non-swap transfers to/from DEX contracts (liquidity adds/removes).                         |
| `unidentified`  | `unidentified_activity`                                                 | Transfers not matched to any known activity pattern.                                       |

This mapping enables consistent flow segmentation, KPI rollups, and alerting logic without custom per-dashboard label handling.

As protocol coverage expands, new values may be added in backward-compatible fashion.

## Methodology

Classification is done at the transfer level, not the transaction level.

1. Start from curated stablecoin transfer rows in `stablecoins_evm.transfers`.
2. Build candidate matches for each transfer against activity-specific datasets (for example DEX, bridge, CEX, flashloan, lending, and issuer signals) using transfer-level keys such as `tx_hash`, token identity, and amount context.
3. Resolve conflicts with a deterministic precedence order, so each transfer gets exactly one winning category.
4. Write unmatched transfers as `unidentified` to preserve full coverage instead of dropping rows.

### Important interpretation details

* One transaction can map to multiple categories if it contains multiple stablecoin transfers.
* `project_address`, `project_name`, and `project_version` are populated only when a protocol/entity match exists.
* Priority rules improve consistency, but edge cases still exist when protocols emit similar transfer patterns in the same transaction.

## Sample query

```sql theme={null}
SELECT
    a.block_date
    , a.category
    , COUNT(*) AS transfers
    , SUM(a.amount_usd) AS volume_usd
FROM stablecoins_evm.activity_enriched AS a
WHERE a.blockchain = 'ethereum'
    AND a.block_date >= CURRENT_DATE - INTERVAL '30' DAY
GROUP BY a.block_date, a.category
ORDER BY a.block_date DESC, volume_usd DESC
```

## Notes

* One transfer maps to one output row (highest-priority match wins).
* For performance, filter by `blockchain` and `block_month`.