Duplicate hash in Noir circuit makes treasure 9 permanently unclaimable
Duplicate treasure hash in circuit — treasure 9 can never be claimed, 10 ETH locked forever
Description
The ALLOWED_TREASURE_HASHES array in main.nr has 10 entries, but entries at index 8 and 9 are identical:
Both are the hash for treasure secret 10. The correct hash for treasure 9 should be -4417726114039171734934559783368726413190541565291523767661452385022043124552 (as listed in Prover.toml.example at index 8).
The test file confirms this — look at tests.nr line 30:
So when someone finds treasure 9 and tries to generate a proof with secret=9, the circuit rejects it because pedersen_hash([9]) doesn't match any hash in the allowed set.
Risk
Likelihood: guaranteed — the hash is simply wrong in the circuit, no edge case needed.
Impact: the finder of treasure 9 permanently loses their 10 ETH reward. Also, with the intended logic (assuming the double-claim bug is fixed), the hunt can never fully complete since only 9 out of 10 treasures can be claimed. That means withdraw() can never be called by the owner either, locking any remaining ETH in the contract.
Proof of Concept
Compare Prover.toml.example index 8 hash vs main.nr index 8:
Prover.toml.example[8]:
-4417726114039171734934559783368726413190541565291523767661452385022043124552main.nr ALLOWED_TREASURE_HASHES[8]:
-961435057317293580094826482786572873533235701183329831124091847635547871092
They don't match. The circuit entry is a copy of index 9 (treasure 10's hash).
Recommended Mitigation
Lead Judging Commences
unclaimable treasure / bricked withdraw path
The issue stems from a mismatch between the circuit and the contract’s economic assumptions: the Solidity contract is configured for `MAX_TREASURES = 10` and only allows the owner to call `withdraw()` once `claimsCount >= MAX_TREASURES`, while the Noir circuit’s baked-in `ALLOWED_TREASURE_HASHES` array does not actually contain ten distinct treasures because one hash is duplicated and another expected hash is missing. As a result, under the intended one-claim-per-treasure design described in the README, there are only nine uniquely claimable treasures even though the system is funded and accounted as if ten rewards can be legitimately redeemed. That creates two linked consequences from the same root cause: first, one treasure is effectively unclaimable because no valid proof can ever be generated for the missing allowed hash, and second, the normal “hunt over” withdrawal path becomes bricked because honest participants can never reach ten legitimate unique claims, leaving the post-hunt fund recovery logic via `withdraw` function permanently unreachable. The owner can still intervene through the emergency path.
Rewards breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.