Root + Impact

Description

• Normal behavior: Physical treasure secrets stay confidential until discovery; only public hashes and proofs appear on chain.

• Problem: Deploy.s.sol states secrets are not revealed to the public, then lists the secrets as 1 through 10 in comments. Anyone with repository access can generate witnesses and proofs without field discovery.

Risk

Likelihood:

• The script ships in the contest repository and is copied into deployments and forks.

• Reviewers, auditors, and competitors read deploy scripts during setup.

Impact:

• The physical hunt fairness property fails because proof generation does not require discovering a secret in the field.

• Rewards can be claimed by anyone who runs the documented proving pipeline with the leaked values.

Proof of Concept

The deploy script comments contradict the stated confidentiality of treasure secrets: plaintext values appear next to the phrase not revealed to the public. This is a documentary PoC (no chain interaction): open the file and compare with fixture inputs.

Steps

1. Open contracts/scripts/Deploy.s.sol and locate the comment block that lists secrets 1–10 and the public hash lines (see excerpt below).

2. Open circuits/Prover.toml.example and confirm the treasure array uses the same small domain ("1" … "10"), so anyone with the repo can derive witnesses without field discovery.

Expected result: Reviewer can read plaintext secrets and matching hashes directly from the repository; no guessing required.

Recommended Mitigation

Explanation: Physical treasure values must not appear in version control. Operators should load secrets from secure storage (KMS, sealed CI, or offline ceremony) at deploy or proving time. Comments that list plaintext secrets defeat the hunt and should be deleted; publish only public hashes or commitments on chain or in docs.