SNARKeling Treasure Hunt
First Flight #59
Beginner FriendlyGameFiFoundry
100 EXP
View results
Previous Next
Submission Details
Impact: high
Likelihood: high
Invalid

Recipient is not constrained in the Noir circuit, allowing proof front-running to steal rewards

0xkhlo

ROOT - circuits/src/main.nr ->Recipient public input is never used in any circuit constraint

Impack: Any valid proof can be submitted with an arbitrary recipient, allowing front-runners to steal rewards from legitimate finders

Description

  • The claim() function accepts a recipient address as a public input and passes it to the verifier. The Noir circuit is designed to bind the proof to a specific recipient to prevent replay attacks.

    The recipient field is declared as a public input in the circuit but is never used in any constraint. A proof generated for one recipient is valid for any other recipient, making the binding completely ineffective.

fn main(treasure: Field, treasure_hash: pub Field, recipient: pub Field) {
assert(is_allowed(treasure_hash));
assert(std::hash::pedersen_hash([treasure]) == treasure_hash);
// @> recipient is never referenced in any constraint
// @> any proof is valid for any recipient
}

Risk

Likelihood:

  • Likelihood:

    • A legitimate participant submits a claim() transaction, it is visible in the public mempool before inclusion, giving attackers the proof bytes and treasure hash

    • MEV bots and searchers routinely monitor the mempool for profitable front-running opportunities with no manual effort required

Impact:

  • An attacker copies the proof from the mempool and resubmits it with their own address as recipient , stealing the 10 ETH reward from the legitimate finder

Every single treasure claim is vulnerable , no participant can safely claim any reward on a live network

Proof of Concept

1. Alice finds a physical treasure and generates a valid ZK proof with recipient = Alice
2. Alice submits claim(proof, treasureHash, Alice) to the network
3. Bob sees the pending transaction in the mempool
4. Bob submits claim(proof, treasureHash, Bob) with higher gas fee
5. Bob's transaction is mined first
6. Verifier accepts the proof because recipient is unconstrained
7. Bob receives 10 ETH, Alice receives nothing

Recommended Mitigation

Include recipient in the pedersen hash preimage so the proof // is cryptographically bound to a specific recipient address. Bind recipient into the proof by hashing it with the treasure.

NOTE: ALLOWED_TREASURE_HASHES and the off-chain hash generation must also be updated to use pedersen_hash([treasure, recipient])

- fn main(treasure: Field, treasure_hash: pub Field, recipient: pub Field) {
- assert(is_allowed(treasure_hash));
- assert(std::hash::pedersen_hash([treasure]) == treasure_hash);
- }
+ fn main(treasure: Field, treasure_hash: pub Field, recipient: pub Field) {
+ assert(is_allowed(treasure_hash));
+ assert(std::hash::pedersen_hash([treasure, recipient]) == treasure_hash);
+ }
Updates

Lead Judging Commences

s3mvl4d Lead Judge 18 days ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement
Assigned finding tags:

unused "recipient" in circuit

The claim that the proof system is broken because the recipient is not explicitly constrained in the Noir circuit reflects a misunderstanding of how zero-knowledge proofs bind public inputs. Although the circuit does not impose algebraic constraints on recipient, the value is still included in the public input vector, which is cryptographically committed to during proof generation. As a result, the proof is only valid for the exact tuple of public inputs it was created with. Any attempt by an attacker to front-run and substitute a different recipient would alter this tuple, causing the verifier’s check to fail because the proof no longer matches the provided public inputs. Therefore, while unconstrained public inputs do not enforce logical relationships within the circuit, they remain inseparably bound to the proof itself, and this binding is sufficient to prevent tampering or replay with modified values. Run the unit tests 'testClaimInvalidProofFails', 'testFrontRunningClaimFails'.

Support

FAQs

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

Give us feedback!