SNARKeling Treasure Hunt

Description

The deployment script logs the current block.chainid, but it does not enforce an expected chain or require operator confirmation before broadcasting transactions.

This means a misconfigured RPC URL or operator mistake can cause deployment to proceed on an unintended network without an explicit script-level safety stop.

Risk

This is an operational deployment risk rather than a direct protocol exploit:

• contracts may be deployed to the wrong network

• funds used for initial deployment may be stranded on an unintended chain

• the resulting deployment may not correspond to the intended contest environment

• the verifier may be economically or operationally impractical on the unintended chain even if deployment succeeds

• the hunt may become unusable or fail to serve its intended purpose in the target operating environment

Proof of Concept

The script only logs the chain ID:

but no guard exists before:

As a result, if the operator points the script at the wrong RPC endpoint, deployment still proceeds.

This matters even when the unintended destination is EVM-compatible. The verifier and hunt contracts may still deploy, but the resulting deployment can be misaligned with the project’s real assumptions about network, users, funds, and proof-verification practicality. On some unintended networks, claim verification may be prohibitively expensive or otherwise unsuitable for the intended hunt workflow.

Recommended Mitigation

Require an expected chain ID from the environment and halt if the script is pointed at the wrong chain.