Every soundcalc parameter that could be re-derived from a vendor's own source re-derived exactly, 51 of 51 numeric fields across RISC0, Miden, OpenVM and SP1, and soundcalc at its pin reproduces its own reports byte-for-byte, while the failures are all in provenance: two of eight cited pins do not resolve, and four units ship no reproduction path.
hunts/r_4166b0 (Record 83 of 98 in chronological sequence)
Guiding Question
Do the ten zkVM soundness figures published by ethereum/soundcalc reproduce to the bit from the vendors' own trees at the versions the TOMLs name, and do the same TOMLs still describe the vendors' current releases?
Method & Verification
Each unit received two unmerged verdicts, REPRODUCTION and FRESHNESS, by regenerating parameters from the named vendor tree and rerunning soundcalc at pin d9078d64c9c3, with six planted faults each turning the verdict they should.
Lineage & Relationships
Primary Sources (at pin 8fa46e134)
Editorial Notes
Case-log status is settled for the units where a source existed; four units have no reproduction path and that is a property of the artifacts, not of the budget. Disposition maps to completed because the missing paths are findings, not unfinished work. SP1 is scoped: 30 of 42 numeric fields from source constants, 12 from machine.shape() at runtime, which needs a Rust build this run did not do. FRESHNESS unchanged for RISC0 means only that the cited September 2024 notebook is byte-identical, not that the vendor's prover is unchanged. Question filled from the HuntSpec. Paired with r_0dfb8d as the other transfer test outside mathematics.
Date Provenance
commit 7570cffa9a4ca0733aeba642b96f6c83cf98f121, hunts/r_4166b0/RESULTS.md, author 2026-08-25T11:21:58-05:00