Dry run
Score a rebuild on your own computer against exactly the cases the judge will replay. Free, as many times as you want, and nothing is sent.
What it runs
The dry run is the judge's replay, run by you. It downloads three things from this site and checks each one by sha256: the original ELF from the program's latest judge snapshot, the corpus bundle of that snapshot (up to 1,000 real mainnet instructions with the account states they read), and the replayer source. It builds the replayer once and keeps it in ~/.cache/teardown, builds your crate the way the judge does, then replays every real case plus 10,000 fuzzed variants on two LiteSVM instances. The fuzz seed comes from the corpus sha256, so the variants are the same ones the judge generates.
Your crate, your binary and the report stay on your computer. The script only downloads; it never uploads anything, and the site does not learn that you ran it beyond the plain file downloads.
The command
curl -fsSL https://www.propammengine.xyz/verifier/dryrun.sh | sh -s <program> <crate dir | file.so>The first argument is the program address. The second is either a crate directory (it must contain Cargo.toml and Cargo.lock) or a .so you already built. For a directory the script runs cargo build-sbf -- --locked inside it and takes the newest .so in target/deploy. It needs curl, tar, a Rust toolchain with cargo and, for a crate directory, Agave cargo build-sbf. Each target page has the line with its address filled in. To try it on a program whose source is public, use the Memo calibration on the verifier page:
curl -fsSL https://www.propammengine.xyz/verifier/dryrun.sh | sh -s MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr ./memo-rebuildThe inputs come from GET /api/v1/dryrun/:program. It answers for every target the judge has snapshotted and for the SPL Memo calibration, and returns 404 with a plain sentence for a program the judge has not snapshotted yet.
Reading the summary
| Line | Meaning |
|---|---|
cases | Real cases plus fuzzed variants, the same count the judge replays. |
budget_bound | Cases where the original itself runs out of compute units. They are counted and not compared, like at the judge. |
compared | Every case that is not budget_bound. |
matched | Compared cases where your binary gives the same result, the same logs, the same return data and the same writable accounts. Split into real and fuzzed. |
original succeeds | Cases where the original returns success. A PASS needs at least 100. |
differing cases | Compared cases that do not match. |
First difference | The first case that differs: its id (transaction signature and instruction index for a real case), its instruction data, then each field that differs with the original's value above yours. A field is the result, a log line (logs[n]), the return data, or an account's lamports, owner or data (with the first differing byte offset). |
The last line is one of two:
PASS-ready: every compared case matches
not yet: N of M matchThe full report is written in ~/.cache/teardown/reports, in the judge's own format, with up to 20 differing cases. The exit code is 0 for PASS-ready and 1 otherwise.
Toolchain
The judge builds with Agave 3.1.10 (platform tools v1.52, rustc 1.89.0). The script reads your local cargo build-sbf --version and warns when it differs. A different compiler can change what a binary logs, how it formats values and how many compute units it uses, so a dry run on another version can disagree with the judge. Use the same version for a dry run you rely on.
What PASS-ready means
PASS-ready means the binary you replayed matches the original on every compared case of the current corpus, with enough success cases. If you submit the same source and the judge builds it with the same toolchain against the same snapshot, the submission should PASS. It is a local check, not a verdict: only the judge's report decides, the snapshot can be refreshed when the program is upgraded (the dry run info then points at the new corpus), and a payout depends on the pot and the rules in Hunting and the judge.