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

[H-02] Duplicate allowed hash in Noir circuit collapses two treasure slots into one claim key

adcdiii

Root + Impact

Description

The normal behavior is to have 10 distinct secrets mapped to 10 distinct allowed Pedersen hashes.

The issue is that ALLOWED_TREASURE_HASHES contains the same value at index 8 and 9. This collapses two intended treasure slots into one cryptographic identity. Under intended one-claim-per-hash semantics, only one of those two slots can be redeemed independently.

// circuits/src/main.nr
global ALLOWED_TREASURE_HASHES: [Field; 10] = [
// ...
-961435057317293580094826482786572873533235701183329831124091847635547871092, // @> index 8
-961435057317293580094826482786572873533235701183329831124091847635547871092 // @> index 9 (duplicate)
];

Risk

Likelihood:

  • The duplicate constant is deterministic and always active for all proofs.

  • At least one legitimate participant eventually hits the colliding slot in normal operation.

Impact:

  • One treasure reward becomes permanently uncollectable once per-hash replay protection is enforced as intended.

  • Protocol promise of 10 unique claimable treasures is violated.

Proof of Concept

Standalone reproduction in Noir:

  1. Compute pedersen_hash([9]) which equals -4417726114039171734934559783368726413190541565291523767661452385022043124552.

  2. Check membership against current ALLOWED_TREASURE_HASHES.

  3. Observe membership is false because the array duplicates hash #10 instead of including hash #9.

  4. A proof for treasure 9 cannot satisfy is_allowed(treasure_hash).

// Should fail with current constants in circuits/src/main.nr
#[test(should_fail)]
fn test_treasure_9_unclaimable_due_to_duplicate_constant() {
let treasure: Field = 9;
let treasure_9_hash: Field =
-4417726114039171734934559783368726413190541565291523767661452385022043124552;
let recipient: Field = 2;
​
// sanity: pedersen hash matches expected hash for 9
assert(std::hash::pedersen_hash([treasure]) == treasure_9_hash);
​
// fails because treasure_9_hash is missing from ALLOWED_TREASURE_HASHES
main(treasure, treasure_9_hash, recipient);
}

Written exploit flow:

  • The duplicated hash allows only one of the two intended physical treasure slots to be represented as a unique on-chain claim key.

  • Once that shared hash is claimed once (with a correct claimed[treasureHash] guard), the second participant mapped to the same hash cannot claim independently.

Recommended Mitigation

Use the global constant ALLOWED_TREASURE_HASHES in circuits/src/main.nr.

global ALLOWED_TREASURE_HASHES: [Field; 10] = [
// ...
- -961435057317293580094826482786572873533235701183329831124091847635547871092,
+ -4417726114039171734934559783368726413190541565291523767661452385022043124552,
-961435057317293580094826482786572873533235701183329831124091847635547871092
];

After updating the circuit constant, regenerate proving artifacts and contracts/src/Verifier.sol from the new circuit.

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!