stablecoin-analysis

稳定币分析

在任何稳定币交易量问题中，最重要的决策是 原始交易量还是调整后交易量——选错了，后续所有数字都会偏差 5–20 倍。编写 SQL 前请先阅读本文。

原始交易量会夸大自然活动——请使用调整后交易量

逐笔转账表中包含 CEX 内部转账、DeFi 协议内部转移、MEV 和刷量交易。对原始转账表执行 SUM(usd_amount) 回答的是“转移了多少价值”，而不是“发生了多少真实经济活动”——两者可能相差一个数量级。进行真实的采用率／使用情况分析时，请使用实体调整后的交易量列（查找 is_adjusted_volume、is_inorganic_sender／is_inorganic_receiver、is_mev_transfer 这类标记，或预聚合的实体调整指标表），不要使用原始 SUM。

如果用户分享了自己信任的图表或数字，而你的原始交易量查询结果高出 5–20 倍，这通常不是查询出了问题，而是原始交易量与调整后交易量之间的差距。不要急着认定 SQL 有误，请先检查是否有调整后交易量的数据源。

信任总量前，务必检查虚假数据／错误数据代币

稳定币交易量表可能会把非稳定币代币错误归入目录（实际案例：Arbitrum 上一个名为“xy”的代币，currency 为 NULL，为 $16.65T 的头条总量贡献了 $5.4T 的虚假交易量——单个错误代币约占报告总量的 1/3）。引用交易量总数前：

• 按代币拆分数据，检查是否存在交易量占比相对于其市场表现明显不合理、currency 为 NULL／缺失，或某一天的交易量异常飙升、远超其典型日常模式的代币。
• 如果用户要求全面审查，就实际审计每个贡献超过 0.1% 交易量的代币，而不只是你碰巧注意到的那个——实际审计中，一旦有人不再只盯着第一个异常代币，往往会发现多个错误代币（一次审查中曾发现 5 个）。

各链特有的重复计数机制

• XRPL（RLUSD 及其他由 XRPL 发行的稳定币）：信任线／涟漪机制会为每笔真实转账生成两条转账记录（发送方→发行方，然后发行方→接收方）。简单排除发行方地址无法解决问题——金库／运营钱包位于发行方之后，仍会导致交易量虚高。按 transaction_hash 去重（每个哈希取 MAX(usd_amount)），并根据行为模式识别金库钱包（交易量极高且恰好只有一个交易对手），不要使用固定地址排除列表。
• Aptos：某些资产（USDT）有两个对应同一底层代币的有效地址——一个是旧版 Coin 模块地址，另一个是较新的 Fungible Asset 地址。供应量／转账表会以其中一个地址为键（通常是较新的 FA 地址）；查询旧版地址会静默返回零行，而不会报错。
• 消息协议表中的跨链代币代码：按代币符号筛选桥接交易量时，请使用精确匹配，不要使用 LIKE／模糊匹配——带封装形式或衍生形式的代币代码（例如 PT-USDG-28MAY2026、USDG0）会与真实符号包含相同子串，使用模糊筛选会悄然抬高计数。

地址规则因链而异——不要将同一规则用于所有链

在联表／筛选前，将 EVM 地址转换为小写。不要将 Solana、Tron 或 Aptos 地址转换为小写——这些地址区分大小写，转成小写会导致联表悄然失败（返回零行，而不是报错）。

原生部署与桥接部署在同一条链上属于不同的供应量

同一种稳定币在同一条链上可能既有原生发行版本，也有桥接表示形式（例如 Polygon 上的原生 USDC 与桥接 USDC.e）。它们的地址和供应量各不相同——不要假设“Polygon 上的 USDC”对应一个规范地址，并且要明确查询针对的是哪种部署。

持有者和地理位置需要使用正确的表，而且单独使用任何一张表都不完整

• “使用稳定币的钱包”需要计算 交易者 ∪ 持有者，不能只看其中一方——将全部余额转出的钱包是交易者，但在期末不是持有者；从未进行交易的休眠持有者则恰好相反。不要只用其中一方来回答“使用情况”问题。
• 余额／持有者表通常仅涵盖 EVM——Solana 或 Tron 往往没有相应的 balances_daily 风格表；要统计这些链上的持有者数量，需要改用基于转账的近似方法，并明确说明这一限制，不要悄悄将其忽略。
• 要按地理位置拆分，应使用实际的地址地理位置表（根据交易所的存款／提款模式推断），而不是 UTC 小时段启发式方法——“00:00-08:00 UTC 之间的活动 = 亚洲”是个很粗略的代理指标，实际的地理位置表可能会推翻这一结论。请注意，地理位置表通常只涵盖 EVM／Tron／Solana，且所有 EVM 链都合并到同一个类别中——联接前，先将具体链（ethereum、polygon、base 等）映射到该类别，否则联接会悄悄返回空结果。

路由／DEX 交易量不等于流通量增长

当稳定币发行方的代币经过 DEX／求解器活动路由时，这部分交易量并不等同于流通量增长。请区分：

• 纯粹过手——在同一笔交易／短时间窗口内铸造并销毁，对净流通量的影响 ≈ $0；
• 库存模式——做市商持有运营库存，流通量 = 持有的库存；
• 真正的采用——终端用户持续持有。

原始交易／路由交易量会严重高估其中属于 #3 的部分。如果问题涉及采用情况或流通量增长，不要在未确认交易量实际反映上述哪一种情况之前，就直接用交易量数字作答。

---

数据源

每个链数据库都有自己的 stablecoins 架构（<chain>.stablecoins.*——例如 ethereum.stablecoins.transfers、solana.stablecoins.supply_change）。对于跨越多个链的内容，优先使用专用的 stablecoins 数据库，而不是 crosschain.stablecoins——跨链汇总所用的命名已迁移到自己的顶级数据库（用于发行方／锚定机制／分类元数据的 stablecoins.core.transfers、stablecoins.core.balances_daily、stablecoins.registry.catalog，以及用于上述调整后交易量／有机活动分类的 stablecoins.intelligence.enriched_transfers）。不要凭记忆或先前会话使用旧的 crosschain.stablecoin.* 名称——该命名已被取代。

对于单条链，旧的 <chain>.assets.stablecoin_transfers 表正逐步淘汰，改用 <chain>.stablecoins.transfers——尽可能避免使用 assets 架构中的版本。

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