rwa_multichain.transfers

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

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 transfers from 21 chains into a single schema with VARCHAR addresses.

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	Curated USD price applied to this transfer
amount_usd	DOUBLE	Curated USD value of the transfer
transfer_type	VARCHAR	Event classification. Non-EVM chains only — see below
is_supply_event	BOOLEAN	true when the transfer is a native mint/burn or other supply change
_updated_at	TIMESTAMP	When this row was last refreshed

token_standard here uses finer-grained values than rwa_multichain.tokens: erc20, bep20, tip20, 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:

WHERE NOT is_supply_event

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.

Chain group	transfer_type	Mints and burns
All EVM-compatible chains	Always NULL	Present as zero-address rows; use is_supply_event
Solana, Stellar	Populated	Present as mint and burn rows
Sui, XRPL, Aptos	Populated	Use is_supply_event for supply changes

So a filter like WHERE transfer_type = 'transfer' silently drops all EVM-compatible activity, which is the large majority of rows. A plain SUM(amount) can include issuance and redemption alongside wallet-to-wallet movement on EVM-compatible chains, Solana, and Stellar. Use NOT is_supply_event to isolate peer-to-peer volume.

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 across supported chains and provides direction (increase or decrease) for net-flow calculations. Never sum transfers and supply_changes together.

Tempo reconstruction boundary

Tempo transfer and balance reconstruction is supported from 2026-05-05. This is a data support boundary, not a claim that Tempo began on that date. Coverage uses complete transfer replay from that boundary because no independent Tempo daily holder-state source exists.

Tempo’s zero-address TIP-20 rows remain in transfers. supply_changes derives them once and verifies them against native TIP-20 Mint and Burn events.

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.

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

Example query

-- 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 NOT is_supply_event
GROUP BY 1, 2
ORDER BY 1 DESC, 5 DESC NULLS LAST

Largest single transfers of an asset:

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