Root + Impact

Description

• Normal behavior: Example Prover.toml rows should deserialize in nargo execute so operators can prove for every documented treasure index.

• Problem: Prover.toml.example lists many treasure_hash values as negative decimals. nargo execute rejects those strings with invalid digit found in string. Positive decimal rows execute. Operators following the example cannot prove for most listed rows without converting to field canonical form.

Risk

Likelihood:

• Default workflow copies Prover.toml.example and runs nargo execute in circuits/.

• Toolchain: nargo 1.0.0-beta.19 rejects negative decimal strings for this input shape.

Impact:

• Practical claim pipeline failure for most rows; operators waste time on input format errors.

• Hunt operations depend on undocumented field encoding steps.

Proof of Concept

Explanation: Many rows in Prover.toml.example use negative decimal strings for treasure_hash. nargo execute rejects those literals, so the default copy-paste workflow fails unless inputs are converted to an accepted canonical form.

Supporting code — reproduce parse failure (contest repo, circuits/):

Expected stderr (example): invalid digit found in string (or similar) when a negative-decimal treasure_hash line is active.

Supporting code — working path uses build.sh, which rewrites Prover.toml from the example with toolchain-friendly values for the selected index:

If operators skip build.sh and run nargo execute on the raw example, they hit the deserialization issue on negative-decimal rows.

Recommended Mitigation

Explanation: Example inputs must use a format nargo accepts for field elements (for example positive decimal canonical values, or a documented hex encoding). Document how negative field values map to literals, or normalize rows in build.sh before nargo execute. That removes operator friction and failed default runs.