1. 最初目标与实际结果#

最初目标是配置私钥和费用上限后，脚本长期监控开盘，并自动把当前持仓兑换成累计 4 张 TMF Pass，无需人工守候。

这个项目实际包含两条链和一个官网签发环节：持有钱包在 ApeChain 向 Deng Desk 交入 NFT，官网汇总档案积分并签发 voucher，主钱包再在 Robinhood Chain 调用 dengClaim 领取。链上 NFT 交入成功，并不等于 Pass 已经领取，也不能原子地锁定另一条链的库存。

实际领取交易发生在 RH 区块 80098628，交易位置为 6，调用 dengClaim，累计 allowance 为 4，转入原生币 value 为 0。链上本身只能证明钱包成功领取；结合用户“我手动领取了”的说明、脚本没有 RH 交易记录以及恢复服务的提前退出日志，才能确认这次领取应归因于用户操作。

此前记录中的“01:09 确认到账”是复查时间，不能当作实际领取时间。项目应评价为“兑换数量达标，自动化验收未达标”。

2. 关键过程和重要决策#

最先厘清了项目机制和钱包角色。当前 16 个 Deng 分布在三个持有钱包，主钱包负责官网档案登录及 RH 领取。主钱包没有持有本次需要交入的 Deng，因此不需要为这些持有钱包的交易支付 APE；持有钱包分别支付自己的 APE gas，主钱包支付 RH ETH gas。

准备阶段核对了官网接口路径、方法、参数、快照证明、关联证明、NFT 归属、nonce 和两链余额。所有当前持仓的证明请求均返回成功，16 个 Deng 每个 1.29 积分，15 个只有 19.35 积分，无法达到需要的 20 积分，所以交入 16 个符合本次目标。虽然官网还有未计分快照地址的分支，脚本没有完整支持，该缺口没有影响这三个当前钱包。

针对持续运行，加入临时接口错误退避、429 的 Retry-After、分阶段登录恢复、RPC 重连，以及同 nonce 的交易恢复和提价。登录调试中，普通验证码任务的 token 被官网拒绝，M1 及相应浏览器上下文通过验证；这也说明身份验证需要真实联调，不能只对照参数名称。

费用决策是在用户授权后把 Ape 总上限设为 2 APE，RH 总上限维持 0.005 ETH。上限是保护条件，不是计划消费金额。预签交易保留开盘报价刷新能力及有限提价空间，没有取消预算检查。

10 月 4 日约 16:46 服务部署并登录成功；19:56 三个钱包提前完成授权，交入交易提前签好。服务使用单实例锁、持久交易状态和受限文件权限，异常时没有配置无限自动重启。

官网公布时间是 10 月 5 日 01:00，但历史 open 状态证明链上实际在 01:01:02 才开放。脚本以链上状态为准，没有仅按倒计时盲发。开放所在区块的 Desk 交易前后，open 从 false 变为 true；本文不根据未核实的函数名称猜测管理操作细节。

区块时间只有秒级精度，服务日志是本机记录的毫秒时间；两者不能直接相减来计算网络提交延迟，也不能把日志看到回执的时间当作交易进入区块的时间。

异常后修复了空 POST 的请求头，加入真实本地 HTTP 接收端的回归测试，本机和服务器完整 234 项测试通过。恢复使用 claim-only 保留已有记录；检测到用户已完成领取后，服务正常结束，随后取消开机自启并暂停自动监控。12:59 的补充复查又在真实登录会话中验证了修复后的业务响应，并确认脚本编码与手动成功交易一致；但账户已经领取完，没有取得新 voucher 或发送自动领取交易，因此仍不能宣布整个自动流程已经实测成功。

3. 做得好的地方及成功原因#

首先，机制分析基本正确。识别了持有钱包、主档案、积分、官网凭证和两链 gas 的关系。三笔交入的链上 calldata 解码与既定方案一致，证明这部分准备没有停留在网页文案层面。

其次，提前授权和预签发挥了作用。实际前三笔授权都在开盘前数小时成功，等待阶段不用再处理授权或首次 nonce 分配。在开盘窗口内，只有一个地址先于我们的交入，之后三笔连续排第 2、3、4，是交入阶段取得的实际结果。没有对照实验，不能准确量化每项优化贡献了多少秒，但准备完成与较早进入链上是有证据的。

第三，费用和恢复边界有用。本次没有因为补 gas 就扩大任意消费范围；交易状态保留了六笔已完成操作，恢复只检查领取，没有重新交入。成功标准使用回执、铸造事件和累计领取数，而不是“RPC 接收”日志。

第四，人工兜底确实保护了结果。用户在自动领取中断后手动完成领取，修复后的进程又识别了已有成果。这里的成功原因包含人工介入，不能将它全部计入脚本可靠性。

WSS 第三个节点持续出错时，HTTP 轮询仍可工作，交入结果说明整个监控没有因此失效。不过日志没有记录开盘信号具体来自 WSS 还是 HTTP，不能确定是哪条通道抢先发现开放。

4. 问题、根因和经验教训#

1
fetch("/backoffice/api/dengs/voucher", {
2
  method: "POST",
3
  credentials: "include",
4
  cache: "no-store"
5
})

5. 投入与产出是否合理#

链上可直接计算的执行成本如下，按回执 gasUsed × effectiveGasPrice 计算，使用原生币计价：

三笔交入的实际 gas 分别为 459274、260246、503214，均低于配置上限；手动领取实际 gas 为 99319。没有因为 gas 不足出现链上失败，本次 gas 配置在实际交易中够用。2 APE 总上限约使用了 6.92%，0.005 ETH 上限也远高于手动领取实际费用。用户转入钱包的剩余 gas 余额属于资产，不应记为已经消耗的成本。

但这不是完整项目成本。还缺少 16 个 Deng 的取得成本与交入后的机会成本、验证码实际扣费总账、节点及服务器费用、补币及跨链费用、人工和开发工时，以及 4 张 Pass 的可兑现价值和后续收益。不能仅凭 gas 很低判断整个项目盈利，也不能把 16 个交入 NFT 的经济成本当作零。

只看已确认的执行费用和拿到 4 张的数量目标，投入受控、结果可接受。按无人值守的工程目标衡量，投入大量检查后仍由人工完成最后一步，测试资源分配并不理想：内部防重发测试较充分，最后的真实 HTTP 报文与签发链路没有得到同等验证。更合理的下一次投入，是补齐高风险外部边界，并把 nonce、预算、恢复框架复用于其他项目，减少一次性适配成本。

6. 同类成熟工程值得借鉴的做法#

没有证据可以识别本次领先地址的私有脚本，也没有经核实的同类收益排行榜。因此这里借鉴的是公开项目的工程做法，而不是把某个“抢购神器”当作经过验证的赢家。

Flashbots 的公开 searcher 示例把发现、评估和提交分为不同阶段；其排障文档要求先确认交易能执行，再分析出价、冲突和到达时间，保存模拟与提交记录，并用各阶段时间定位延迟。这个顺序适合本项目：先确保真实领取能完成，再谈降低提交延迟。公开示例、排障方法

ERC-4337 bundler 的文档将模拟失败原因、执行成功率、包含延迟、gas 估计误差与运行状态作为持续监控对象，并提供兼容性测试体系。我们可以学习“兼容性证据”和“运行指标”分开记录：单测通过、真实客户端报文通过、真实接口联调通过、链上业务完成，各有独立状态。监控指标、兼容性测试

这些来源不证明 Flashbots 的 Ethereum 提交通道适用于 ApeChain 或 RH，也不证明 TMF 领先参与者用了这些工具。借鉴的是验证和测量方法；是否采用特定通道，要单独核验目标链支持情况。

7. 更早参与者是怎样完成的#

“更早买入”在这里应拆为更早交入 Deng、和更早凭 voucher 领取 Pass。这次讨论的是兑换入口，所分析交易 value 为 0，不是二级市场付款买入。

8. 改进方向、优先级和下一步行动#

真实 voucher 联调不能通过强行再次领取已经领取完的 4 张来完成。当前账户的目标已经达成，应保持服务停止，使用测试档案、项目测试环境或下一次有明确授权的有效领取窗口验收。

下一次上线前，应先列出完整流程和无法提前验证的条件，使用部署版本做真实 HTTP 报文测试及登录接口联调，再验证有效 voucher、合约模拟与故障恢复。开盘前冻结版本、预热两链和官网会话、确认余额与 nonce；运行中分别展示“交入完成”和“领取完成”，以最终 NFT 铸造及累计领取数作为成功判据。

目前空 POST 修复已部署且测试通过，真实登录后的业务响应和成功交易的 calldata 编码也已核对；但仍未完成新 voucher 签发到自动领取的真实验收，最新修复尚未形成新的 Git 提交。服务已停止、开机自启已取消，自动监控暂停。本次补充复查有两次验证码服务调用，其实际扣费尚未查账；没有启动服务或发送新链上交易。

这次留下的可复用经验是：内部逻辑正确、参数一致、费用充足和交入靠前，都不能代替最后一个外部依赖的验证。把最终领取链路跑通、把失败立即暴露、把每段耗时测出来，才能在下一次项目中同时提高可靠性与速度。