SNARKeling Treasure Hunt

Description

• The Noir circuit's ALLOWED_TREASURE_HASHES is declared as a 10-element array and paired with MAX_TREASURES = 10 in the Solidity contract. The deployment flow funds the contract with 100 ETH so that each of the ten expected treasures can be redeemed for 10 ETH.

• Entries at index 8 and index 9 of ALLOWED_TREASURE_HASHES are byte-for-byte identical. The circuit therefore admits only 9 distinct treasure_hash public inputs, while the on-chain claimed mapping keys on that hash and enforces uniqueness. Once the nine unique hashes are consumed, no tenth hash exists for claim() to succeed on, so claimsCount stops at 9. Since withdraw() requires claimsCount >= MAX_TREASURES == 10, it becomes permanently unreachable, stranding the tenth 10 ETH reward in the contract.

Risk

Likelihood:

• Occurs on every deployment using the shipped circuit artifacts — the set membership check is_allowed(treasure_hash) and the Solidity MAX_TREASURES constant never align because the circuit only exposes nine distinct hashes.

• No user action is required to trigger the inconsistency; once any nine distinct hashes are claimed, the final reward slot is locked.

Impact:

• 10 ETH (one tenth of the funded reward pool) is permanently stranded inside the contract. withdraw() reverts with HUNT_NOT_OVER because claimsCount caps at 9.

• Only emergencyWithdraw() (owner-only, requires the contract be paused) can recover the stuck funds, breaking the advertised "organizer withdraws after hunt" UX.

• Participants advertised a hunt with ten treasures receive only nine reward opportunities; if both physical "9th" and "10th" treasures share the duplicated secret, the second finder receives nothing.

Proof of Concept

Source-level inspection of circuits/src/main.nr lines 64–65 shows the two literals are textually identical. No runtime PoC is needed — the equality is textual and deterministic at circuit-compilation time.

Economic consequence: after 9 successful claims claim() reverts AllTreasuresClaimed only if claimsCount >= 10; actually it reverts because no further distinct hash can pass is_allowed. Any attempt at the tenth slot fails proof verification. withdraw() checks claimsCount >= MAX_TREASURES and reverts with HUNT_NOT_OVER, leaving 10 ETH permanently stuck pending emergencyWithdraw().

Recommended Mitigation

Replace the duplicated value at index 9 with the intended tenth distinct treasure hash, regenerate the verifier contract and proving key, and regenerate the Foundry fixtures. Alternatively, if only nine treasures were ever intended, align the contract constant and the deployment funding to match so the lifecycle terminates cleanly.

If keeping nine treasures:

And update the deployment script's fixed funding from 100 ether to 90 ether. In both cases, regenerate the circuit artifacts and the Foundry fixtures so the on-chain verifier matches the compiled Noir code.