rwa-analysis

RWA 分析

RWA 问题看起来像是简单的汇总（“X 的 AUM 是多少”“Y 有多少持有人”），但直接查询通常会以一种具体且反复出现的方式出错。在为 RWA 问题编写 SQL 前，请先阅读本文——这比事后排查被放大 30 倍的数字要省事得多。

汇总：取快照，不要求和

AUM、市值和供应量是存量（某个时间点的余额），而不是流量。对一段日期范围内的每日快照表求和，会把同一份余额反复累加。

• 对每个分组键取最新一行（使用 QUALIFY ROW_NUMBER() OVER (PARTITION BY ... ORDER BY date DESC) = 1，或按组取 MAX(date)），绝不要跨日对 market_cap_usd / supply 使用 SUM。
• 这个错误很容易被忽略，因为错误的数字看起来仍然合情合理——曾有一个实际案例报告的 AUM 为“$220B”，实际却是 $7.2B，这是将约 30 天的同一份快照相加后放大了约 30 倍。

多链产品：跨链求和，但要说明

代币化基金（BUIDL、BENJI 等）会分别部署在多条链上。每条链上的部署都是独立且真实的供应量——对同一快照日期的各链数据求和，才能得到真实的总 AUM；但如果查询只限定一条链，就会低估规模，让基金看起来远小于实际（一个实际案例：仅 Ethereum 上为 $415M，而 8 条链上的真实总额为 $1.67B）。

• 报告跨链总额时，还要列出 COUNT(DISTINCT chain) 或列明各条链——读者需要知道这个数字是汇总值，而不是单条链上的部署规模。

分类：依据风险因子，而非法律包装

应根据底层风险因子（asset_class / asset_type）分类，而不是根据法律结构或仅凭产品名称中的关键词判断。代币化国债 ETF 属于 rates，而不是 equities，尽管“ETF”听起来像是股票类产品。如果发现表中仍有已弃用的 rwa_class 列，不要使用它——请先确认它是否已被新的分类字段取代，再决定是否采用。

对于“代币化国债”，通常应使用筛选条件 asset_class = 'rates' AND asset_type IN ('government_debt_us', 'money_market_funds_us', 'repurchase_agreements')——请根据实时架构确认具体枚举值，因为这类值可能会被重命名。

Pre-IPO / 代币化股票：没有可直接使用的标记

没有 is_pre_ipo 布尔值。仅凭股票代码无法判断——一些听起来很新颖的代码（SKHX/SK Hynix、CRCL/Circle、KIOXIA）实际上已经公开交易。要计算真实的 Pre-IPO 成交量占比，请分别查询每个代码实际的 IPO 日期，并从该日期切分时间序列（例如，SpaceX/SPCX 于 2026-06-12 IPO——该日期之前的成交量属于 Pre-IPO，之后则不属于）。

还要留意不同发行平台上的产品重复：同一种底层金融工具可能以不同的产品形式在链上发行，并在各个平台使用不同的代码后缀（例如，Dinari 的 dShares FBTC.d / BTCO.d 与 Robinhood 的普通 FBTC / BTCO 是追踪同一底层 ETF 的两个不同产品，各自有自己的供应量和价值——把它们当成同一个产品相加会重复计算；把它们视为毫不相关的产品，则会低估该名称在整个生态中的实际覆盖情况）。如果按代码搜索没有结果，请搜索 symbol、name 和 product_name——根据平台不同，同一种金融工具可能会以其中任意一个字段编入索引。

缺少价格：不要报告空白

新上市或流动性不足的代币化资产，其供应量表中的 price_usd / market_cap_usd 通常为 NULL——因为尚无实时价格数据源。与其返回空白或静默丢弃该行，不如使用 supply × external NAV/share price 作为估值，并明确标注这是估算值，而非实测值。

在排名前排除已知的不良数据代币

RWA 持有者／集中度排名容易受到链上供应量巨大、却没有可验证现实资产支持的代币影响（实际见过：“QGold”、“UGold”——数十亿枚代币，却没有真实储备）。这些代币会以毫无意义的数据占据简单持仓量排名或代币排名的前列。意外发现某个 RWA 代币规模异常大时，应先进行合理性检查，再将其纳入排名，而不是假设链上供应量就意味着其真实可信。

同样，在绘制随时间变化的“发行量”或“流量”图表前，应过滤掉一次性的发行日迁移峰值（例如，将现有余额迁移到新合约时，代币首次上架产生的铸造／销毁）。单次迁移事件可能远超之后每个真实经济周期的数据量，让整张图表都只反映那一天。

TVL／抵押品重复计算

将 RWA 代币纳入 DeFi TVL 背景（RWA 作为抵押品）时，只汇总 is_primary 余额（或等效的“主要账本头寸”标记）——同一抵押品的头寸可能出现在多个协议侧账本条目中，汇总全部条目会导致重复计算。

地理位置是代理指标，而非测量结果

Allium 没有 RWA 持有者或资金流的原生地理数据——区块链具有假名性。实体／发行方司法管辖区标签（通过身份／实体表获取）是关于“事情发生在哪里”的最接近的合理代理指标，但应明确说明这一点，而不是将其呈现为实际测得的地理数据。

时间范围：不要盲信“全年”对应的相对默认值

如果请求是“2024 年所有 RWA 转账”或类似的日历时间段，应使用明确的日期边界（BETWEEN '2024-01-01' AND '2024-12-31'），而不是相对滚动时间范围（CURRENT_DATE - INTERVAL）。RWA 表的聚簇方式未必足够紧密，无法让悄无声息的时间范围错误容易被发现——请明确核实边界。

---

数据来源

每个链数据库都有自己的 rwa 架构（<chain>.rwa.*——例如 ethereum.rwa.transfers、ethereum.rwa.supply_change、ethereum.rwa.supply_daily）。对于涉及多个链的查询，优先使用专用的 rwa 数据库，而非 crosschain.rwa——跨链汇总的命名已迁移至独立的顶级数据库：rwa.core.transfers、rwa.core.supply_daily／supply_latest、rwa.core.balances_daily／balances_latest，以及用于发行方／资产类别／资产类型分类和原生部署与桥接部署元数据的 rwa.registry.catalog／deployments。不要凭记忆或以往会话使用旧的 crosschain.rwa.* 名称——这些命名已被取代。

随着架构演进，表名和列名也会变化，因此不要凭记忆硬编码上述任何名称。先运行 data-matching，确认适用于具体问题的当前表；如果需要在编写 SQL 前核对列名，请直接使用 search_schemas／search_docs。