Duplicate treasure hash reduces claimable treasures
Duplicate treasure hash reduces claimable treasures
Description
The ALLOWED_TREASURE_HASHES array in the circuit (circuits/src/main.nr:55-67) contains a duplicate entry. The hash -961435057317293580094826482786572873533235701183329831124091847635547871092 appears at both index 8 (line 64) and index 9 (line 66).
Meanwhile, the deploy script (Deploy.s.sol:24-26) lists the correct 10th hash as -4417726114039171734934559783368726413190541565291523767661452385022043124552, which corresponds to treasure secret 9. This hash is missing from the circuit, meaning treasure 9 can never be claimed.
The contract is funded with 100 ETH (10 treasures x 10 ETH), but only 9 unique treasures are claimable. 10 ETH will be permanently locked unless the owner withdraws after MAX_TREASURES claims — but that can never happen either, since the claimed[_treasureHash] bug (line 89) prevents more than one claim regardless.
Risk
Likelihood: High
The duplicate is hardcoded in the circuit at compile time. Every deployment using this circuit will have only 9 unique treasures.
Impact: Medium
One treasure (10 ETH) becomes unclaimable. The contract expects 10 unique treasures but the circuit only validates 9.
Proof of Concept
The
ALLOWED_TREASURE_HASHESarray has 10 entries but only 9 are unique.The missing hash from
Deploy.s.sol:25is-4417726114039171734934559783368726413190541565291523767661452385022043124552(pedersen hash of secret9).A player who finds treasure
9cannot generate a valid proof becauseis_allowed()will never match the correct hash.10 ETH remains locked in the contract.
Recommended Mitigation
Replace the duplicate entry at index 9 with the correct hash for treasure 9:
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.