dex-analysis

DEX 分析

DEX 分析中最常见的错误不是用了错误的表，而是把按跳数或按交易方建模的数据，当作按兑换或按交易建模的数据来处理。聚合前先确认表的粒度。

交易行通常按跳数记录，而不是按兑换记录

多跳路由（A→B→C）可能会为用户体验中的一次兑换产生 2–3 条交易记录。这会同时抬高交易量和行数——一项针对特定链的真实对比发现，仅因跳数扇出，数据就比外部来源高出约 1.3 倍。

• 在信任交易量／计数总值之前，先比较 trades 表中的 COUNT(*) 和 COUNT(DISTINCT transaction_hash)——两者差距较大，就表明存在多跳扇出。
• 如果需要将交易量与外部聚合器（DefiLlama 等）进行比较，可以除以观测到的跳数比率，或先按 transaction_hash 粒度聚合。

AMM 数学问题按 protocol 分组，品牌问题按 project 分组

protocol 和 project 回答的是不同问题，却经常被混淆：

• project 标识品牌产品（例如 “PancakeSwap V2”）。
• protocol 标识底层 AMM 实现（例如 PancakeSwap V2 是 Uniswap V2 的直接分叉，因此两者都显示为 protocol = 'uniswap_v2'）。

如果问题实际关乎 AMM 机制，就使用 protocol——例如无常损失取决于定价曲线，而不是品牌。按 project 对无常损失分析分组，会悄悄将数学机制相同的池（Uniswap V2 及其分叉）拆分到不同分组中，而它们本应归为一组。

不要假设所有“形似兑换”的场所都采用相同机制：

• PumpSwap ≠ Pump.fun 的联合曲线。 它们是同一代币生命周期中的先后阶段，并非同一种产品——联合曲线阶段不存在无常损失的概念（没有外部 LP），只有毕业后的 PumpSwap 池才有。
• V3／集中流动性的无常损失并非按比例缩放的 V2 无常损失——更窄的 tick_lower／tick_upper 范围会通过与范围相关的集中系数，同时放大无常损失和手续费收入。将简单的 V2 无常损失公式应用于 V3 仓位会得出错误结果，而不只是近似值。
• Pendle PT/YT/SY/LP 仓位采用 yields 风格的架构，而不是 dex。 不要在 DEX 交易／流动性表中查找 Pendle。

聚合器交易通常需要联接才能获取基本字段，其手续费会隐藏在转账中

聚合器交易表（0x、1inch 等）可能缺少普通交易表中常见的字段——例如没有 decimals 列或兑换计数列。联接代币元数据表以获取 decimals，并使用 COUNT(*) OVER (PARTITION BY transaction_hash) 推导兑换计数，不要假设一定存在相应列。如果需要精确精度，请确认联接的是实际的带命名空间的 transfers 表（而不是名称相似的不带命名空间的表），并使用原始整数金额列，而不是已调整小数位的金额列。

聚合器的隐式手续费／盈余不会以带标签的列显示——要还原它，需要找到一笔 ERC20 转账：其交易买入／卖出的代币从聚合器入口合约流向一个既非 taker、也非内部池／路由器合约的地址。该笔剩余转账就是手续费；根据对应一侧代币的 decimals 调整小数位。

信任比率前先做合理性检查

• 当记录的 TVL 接近零时，资金效率（交易量／TVL）会趋于无穷大——这通常意味着该特定协议的 TVL 索引不完整，而非效率真的无穷大。为比率设置最低 TVL 阈值，低于阈值时返回 null／标记，而不是直接报告原始除法结果。
• 平均交易规模与中位数差距较大，说明该场所可能并不典型——少数大型机构级交易拉高均值，通常表明 DEX 数据中出现了流动性质押或资金管理协议，而非“普通”的零售兑换场所。如果交易规模分布与问题有关，不要只计算平均值，也要检查中位数。

Perp-DEX（Hyperliquid 风格）特性

• 原始成交表通常是每笔成交的每一方各占一行（买方一行，卖方一行），每行都有 taker/maker 标记——不要假设按一方记录的表会在同一行中提供交易双方的信息。需要同时获取双方信息时，请使用交易级表（一笔交易一行，包含双方对手方地址）。
• 由于成交记录按一方一行，如果已经按用户分组，就不要将 SUM(size) 除以 2——“除以 2”只适用于未分组的全市场总和，因为此时每笔交易会分别计入买方和卖方的记录；筛选或分组到单个用户的成交记录后，该用户的交易量已经只计了一次。
• 归因于“Builder”的交易流（第三方订单流提交方——机器人、聚合器、跟单交易前端）以 taker 订单为主，因为这类交易通常是自动化且主动成交的，而非被动限价单。分析此类交易流时，不要假设它与普通散户交易流的行为相同。
• 在大型 perp 交易表中按用户汇总较长的回溯窗口（例如 12 个月），可能会导致数仓语句超时。开始时先缩短时间窗口（3–6 个月），之后再考虑覆盖完整周期，尤其是针对阈值类问题（“每月交易额达到 $1000+ 的用户”）。

价格数据的特殊情况

Allium 基于 DEX 数据的代币价格通常是短时间间隔（例如 1 分钟）的 VWAP，并经过异常值过滤，以剔除纯套利造成的价格尖峰。连续的亚分钟轮询中若反复出现相同价格，通常意味着该时间窗口内没有新成交（API 返回的是上次缓存的价格），而非数据错误——这种情况在流动性较差的封装资产上最明显，因为它们在链上的交易频率远低于其底层资产在中心化交易所的交易频率。这也是持续存在的 CEX/DEX 价差并不一定意味着错误的原因。

跨 DEX 交易对汇总

如果需要获取不区分交易方向（A→B 和 B→A 视为同一交易对）的交易对数据，请标准化交易对标签，例如 LEAST(token_sold_symbol, token_bought_symbol) || '/' || GREATEST(...)，以便将两个方向的交易汇总在一起，而不是显示为两个独立的交易对。在采用“热门交易对”排名之前，请留意未解析的代币符号可能导致交易对标签为空值。

---

数据源

每条链的数据库都有自己的 dex 架构（<chain>.dex.trades、<chain>.dex.pools、<chain>.dex.liquidity_positions 等）。与稳定币和 RWA 不同，DEX 目前还没有专门的跨链数据库——对于涉及多条链的问题，请使用 crosschain.dex 下的多链组合视图（crosschain.dex.trades、针对 EVM 优化的 crosschain.dex.trades_evm，以及对应的聚合器视图 crosschain.dex.aggregator_trades/aggregator_trades_evm），而不是手动合并各链的表。

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