bridge-analysis

跨链桥分析

跨链桥转账表在设计上是不对称的——它们不一定会记录转账的两端。在汇总之前，先弄清楚方向性模型。

跨链桥转账表记录的是净单向流量，不一定记录转账的两端

具体的覆盖形式取决于跨链桥类型：

• Ethereum 上的标准跨链桥通常同时包含流入和流出记录。
• 应用级跨链桥以及非 Ethereum 链上的跨链桥活动，通常只记录发起转账的链上的流出记录。

这是为了防止重复计数而有意采用的设计，并非数据覆盖缺失——但这意味着，SUM(usd_amount) 的行为会因你查询的链与跨链桥类型组合而异。跨链汇总前，先检查特定跨链桥和链上实际存在哪些 direction 值，不要假设表中每笔转账都有对应的流入和流出记录。

筛选 ≥2 条目标链会引入单链筛选不会出现的重复计数陷阱

如果将跨链桥流量筛选到一个目标链列表中（例如“ethereum、arbitrum、base 之间的流量”），并且某笔转账的两端都在该列表中，那么这笔转账可能会满足两次 WHERE 子句——一次作为源链的流出记录，一次作为目标链的流入记录，从而抬高 SUM(usd_amount)。

• 如果转账的源链和目标链都在目标集合中，应将其标记为特殊情况，而不是与其他记录一并求和。
• 如果需要一个跨多条链的单一汇总数值，优先使用 net_flow_usd（流入 − 流出）作为安全的跨链汇总指标——无论是否会发生重复计数，该指标都能保持准确，因为同一笔转账会对两端产生对称贡献，最终相互抵消。

正确隔离单个协议

要从统一的／跨链转账表中提取特定跨链桥协议的交易量，应筛选协议标识字段（通常名为 protocol），而不是在两者都存在时使用泛化的 bridge 字段——通常 protocol 是更细粒度、更可靠的筛选条件，例如专门隔离 Circle 的 CCTP。匹配时忽略大小写。

报告单个协议的交易量时，应将其表示为有意义的分母所占的份额（例如，协议交易量 ÷ 该资产的跨链总交易量，或 ÷ 所有跨链桥交易量），而不应只给出绝对数值——利益相关者通常会据此判断协议的采用情况，而且与原始美元金额相比，这是一个随时间变化更稳定的指标。

跨链桥身份可从链上数据推导；集成方／聚合器归属则不行

每笔跨链桥转账使用的协议（合约地址 + 事件签名 → 注册表映射）仅凭链上数据即可确定。是谁路由了这笔交易——即哪个前端或聚合器发起了交易（跨链桥自有界面、钱包内置的跨链桥功能，还是第三方聚合器）——通常不是标准化的链上字段；统一转账表有时还会有意排除专用的“聚合器”列，以避免另一种重复计数。不要指望仅靠 SQL 就能回答“是谁路由了这笔转账”——这需要链下 API／分析数据、在合约层面添加集成方参数的改动，或基于维护中的聚合器合约注册表进行启发式 tx.to／调用栈追踪。任何一种方式都应标记为比普通查询更繁重的工作。

在没有直接关联键时追踪特定转账

有些环节不会记录在按链划分的桥接转账表中，最常见的是非 EVM 原生环节（例如，从 Bitcoin 发起并桥接到 EVM 链的转账）。在这种情况下，桥接事件只会显示为目标链上的铸币记录，没有指向源链原始交易的上游链接。

在没有直接关联键的情况下追踪此类锁定并铸币流程，一般采用以下模式：

1. 从相关原始表中提取源链上的金额和时间戳。
2. 在源链时间戳之后的短时间窗口内，搜索目标链上的封装代币转账，查找铸币记录（from_address = 零地址／销毁地址）。
3. 在桥接费容差范围内按金额匹配（通常为几个基点）——由于手续费的存在，按精确金额匹配通常会失败。

如果两侧都没有解码后的桥接事件将它们关联起来（例如，封装资产在没有任何已捕获桥接交易的情况下独立铸造），不要强行进行转账级关联；应改为构建实体映射（实体、链、地址、类型、置信度），并将两侧相关但独立的活动作为流量代理进行追踪，将其呈现为相关性证据，而非匹配后的追踪结果。

手续费／Gas 归属

由桥接触发的铸币或中继操作所产生的目标链 Gas 费通常由桥接的中继地址支付，而不是由接收方支付。在还原桥接经济情况或拆解特定用户转账的费用时，不要将这笔 Gas 费归到最终用户身上。

各数据界面的覆盖缺口

如果使用 Allium 的 Wallet API，而非原始 SQL 表，请注意，该 API 中呈现的跨链／桥接活动类型通常仅涵盖 EVM。Solana 和 Bitcoin 侧的桥接活动可能不会出现在增强活动流中，需要像上文所述那样直接追踪原始表。

---

数据源

桥接数据存放在两个地方：每个链数据库都有自己的 bridges 架构 （<chain>.bridges.*），此外还有一个共享的 crosschain.bridges 架构，用于跨链汇总和比较。凡是涉及多条链的查询，都应优先使用 crosschain.bridges，而不是手动合并各链的表。

在这两个架构中，活动分为三个不同类别——不要将它们混为一谈：

1. 桥接 — 直接转移价值的规范桥接和应用级桥接（锁定并铸币、销毁并铸币、流动性池桥接）。
2. 消息传递协议 — 通用消息传递基础设施（例如 LayerZero、Wormhole、CCIP），可以承载价值转移，但其本身不是桥接；一条消息不保证一定伴随转账，反之亦然。
3. 聚合器 — 为给定转账从多个底层桥接／消息传递协议中进行选择的路由器；聚合器层与其路由所经的底层桥接属于两种不同的归因，针对其中一方的查询会漏掉另一方，且不会发出提示。

每个类别都拆分为独立的入站和出站表（例如，记录源链环节的出站转账表，以及记录目标链环节的入站转账表），而不是使用带方向列的单张表。这体现了上文所述的非对称记录设计，并在表级别明确呈现。应通过消息／转账标识符关联两侧，而不是假设单张表中包含两个环节。

尽可能避免使用扁平的 <db>.bridges.transfers 表——该表已弃用。 它早于上述桥接／消息传递协议／聚合器拆分设计，且不包含相应的归因信息；查询该表无法区分记录所属的类别或方向。

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