Root + Impact

Description

• Normal behavior: ALLOWED_TREASURE_HASHES should list ten independent treasures. Fixture rows should match the baked-in array so scripted nargo runs succeed for each index.

• Problem: Indices 8 and 9 share the same field element. The ninth row in Prover.toml.example may not match ALLOWED_TREASURE_HASHES[8], so scripted builds for that index fail is_allowed while operators expect ten distinct treasures.

Risk

Likelihood:

• Operators follow Prover.toml.example and build.sh with TREASURE_INDEX set to the mismatched row.

• The duplicate is visible in the single in-scope circuit file.

Impact:

• Broken scripted proving path and operator confusion; deployments or demos can get stuck on a row that does not match the array.

• Fairness story weakens when two slots represent the same hash.

Proof of Concept

Explanation: The last two entries of ALLOWED_TREASURE_HASHES are the same Field literal, so two indices share one hash. That is visible in source and implies at most nine distinct allowed hashes.

Supporting code — show duplicate lines in main.nr (contest repo root):

Expected result: two matching lines (indices 8 and 9 in the array).

Supporting code — excerpt (tail of allowlist):

Optional: cd circuits && TREASURE_INDEX=8 ./scripts/build.sh and TREASURE_INDEX=9 ./scripts/build.sh — both select the same duplicate hash value for public input comparison against fixtures.

Recommended Mitigation

Explanation: Replace the duplicate ninth and tenth allowlist entries with two distinct field values, regenerate the verifier (build.sh) and redeploy. Align every row in Prover.toml.example with ALLOWED_TREASURE_HASHES[i] so scripted builds for each index match is_allowed.