SNARKeling Treasure Hunt

First Flight #59
Beginner FriendlyGameFiFoundry
100 EXP
View results
Submission Details
Severity: high
Valid

Duplicate Hash in ALLOWED_TREASURE_HASHES (Circuit Bug)

Root + Impact

Description

  • The ALLOWED_TREASURE_HASHES array contains a duplicate entry. Indices 8 and 9 both have the same hash value:


// @>ALLOWED_TREASURE_HASHES in main.nr:
-961435057317293580748470334769940469574357001183329831124091847635547871092, // index 8
-961435057317293580094826482786572873533235701183329831124091847635547871092 // index 9

Risk

Likelihood:

  • Reason 1: Probability: 10% (=1/10), assume each treasure to be equally uncovered.

Impact:

  • Impact 1: As long as either Treasure@index8 or Treasure@index9 is successfully discovered, the other one cannot be claimed since they point to the same Treasure.

Proof of Concept

When a game starts, a participant discovers the Treasure@index9 and claims the reword. Any participant cannot claim the reward for Treasure@index8 as they point to the same Treasure.

Game start ...
ParticipantA discovers Treasure @index9 and submits a ZK proof to claim a treasure reward for a its recipient address;
ParticipantA's submission is proved and the reward is taken.
ParaticipantB discovers Treasure @index8 and submits a ZK proof to claim a treasure reward with a its recipient address.
The claim failed since Treasure @index8 points to an already claimed Treasure @index9.

Recommended Mitigation

To remove one of the duplicate hash in main.nrand add a new valid hash pointing to a unique Treasure.

//file: main.nr
global ALLOWED_TREASURE_HASHES: [Field; 10] = [
1505662313093145631275418581390771847921541863527840230091007112166041775502,
-7876059170207639417138377068663245559360606207000570753582208706879316183353,
-5602859741022561807370900516277986970516538128871954257532197637239594541050,
2256689276847399345359792277406644462014723416398290212952821205940959307205,
10311210168613568792124008431580767227982446451742366771285792060556636004770,
-5697637861416433807484703347699404695743570043365849280798663758395067508,
-2009295789879562882359281321158573810642695913475210803991480097462832104806,
8931814952839857299896840311953754931787080333405300398787637512717059406908,
- -961435057317293580094826482786572873533235701183329831124091847635547871092,
+ (a valid hash pointing to a unique Treasure)
-961435057317293580094826482786572873533235701183329831124091847635547871092
];
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!