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

Use is_supply_event for cross-chain mint/burn filtering

is_supply_event is the normalized cross-chain flag for native supply changes. Use it to isolate peer-to-peer movement:
Keep transfer_type when you need chain-native detail. It is NULL for every EVM row and 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. 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 native supply events consistently across all chains, including EVM, with direction (increase / decrease) for net-flow calculations.

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, so an unfiltered scan is expensive.

Example query

Largest single transfers of an asset: