Root + Impact

Description

• Normal behavior: The contract claim cap and the circuit allowlist should agree on how many distinct treasures can be completed under one hunt.

• Problem: The contract pays up to ten claims (MAX_TREASURES == 10). After deduplication, ALLOWED_TREASURE_HASHES contains nine distinct field elements (duplicate at two indices). If replay protection correctly enforces one claim per distinct hash, the protocol may be unable to reach ten successful claims aligned with ten physical treasures.

Risk

Likelihood:

• Visible only after replay storage is fixed so each hash pays at most once.

• Until then, snarkeling-1 style repeats mask the mismatch.

Impact:

• Hunt may not complete fairly; leftover funds or blocked withdraw path depending on how the cap is reached.

• Spec mismatch between Solidity and circuit hurts operator planning.

Proof of Concept

Explanation: Solidity allows 10 successful claims; the circuit’s allowlist has only 9 distinct field values because of the duplicate (snarkeling-6). Once replay is fixed to one payout per distinct treasureHash, the hunt cannot complete 10 unique hashes without a contract or circuit change.

Supporting code — contract cap:

Supporting code — duplicate tail proves nine distinct hashes max:

Supporting command — duplicate hash appears twice in the allowlist array:

Expected output: 2 (same field element at two indices).

Expected result: spec mismatch: 10 payout slots on chain vs 9 distinct allowed hashes once per-hash replay is enforced.

Recommended Mitigation

Explanation: Either add a tenth distinct hash to the circuit allowlist and regenerate the verifier so MAX_TREASURES == 10 matches ten unique treasures, or lower MAX_TREASURES to the count of distinct allowed hashes (nine today) and document the cap. The contract and circuit must agree to avoid stuck hunts or unfair caps once per-hash replay is enforced.