Easy to say, easy to fake with a unit test that mocks the prover. Here's the actual workflow, gated on a real HTTP round trip against a real running server.
Only when it matters — path-filtered to examples/**.zkasm, crates/**, contracts/**, or the workflow file itself — on every pull request and every push to main.
cargo build --release --workspace cargo test --release --workspace
So far, a normal Rust CI job. What makes this "proof as a CI check" rather than "tests as a CI check": the workflow starts a real zkvm-host-server in the background, polls /healthz for up to 15 seconds, then runs this loop against every example program:
for f in examples/*.zkasm; do
./target/release/zkvm deploy "$f" --out "${f}.proof"
./target/release/zkvm verify "$f" "${f}.proof"
doneEvery .zkasm file gets deployed to the live server and its returned proof verified, over a real HTTP round trip. If any one fails to prove or verify, the job fails and the PR is blocked.
cd contracts && forge test -vv
Runs independently, with contracts/lib/forge-std checked out as a git submodule (submodules: true — easy to forget, fails with a confusing "file not found" if missed). See the Contracts page for what the 8 tests check.
Performance regressions — a program that used to prove in 2 seconds and now takes 20 still passes, as long as it eventually verifies — and anything about the on-chain path, since scripts/onchain_demo.sh isn't wired into CI yet. A break there would only surface by running it manually.