用途：这是一份用于 Allium 平台分析 DEX/AMM 交易、流动性与定价数据的方法论手册，面向用 SQL 处理链上 DEX 数据的分析场景，覆盖 Uniswap、PancakeSwap、PumpSwap/Pump.fun、Orca、Pendle、聚合器等。
主要能力与要点：
- 统计口径。最常见的错误是把逐跳（per-hop）或逐边（per-side）数据当作逐笔交易。多跳路径 A→B→C 可能对一次用户兑换产生 2-3 行记录，导致交易量与行数虚高，资料提及某链上曾出现约 1.3 倍虚高。可用 COUNT(*) 与 COUNT(DISTINCT transaction_hash) 对比排查；与外部聚合器（如 DefiLlama）对比时，按观察到的跳数比例折算，或先按 transaction_hash 聚合。
- protocol 与 project 区分。project 指品牌产品（如 PancakeSwap V2），protocol 指底层 AMM 实现（如 Uniswap V2 的直系分叉也记为 uniswap_v2）。涉及 AMM 机制（如无常损失）应按 protocol 分组，否则会把同机制资金池拆开。
- 机制差异。PumpSwap 与 Pump.fun 的 bonding curve 是同一代币生命周期的先后阶段而非同一产品；bonding curve 阶段无外部 LP，因而无无常损失概念。V3/集中流动性的无常损失不等于 V2 公式缩放，tick_lower/tick_upper 越窄会按范围相关因子放大无常损失和手续费收益。Pendle 的 PT/YT/SY/LP 属收益类 schema，不在 dex 表中查找。
- 聚合器。0x、1inch 等的交易表可能缺少 decimals、swap 计数等字段，需 join 代币元数据并用 COUNT(*) OVER (PARTITION BY transaction_hash) 推导；注意 join 到正确带命名空间的 transfers 表及原始整数金额列。聚合器的隐式费用/盈余没有现成列，需通过入口合约流向非 taker、非内部池/路由地址的 ERC20 转账腿重建。
- 比率校验。成交量/TVL 在 TVL 接近零时会趋于无穷，通常意味该协议 TVL 索引不完整，应设最小 TVL 阈值并返回 null/标记。均值与中位数差距大提示非典型场所。
- 永续 DEX（Hyperliquid 类）。fills 表通常每边每笔一行并带 taker/maker 标记，若需双方地址用 trade 级表。按用户分组后不要对 SUM(size) 再除以 2。builder 归因流量偏向 taker 单。长回看窗口（如 12 个月）按用户聚合大数据表可能触发超时，可先用 3-6 个月窗口。
- 价格数据。DEX 派生价格通常是短周期（如 1 分钟）VWAP 并做异常值过滤；连续相同价格多表示该窗口无新成交，而非数据 bug，薄流动性封装资产尤明显。
- 跨 DEX 配对汇总。可用 LEAST/GREATEST 归一化配对标签，使 A→B 与 B→A 合并；注意未解析符号导致的 null 标签。
使用方式：各链数据库有独立 dex schema（如 <chain>.dex.trades、pools、liquidity_positions）；跨链场景使用 crosschain.dex 下的多链组合视图（crosschain.dex.trades、crosschain.dex.trades_evm 及聚合器对应视图），而非手工 union。表名列名随 schema 演进，不要凭记忆硬编码，先运行 data-matching 确认当前表，并用 search_schemas/search_docs 或 browse_schemas 核对列名后再写 SQL。
限制：资料未提供具体收费、价格、平台可用性或性能指标；schema 和列名会变化，需实时核对。