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

> Transfer-level movement of tokenized real-world assets across 19 chains, normalized into one cross-chain schema.

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.transfers` is the movement table for tokenized RWAs. Grain: one row per transfer, keyed on `(blockchain, block_month, block_date, unique_key)`. It normalizes EVM, Solana, Aptos, Sui, XRPL, and Stellar transfers into a single schema with `VARCHAR` addresses.

<PremiumDatasetAccessCard />

## Table schema

| Column            | Type        | Description                                                                       |
| ----------------- | ----------- | --------------------------------------------------------------------------------- |
| `unique_key`      | `VARCHAR`   | Row identifier                                                                    |
| `blockchain`      | `VARCHAR`   | Chain for the transfer                                                            |
| `block_time`      | `TIMESTAMP` | Transfer timestamp                                                                |
| `block_date`      | `DATE`      | Transfer date                                                                     |
| `block_month`     | `DATE`      | Partition column. Filter on this for large scans                                  |
| `block_number`    | `BIGINT`    | Block height                                                                      |
| `tx_id`           | `VARCHAR`   | Transaction identifier. Transaction hash on EVM, signature on Solana              |
| `tx_index`        | `BIGINT`    | Transaction position within the block                                             |
| `event_index`     | `BIGINT`    | Event position within the transaction                                             |
| `sub_event_index` | `BIGINT`    | Position within a single event, for chains that emit multiple movements per event |
| `from_address`    | `VARCHAR`   | Sender. 0x-hex on EVM, base58 on Solana, native form elsewhere                    |
| `to_address`      | `VARCHAR`   | Recipient                                                                         |
| `tx_signer`       | `VARCHAR`   | Account that signed the transaction, which may differ from `from_address`         |
| `token_address`   | `VARCHAR`   | Normalized native token identifier. Join key to the NAV tables after casting      |
| `token_id`        | `VARCHAR`   | Normalized cross-chain token identifier, joins to `rwa_multichain.tokens`         |
| `token_symbol`    | `VARCHAR`   | RWA token symbol                                                                  |
| `token_standard`  | `VARCHAR`   | Native token standard. Finer-grained than on `tokens` — see the note below        |
| `amount_raw`      | `DOUBLE`    | Amount in the token's native precision                                            |
| `amount`          | `DOUBLE`    | Decimals-adjusted amount                                                          |
| `price_usd`       | `DOUBLE`    | USD price applied to this transfer, where coverage exists                         |
| `amount_usd`      | `DOUBLE`    | USD value of the transfer, where coverage exists                                  |
| `transfer_type`   | `VARCHAR`   | Event classification. **Non-EVM chains only** — see below                         |
| `_updated_at`     | `TIMESTAMP` | When this row was last written by the pipeline                                    |

<Warning>
  `token_standard` here uses finer-grained values than `rwa_multichain.tokens` — `erc20`, `bep20`, `spl_token`, `spl_token_2022`, `classic`, `soroban`, `issued`, `sui_coin`. Do not join the two tables on `token_standard`; join on `(blockchain, token_id)`.
</Warning>

## transfer\_type is only populated on non-EVM chains

This is the single most common source of wrong results on this table. `transfer_type` is `NULL` for **every** EVM row. It is populated only on Solana, Stellar, Sui, XRPL, and Aptos.

| Chain group                                                                 | `transfer_type` | Mints and burns                             |
| --------------------------------------------------------------------------- | --------------- | ------------------------------------------- |
| EVM (Ethereum, Base, Arbitrum, BNB, Polygon, Robinhood Chain, and the rest) | Always `NULL`   | Excluded upstream                           |
| Solana, Stellar                                                             | Populated       | **Present** as `mint` and `burn` rows       |
| Sui, XRPL, Aptos                                                            | Populated       | Not observed, but other typed values appear |

So a filter like `WHERE transfer_type = 'transfer'` silently drops all EVM activity, which is the large majority of rows. And a plain `SUM(amount)` over Solana or Stellar includes issuance and redemption alongside wallet-to-wallet movement.

For strictly peer-to-peer movement across all chains:

```sql theme={null}
WHERE transfer_type IS NULL
   OR transfer_type NOT IN ('mint', 'burn')
```

Values observed on the typed chains include `transfer`, `mint`, `burn`, `payment`, `object_created`, `object_deleted`, `ownership_transfer`, `ownership_balance_topup`, `ownership_balance_spend`, and `transfer_with_balance_change`.

<Note>
  For issuance and redemption analysis, use [`supply_changes`](/data-catalog/curated/rwa/holders-supply/supply-changes) instead. It covers mints and redeems consistently across all chains, including EVM, with a signed amount column for net flow.
</Note>

## Query performance

Filter on `block_month` or `block_date` to prune partitions, and add `blockchain` when you only need one chain. Robinhood Chain and Solana dominate row counts — Robinhood alone carries over 24 million transfers in a typical week — so an unfiltered scan is expensive.

```sql theme={null}
-- ✅ Good: partition-pruned and chain-scoped
SELECT * FROM rwa_multichain.transfers
WHERE block_month >= date_trunc('month', current_date)
  AND blockchain = 'ethereum'
```

## Example query

```sql theme={null}
-- Weekly peer-to-peer transfer volume by chain
SELECT
  date_trunc('week', block_date) AS week,
  blockchain,
  COUNT(*) AS transfers,
  COUNT(DISTINCT from_address) AS unique_senders,
  SUM(amount_usd) AS volume_usd
FROM rwa_multichain.transfers
WHERE block_month >= date_trunc('month', current_date - INTERVAL '2' month)
  AND (transfer_type IS NULL OR transfer_type NOT IN ('mint', 'burn'))
GROUP BY 1, 2
ORDER BY 1 DESC, 5 DESC NULLS LAST
```

**Largest single transfers of an asset:**

```sql theme={null}
SELECT
  block_time,
  blockchain,
  from_address,
  to_address,
  amount,
  amount_usd,
  tx_id
FROM rwa_multichain.transfers
WHERE block_month >= date_trunc('month', current_date - INTERVAL '1' month)
  AND token_symbol = 'BUIDL'
ORDER BY amount DESC
LIMIT 25
```