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

Ten on-chain rewards vs nine distinct allowed hashes

virgilbb

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.

// @> ten payout slots on chain
uint256 public constant MAX_TREASURES = 10;
​
// @> baked-in list has duplicate entries — nine unique values
global ALLOWED_TREASURE_HASHES: [Field; 10] = [ /* ... duplicate at [8] and [9] ... */ ];
​

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:

// contracts/src/TreasureHunt.sol
uint256 public constant MAX_TREASURES = 10;
​

Supporting code — duplicate tail proves nine distinct hashes max:

// circuits/src/main.nr — same literal at [8] and [9]
global ALLOWED_TREASURE_HASHES: [Field; 10] = [
// ...
-961435057317293580094826482786572873533235701183329831124091847635547871092,
-961435057317293580094826482786572873533235701183329831124091847635547871092
];
​

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

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

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.

-uint256 public constant MAX_TREASURES = 10;
+uint256 public constant MAX_TREASURES = 9; // after aligning circuit allowlist
​
-// duplicate at indices 8 and 9
+// add a tenth distinct hash and regenerate verifier artifacts
​
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!