这次 BNCB 抢跑没有买入，主要原因是脚本支持的协议、币对和触发条件，没有覆盖当时已经能够成交的路线。链上交易证实：在服务停止前约三分钟，另一位买家已经通过 PancakeSwap Infinity 的原生 BNB/BNCB 池取得 BNCB，再经 Flap Portal 买到 7Stock。
初次排查只回查了五个 Pancake V2/V3 的 BNCB/USDT 候选池，却把其中一个 V3 池在停机后的开池时间，概括成所有购买路线的出现时间。这一结论不完整，需要纠正。本文以成功交易的完整调用树、代币转账、池事件、历史状态和运行日志，重建实际发生的过程。以下时间均为北京时间，日期为 2026 年 9 月 14 日。
一、这笔交易证明了什么
复盘的关键样本是 0x138d56…cbced。它在 20:25:28，区块 121837345 成功执行，交易索引为 1，即该区块的第二笔交易。
完整调用与转账记录显示，买入路线为：
原生 BNB → PancakeSwap Infinity CL 的 BNB/BNCB 池 → BNCB → Flap Portal → 7Stock → 买家。
Infinity 兑换输出了 267.157941288819449243 BNCB。后续经 Portal 买入并最终转给买家的目标代币为 291,978,224.374756696548735460 7Stock。这笔交易没有 USDT 或 WBNB 的转账，也没有通过 Pancake V2/V3 完成兑换。
因此，能够确定的是：停机前已经有一条成功购买目标代币的路线，而现有脚本没有覆盖它。 这并不证明相同时间、任意买入数量都能以相同价格成交，也不能仅凭一次早期买入就判断最终盈利。
样本中的“V4”具体是哪一种
样本使用的是 PancakeSwap Infinity CL。把它笼统称作“V4 池”容易与 Uniswap V4 混淆；这里依据管理器地址、事件和 PoolKey 识别到的是 Pancake 的 Infinity 协议。
实际调用的 CLPoolManager 为 0xa0ffb9c1ce1fe56963b0321b32e7a0302114058b，与 PancakeSwap 官方部署地址一致。两个关键池的身份如下：
| 币对 | Infinity PoolId |
|---|---|
| BNCB/USDT | 0xb2d5d017ce59fc823a4af4aa240f378aa4d180d8604d0f831322135aed1f75c0 |
| 原生 BNB/BNCB，样本实际使用 | 0xc91ace669ee5066ed56312a76a3925b60da5745e1e6fe634f1f6253d7b4b758a |
PoolId 不是一个独立的池合约地址。Infinity 用管理器中的 PoolKey 区分币对、hooks、管理器、费率和参数，并由它计算 PoolId。本次调查对相关 PoolKey 重新计算了身份，结果与链上 PoolId 一致。官方 PoolManager 架构
二、完整时间线：先有单边池，再通过卖单获得 BNCB
| 时间 | 已核实的事实 | 对脚本的意义 |
|---|---|---|
| 19:23:42 | 脚本完成准备，监听五个 V2/V3 BNCB/USDT 候选池 | 五条买单已预签，等待匹配事件 |
| 19:41:37 | Infinity BNCB/USDT 池初始化，并加入 10,000 USDT、0 BNCB | Infinity 已出现，但不在订阅范围内 |
| 19:56:11 | Infinity 原生 BNB/BNCB 池初始化，并加入 14 BNB、0 BNCB | 样本后来使用的池已经存在 |
| 20:25:27 | 一笔卖单把 BNCB 输入五个 Infinity 池；其中 USDT 池收到 127.8 BNCB，BNB 池收到 318.2 BNCB | 存量池通过 Swap 获得 BNCB，没有新增 LP 仓位事件 |
| 20:25:28 | 样本买家通过 Infinity BNB/BNCB，再经 Portal 买到 7Stock | 出现直接的成功成交证据 |
| 20:28:27 | 服务按操作指令停止 | 比样本成功买入晚约 179 秒 |
| 20:30:04 | 原有候选 V3 0.05% BNCB/USDT 池创建、初始化，并 Mint 54,541 BNCB、0 USDT | 这一次才符合原脚本的事件条件，但已经停机 |
Infinity 两个池的初始注资分别由 USDT 池初始化交易和 BNB 池初始化交易核验。其中原生 14 BNB 的流向进一步通过调用追踪确认，并非只根据价格区间推测。
关键变化发生在 20:25:27 的卖出交易：卖方把 BNCB 换成这些池里预先放入的报价资产。它改变了池内资产分布，让后续买家能够反向换出 BNCB。紧接着的成功样本证实了 BNB/BNCB 路线确实可以使用。
这解释了“早就看到池子”和“后来才有人能够买入”为什么需要分别验证。初始化、单边注资、获得可供买出的 BNCB、特定数量的整条路线成功成交，是不同事实。不能把最早初始化时间直接当成可买时间，也不能把最后出现的 V3 池当成全市场首次可买的时间。
三、脚本为什么没有提交买单
1. 自动选择的范围只有五个 V2/V3 候选池
当时的实现覆盖 Pancake V2 BNCB/USDT，以及 Pancake V3 的 0.01%、0.05%、0.25%、1% 四档 BNCB/USDT 池。所谓“自动识别”，是在这五个候选中计算并验证地址、预签路线、选择第一个符合条件的事件。
这符合最初明确列出的 V2/V3 实施范围，但不足以覆盖“尽早通过任意可用路线买到目标代币”的更广目标。交付时没有把这一协议边界说明得足够清楚。
实际成功路线同时超出了两个边界：它使用 Infinity，而且第一段是 原生 BNB/BNCB。脚本的 WSS 订阅和 HTTP 补扫都只查询五个候选地址，因此不会把这笔 Infinity Swap 当成候选触发。多条连接都正常，也不会改变这一点。
执行合约也只有 V2/V3 的兑换分支。即使临时发现了 Infinity 事件，现有预签买单仍不能自动切换成样本路线。需要同时补齐发现、校验和执行能力。
2. “必须出现新增 BNCB 的 Mint”漏掉了通过 Swap 形成的机会
原触发逻辑可简化为：
事件地址属于五个候选池并且事件是该版本的 Mint并且本次 Mint 的 BNCB 数量大于 0才锁定路线并提交对应预签买单本案的重要转折却是 卖单把 BNCB 输入已经存在的单边池。这一步发生的是 Swap，并不要求新增 LP 仓位。只把 Infinity 加仓事件补进监听，仍然不能解决这个问题。
此外，Infinity CL 的仓位事件是管理器上的 ModifyLiquidity，包含 PoolId、区间和有符号的流动性增量，没有 V3 Mint 的 amount0/amount1 字段。把管理器地址塞进原候选地址列表，再沿用 V3 解码方式也不可行。Infinity CL 官方事件接口
3. Gas 和预签无法补上未触发的路线
这次买单配置为 1.5 BNB 本金、0.05 BNB 小费、25 Gwei Gas。日志和持久化状态显示，脚本一直处于准备完成的状态，未选择路线、未记录触发事件，也没有买单提交记录。
因此，此次没有买入不能归因为“买单已经发送，但 Gas 不够高，竞争失败”。流程没有走到发送这一步。候选地址预计算、多路线预签、同 nonce 和单次路线锁定，可以减少受支持路线的处理时间，却无法弥补协议或触发语义缺失。
四、需要纠正的三个排查判断
把局部 V3 结论当成了全局结论
原先回查的 V3 0.05% 池为 0xb754f10cebf50b8862444cf4d6c1cc31a3b71c18。历史 getCode 和工厂 getPool 均表明，它在停机前尚未部署，直到 区块 121837957、20:30:04 才在 同一笔交易中创建、初始化并加入 BNCB。
这个具体时间没有算错。错误在于，把“这个 V3 池停机后才出现”进一步解释成“停机前不存在可用买入路线”。Infinity 的成功交易已经否定了后一种说法。
只看到了样本里的 Mint，没有读完整交易
样本中还有一个 BNCB/7Stock 地址 0xd141593d1f122397aeb883527ad405c34d3357e5 发出的 Mint、Sync 和 Swap 日志。初次调查只抓住了这条不属于候选币对的 Mint，因而遗漏了整笔交易最关键的 Infinity 兑换与 Portal 买入。
进一步追踪发现，调用树中没有向这个地址转入两种代币；目标代币实际从 Portal 送往买家使用的中间合约，再到买家。样本前一个区块，Portal 对目标代币记录的储备和流通量为 0，外盘池字段也为零地址；样本区块结束后外盘池字段仍为零地址。这支持“早期 Portal 内盘购买”的解释，而不是已经迁移到外盘的判断。
由于尚未拿到该辅助地址的已验证实现源码，本文不把它的具体合约类型写死，也不把兼容 Mint 日志中的数量直接描述为实际 LP 入金。事件名相同，不足以证明资金行为相同。
把“本次没有新增 BNCB”误当成“整个池无法买”
运行期间，五个候选池的链上回查发现九次 Mint，全部是本次 BNCB 数量为 0、USDT 数量大于 0。它们不满足原触发规则，可以解释为什么按该规则回放不会选中路线，却不能单凭这一点证明池内没有历史仓位、或所有方向都无法成交。
同样，V3 的 liquidity() 只描述当前价格区间的活跃流动性。它为零时，不能未经交易方向、其他 tick 和实际报价检查，就推导整条兑换路线必然失败。Pancake V3 官方池状态接口
五、WSS 和样本交易成本分别说明什么
连接日志确实存在问题：WalletConnect 反复连接失败，两条 QuickNode 连接也多次关闭重连。按已记录的连接状态重建，在五路首次全部订阅后，没有出现五路同时断开的记录；两个 dRPC 连接没有断开记录，HTTP 补扫游标也持续推进。
这些证据不能保证不存在静默卡顿、短时延迟或未记录的丢包。但它们不足以支持“因为全部 WSS 同时掉线，所以漏掉了这笔买入机会”的说法。本次已确认的漏覆盖，在协议过滤和触发条件层面就会发生。 网络稳定性仍需单独改进，不能替代策略覆盖。
另一方面，样本确实买得早，但成本并不低。根据交易回执和原生币调用流，费用拆分如下：
| 项目 | BNB |
|---|---|
| 交易最初携带的金额 | 8 |
| 返还买家的金额 | 5.283570722014183973 |
| 净支付，不含 Gas | 2.716429277985816027 |
| 其中 Infinity 实际净兑换输入 | 2.689533938599817849 |
| 其余两笔原生币支付合计 | 0.026895339385998178 |
| Gas 费用 | 3.312404708 |
Gas 回执为 1,241,531 gas × 2,668 Gwei。8 BNB 是交易携带值，不能直接当作购买成本；两笔其余支付也没有仅凭金额就认定为特定类型的小费。如此高的 Gas 是否对该笔排序起决定作用，单靠这笔回执无法确认，更不能直接照搬为后续配置。本文没有核算该买家之后的卖出与盈亏。
六、后续应如何验收改进
首先需要把策略目标写清楚：如果目标仍是“指定 V2/V3 BNCB/USDT 池新增 BNCB 时买入”，现在的结果可以由原规则解释；如果目标是“尽早找到能够买到 7Stock 的路线”，验收就必须覆盖已经存在的池、不同报价资产，以及通过 Swap 改变可成交状态的情况。
后续实现应至少满足以下条件：
- 发现范围与执行范围可见。 能识别相关协议、币对和池身份；遇到尚不支持执行的池，明确记录“已发现但路线未支持”，而不是保持沉默。
- 新协议贯穿整条路线。 Infinity 需要管理器事件解析、PoolKey/PoolId 校验、原生币结算和执行适配；继续保留同 nonce、首条路线锁定与提交前持久化约束。
- 用状态变化驱动可成交检查。 初始化、仓位变更、Swap 和启动时已有状态都应纳入评估。发现一个事件不等于立即下单，应检查给定输入规模和最低到账要求下的整条路线。
- 用这次历史过程做分叉回放。 分别验证单边池刚创建、卖单输入 BNCB 后、样本买入后等状态；核验实际本金、滑点边界、Portal 输出，以及重启和重复事件是否造成跨路线提交。
- 保留能解释“不下单”的日志。 记录事件区块、接收时间、协议与 PoolId、忽略原因、报价或模拟结果，以及各节点最新响应和补扫进度。
这些是复盘提出的后续验收要求，本次调查没有部署或启动新交易策略，服务保持停止。
证据范围与复核方法
本文涉及的 BNCB 为 0x4902c5ebc598265ed2212b559b042de8a5eeec3f，目标 7Stock 为 0xed963d4551429b959fc328360bd3d29e2a327777，USDT 为 0x55d398326f99059ff775485246999027b3197955；用地址识别代币，避免仅凭名称混淆。
关键四笔 Infinity 交易的区块哈希、回执状态和事件摘要，由 dRPC、QuickNode 与公共 BNB RPC 交叉核对一致。样本的 30 条日志另做了完整一致性比较，并读取 debug_traceTransaction 调用树。链上证据来自 JSON-RPC；文中的 BscScan 链接用于定位原始交易，不代表只依赖浏览器页面摘要。
Infinity 相关历史扫描覆盖区块 121825868 至 121837743，约为 19:00 至停机时刻；文中对首笔相关 Swap 的判断限于该已核验范围。服务启动、停止、连接异常和提交状态则来自运行日志与持久化状态。单个样本可以证明一条路线已成功成交，不能证明它是全市场绝对第一笔，也不能替代本脚本在同一历史状态、使用自身本金与参数的完整回放。