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]: -4417726114039171734934559783368726413190541565291523767661452385022043124552

• main.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