> ## 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 (Solana)

> Transfer-level stablecoin activity classification on Solana

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_solana.activity_enriched` table classifies each stablecoin transfer on Solana into an activity category.

<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 (`solana`)                 |
| `block_month`             | `DATE`      | First day of month (partition column) |
| `block_date`              | `DATE`      | Transaction date                      |
| `block_time`              | `TIMESTAMP` | Transaction timestamp                 |
| `block_slot`              | `BIGINT`    | Solana slot number                    |
| `tx_id`                   | `VARCHAR`   | Transaction signature                 |
| `outer_instruction_index` | `BIGINT`    | Outer instruction index               |
| `inner_instruction_index` | `BIGINT`    | Inner instruction index (nullable)    |
| `token_mint_address`      | `VARCHAR`   | Token mint address                    |
| `token_symbol`            | `VARCHAR`   | Token symbol                          |
| `currency`                | `VARCHAR`   | ISO 4217 code                         |
| `from_owner`              | `VARCHAR`   | Sender wallet                         |
| `to_owner`                | `VARCHAR`   | Receiver wallet                       |
| `amount_raw`              | `UINT256`   | Raw transfer amount                   |
| `amount`                  | `DOUBLE`    | Decimals-adjusted amount              |
| `amount_usd`              | `DOUBLE`    | USD amount                            |
| `outer_executing_account` | `VARCHAR`   | Program executing instruction         |
| `category`                | `VARCHAR`   | Activity category                     |
| `activity`                | `VARCHAR`   | Activity label                        |
| `project_address`         | `VARCHAR`   | 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.                      |
| `cex`                       | `cex_deposit`, `cex_withdraw`, `cex_internal_transfer`                                          | Transfers to/from known centralized exchange wallets.         |
| `issuer`                    | `issuer_mint`, `issuer_burn`, `issuer_unidentified`                                             | Stablecoin minting, redemption, and peg stability operations. |
| `flashloan`                 | `flashloan_borrow`, `flashloan_repay`, `flashloan_unidentified`                                 | Atomic borrow-and-repay within a single transaction.          |
| `lending`                   | `lending_supply`, `lending_borrow`, `lending_repay`, `lending_withdraw`, `lending_unidentified` | Supply, borrow, repay, and withdraw on lending protocols.     |
| `yield`                     | `yield_unidentified`                                                                            | Transfers to/from yield strategy or wrapper programs.         |
| `bridge`                    | `bridge_deposit`, `bridge_withdraw`                                                             | Cross-chain transfers via bridge programs.                    |
| `unidentified`              | `unidentified_activity`                                                                         | Transfers not matched to any known activity pattern.          |
| `unidentified_bot_activity` | `unidentified_bot_activity`                                                                     | High-volume automated program patterns not yet classified.    |

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_solana.transfers`.
2. Evaluate each transfer against category-specific detection logic using Solana-native context (transaction signature, instruction indexes, token mint, transfer amount, and known program/address labels).
3. Apply deterministic priority rules when multiple category matches exist for a transfer.
4. Keep full transfer coverage by assigning unmatched rows to `unidentified` (or `unidentified_bot_activity` for high-volume automated program patterns).

### Important interpretation details

* The same transaction can produce different categories across its individual transfers.
* Instruction index context is important on Solana for distinguishing activity legs inside one transaction.
* `project_address`, `project_name`, and `project_version` are populated only when a confident protocol/entity match exists.

## Sample query

```sql theme={null}
SELECT
    a.block_date
    , a.category
    , COUNT(*) AS transfers
    , SUM(a.amount_usd) AS volume_usd
FROM stablecoins_solana.activity_enriched AS a
WHERE 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`.