Skip to main content
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.

Table schema

token_standard here uses finer-grained values than rwa_multichain.tokenserc20, 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).

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. 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:
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.
For issuance and redemption analysis, use supply_changes instead. It covers mints and redeems consistently across all chains, including EVM, with a signed amount column for net flow.

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.

Example query

Largest single transfers of an asset: