SNARKeling Treasure Hunt

Description

The contract incorrectly uses an uninitialized immutable variable _treasureHash when checking whether a treasure has already been claimed.

Instead of using the function parameter treasureHash, the contract performs the check using _treasureHash, which is never assigned in the constructor and therefore defaults to bytes32(0).

As a result, the duplicate claim protection does not correctly apply to individual treasures, and the mapping logic becomes inconsistent with the intended design.

This breaks the invariant that each treasure should be uniquely claimable only once.

Risk

The contract incorrectly uses an uninitialized immutable variable _treasureHash when checking whether a treasure has already been claimed.

Instead of using the function parameter treasureHash, the contract performs the check using _treasureHash, which is never assigned in the constructor and therefore defaults to bytes32(0).

This breaks the intended claim uniqueness logic and causes incorrect state tracking for treasure claims.

Impact:

• Claim tracking is incorrect

• Only bytes32(0) is checked for duplication

• Real treasure hashes are not properly protected

• Claim logic diverges from intended design

Severity:

High

🧪 Proof of Concept

The issue occurs because the contract checks an uninitialized storage variable instead of the input parameter.

Step 1 — User submits a valid claim

Step 2 — Incorrect state check is performed

Inside the claim function:

However:

• _treasureHash is never initialized

• It defaults to bytes32(0)

Step 3 — Actual behavior

The contract always evaluates:

instead of:

Step 4 — Result

• Only the zero hash key is ever checked

• Real treasure hashes are not properly tracked

• Claim uniqueness enforcement is broken

🛠️ Recommended Mitigation

The contract should correctly use the function parameter treasureHash for claim tracking.

✅ Fix

Replace:

With:

🧹 Optional Improvement

Remove the unused variable to prevent confusion:

🧠 Expected Outcome After Fix

• Each treasure is tracked correctly

• Duplicate claims are properly prevented

• Contract behavior matches intended design