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

# rwa_multichain.trades

> Secondary-market trades of tokenized real-world assets — DEX swaps plus RWA-native venues including Ondo Global Markets, Swarm, and Dinari.

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>;

`rwa_multichain.trades` covers where tokenized RWAs actually change hands. Grain: one row per trade, keyed on `(blockchain, block_month, block_date, unique_key)`. It unions DEX swaps with RWA-native venues and normalizes both into a two-token swap schema.

<PremiumDatasetAccessCard />

## Two platform types

`platform_type` splits the table into the two kinds of venue:

| `platform_type` | What it covers                                                                                                        | Recent 7-day rows |
| --------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------- |
| `dex`           | Ordinary DEX swaps where one leg is an RWA — Uniswap, Raydium, PancakeSwap, Meteora, Curve, Aerodrome, and 30+ others | \~3.23M           |
| `rwa_platform`  | Purpose-built RWA venues — Ondo Global Markets, Swarm, Dinari                                                         | \~85K             |

DEX volume dominates by row count, but `rwa_platform` is where issuer-operated primary and secondary flow shows up. Split on `platform_type` rather than treating the table as homogeneous.

## rwa\_side tells you which leg is the RWA

Every row is a two-token swap, and either leg can be the real-world asset. `rwa_side` resolves it:

| `rwa_side`   | Meaning            | Read the RWA from                 |
| ------------ | ------------------ | --------------------------------- |
| `buy`        | The RWA was bought | `token_bought_*` columns          |
| `sell`       | The RWA was sold   | `token_sold_*` columns            |
| `rwa_to_rwa` | Both legs are RWAs | Either, depending on the question |

Ignoring `rwa_side` and always reading `token_bought_address` gives you the stablecoin or quote asset roughly half the time. For directional flow analysis, filter `rwa_side IN ('buy', 'sell')` to exclude the RWA-to-RWA rows that would double-count.

## Table schema

| Column                     | Type        | Description                                                  |
| -------------------------- | ----------- | ------------------------------------------------------------ |
| `blockchain`               | `VARCHAR`   | Chain for the trade                                          |
| `block_month`              | `DATE`      | Partition column                                             |
| `block_date`               | `DATE`      | Trade date                                                   |
| `block_time`               | `TIMESTAMP` | Trade timestamp                                              |
| `block_number`             | `BIGINT`    | Block height                                                 |
| `platform_type`            | `VARCHAR`   | `dex` or `rwa_platform`                                      |
| `project`                  | `VARCHAR`   | Venue name, e.g. `uniswap`, `raydium`, `ondo_global_markets` |
| `version`                  | `VARCHAR`   | Venue version where applicable                               |
| `token_bought_symbol`      | `VARCHAR`   | Symbol of the token received                                 |
| `token_bought_address`     | `VARCHAR`   | Address of the token received                                |
| `token_bought_amount`      | `DOUBLE`    | Decimals-adjusted amount received                            |
| `token_bought_amount_raw`  | `UINT256`   | Raw amount received                                          |
| `token_sold_symbol`        | `VARCHAR`   | Symbol of the token given                                    |
| `token_sold_address`       | `VARCHAR`   | Address of the token given                                   |
| `token_sold_amount`        | `DOUBLE`    | Decimals-adjusted amount given                               |
| `token_sold_amount_raw`    | `UINT256`   | Raw amount given                                             |
| `token_pair`               | `VARCHAR`   | Normalized pair label                                        |
| `amount_usd`               | `DOUBLE`    | USD value of the trade                                       |
| `taker`                    | `VARCHAR`   | Address taking the trade                                     |
| `maker`                    | `VARCHAR`   | Counterparty, where the venue exposes one                    |
| `project_contract_address` | `VARCHAR`   | Pool or venue contract                                       |
| `tx_id`                    | `VARCHAR`   | Transaction identifier                                       |
| `tx_from`                  | `VARCHAR`   | Transaction sender                                           |
| `tx_to`                    | `VARCHAR`   | Transaction recipient                                        |
| `event_index`              | `BIGINT`    | Event position within the transaction                        |
| `sub_event_index`          | `BIGINT`    | Position within a single event                               |
| `rwa_side`                 | `VARCHAR`   | Which leg is the RWA: `buy`, `sell`, or `rwa_to_rwa`         |
| `unique_key`               | `VARCHAR`   | Row identifier                                               |
| `_updated_at`              | `TIMESTAMP` | When this row was last written by the pipeline               |

<Note>
  Addresses are `VARCHAR` across all token and account columns — 0x-hex on EVM, base58 on Solana — so one query covers both without casting. Joining to the `VARBINARY` NAV tables does require a cast; see [NAV intervals](/data-catalog/curated/rwa/valuation/nav-intervals).
</Note>

## This table does not contain perpetuals

Perpetual futures on RWA underlyings are a different instrument with a different schema, and they live in [`perp_trades`](/data-catalog/curated/rwa/activity/perp-trades). A perp fill is not a two-token swap, so it is deliberately not unioned in here. Comparing spot to synthetic activity means querying both tables and joining on asset class.

## Example query

```sql theme={null}
-- Venue mix for RWA secondary trading
SELECT
  platform_type,
  project,
  COUNT(*) AS trades,
  COUNT(DISTINCT taker) AS unique_takers,
  SUM(amount_usd) AS volume_usd
FROM rwa_multichain.trades
WHERE block_month >= date_trunc('month', current_date - INTERVAL '1' month)
  AND rwa_side IN ('buy', 'sell')
GROUP BY 1, 2
ORDER BY 5 DESC NULLS LAST
LIMIT 30
```

**Net directional flow per asset, reading the correct leg:**

```sql theme={null}
SELECT
  block_date,
  CASE rwa_side
    WHEN 'buy' THEN token_bought_symbol
    WHEN 'sell' THEN token_sold_symbol
  END AS rwa_symbol,
  SUM(CASE WHEN rwa_side = 'buy' THEN amount_usd ELSE -amount_usd END) AS net_buy_usd,
  SUM(amount_usd) AS gross_volume_usd
FROM rwa_multichain.trades
WHERE block_month >= date_trunc('month', current_date)
  AND rwa_side IN ('buy', 'sell')
GROUP BY 1, 2
ORDER BY 1 DESC, 4 DESC NULLS LAST
```