M-01 Mismatch Between `MAX_TREASURES` and Unique Circuit Hashes
Description
The Solidity contract hardcodes MAX_TREASURES = 10, and the normal post-hunt withdrawal path requires claimsCount >= MAX_TREASURES. However, the Noir circuit currently contains only 9 unique allowed treasure hashes because the final entry in ALLOWED_TREASURE_HASHES is duplicated.
This creates a cross-module inconsistency between the contract’s terminal condition and the circuit’s effective set of uniquely claimable treasures.
Risk
If duplicate-claim protection is fixed as intended, the system may allow only 9 unique successful treasure claims while still requiring 10 claims before withdraw() is permitted.
This can lead to:
-
an unreachable normal terminal condition
-
residual ETH remaining locked unless an emergency owner path is used
-
inconsistent assumptions between contract logic and circuit logic
Proof of Concept
The inconsistency can be reasoned about directly from the code. If the circuit exposes only 9 unique hashes, then the contract’s 10-claim terminal condition may never be satisfied.
In Solidity:
and:
In Noir:
Recommended Mitigation
Bring the contract and circuit back into agreement. The preferred fix is to restore the intended unique allowlist in the circuit, then regenerate all dependent artifacts.
Or, if the intended number of distinct treasures is actually 9, then the contract should instead be updated to match that design decision:
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.