SNARKeling Treasure Hunt
First Flight #59
Beginner FriendlyGameFiFoundry
100 EXP
View results
Previous Next
Submission Details
Severity: high
Valid

Allowlist duplicates a hash and fixtures may not match the baked-in array

virgilbb

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.

// @> duplicate hash at indices 8 and 9 — only nine distinct values in the allowlist
global ALLOWED_TREASURE_HASHES: [Field; 10] = [
// ...
8931814952839857299896840311953754931787080333405300398787637512717059406908,
-961435057317293580094826482786572873533235701183329831124091847635547871092,
-961435057317293580094826482786572873533235701183329831124091847635547871092
];
​

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):

grep -n "961435057317293580094826482786572873533235701183329831124091847635547871092" circuits/src/main.nr
​

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

Supporting code — excerpt (tail of allowlist):

// circuits/src/main.nr (excerpt)
8931814952839857299896840311953754931787080333405300398787637512717059406908,
-961435057317293580094826482786572873533235701183329831124091847635547871092,
-961435057317293580094826482786572873533235701183329831124091847635547871092
];
​

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.

- -961435057317293580094826482786572873533235701183329831124091847635547871092
+ <distinct tenth Field element>
​
-// misaligned Prover.toml.example treasure_hash row for index 8
+// align every fixture row with ALLOWED_TREASURE_HASHES[i] after deduplication
​
Updates

Lead Judging Commences

s3mvl4d Lead Judge 18 days ago
Submission Judgement Published
Validated
Assigned finding tags:

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.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!