rwa_multichain.trades

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.

Two platform types

platform_type splits the table into the two kinds of venue:

`platform_type`	What it covers
`dex`	Ordinary DEX swaps where one leg is an RWA — Uniswap, Raydium, PancakeSwap, Meteora, Curve, Aerodrome, and others
`rwa_platform`	Purpose-built RWA venues — Ondo Global Markets, Swarm, Dinari

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. trades does not have a token_id column. To attach RWA reference data, select the RWA leg with rwa_side, then join its address to the relevant chain identity:

CASE rwa_side
  WHEN 'buy' THEN token_bought_address
  WHEN 'sell' THEN token_sold_address
END AS rwa_token_address

For EVM and Solana rows, that value matches rwa_multichain.tokens_reference_data.token_id.

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 refreshed

Addresses are VARCHAR across all token and account columns — 0x-hex on EVM, base58 on Solana — so one query covers both without casting. For point-in-time valuation, resolve the RWA leg and join prices on (blockchain, token_id) and its validity range.

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

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

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

Attach issuer and product class to the RWA leg:

WITH rwa_legs AS (
  SELECT
    *,
    CASE rwa_side
      WHEN 'buy' THEN token_bought_address
      WHEN 'sell' THEN token_sold_address
    END AS rwa_token_id
  FROM rwa_multichain.trades
  WHERE block_month >= DATE_TRUNC('month', CURRENT_DATE)
    AND rwa_side IN ('buy', 'sell')
)
SELECT
  r.issuer_name,
  r.product_asset_class,
  SUM(t.amount_usd) AS volume_usd
FROM rwa_legs AS t
INNER JOIN rwa_multichain.tokens_reference_data AS r
  ON r.blockchain = t.blockchain
  AND r.token_id = t.rwa_token_id
GROUP BY 1, 2
ORDER BY 3 DESC

Curated Data

Solana

Hyperliquid

Non-EVM Networks

Protocols

EVM Networks

Partner Data

Dune Index

rwa_multichain.trades

Two platform types

rwa_side tells you which leg is the RWA

Table schema

This table does not contain perpetuals

Example query

​Two platform types

​rwa_side tells you which leg is the RWA

​Table schema

​This table does not contain perpetuals

​Example query

Two platform types

rwa_side tells you which leg is the RWA

Table schema

This table does not contain perpetuals

Example query