Read the Roadmap first to see what's real versus what's explicitly not built yet, so a contribution lands where it's actually useful.
git clone --recurse-submodules https://github.com/CodesbyFebin/rust-stark-zkvm.git cd rust-stark-zkvm cargo build --release cargo test --release --workspace cd contracts && forge test
Use --release for tests, not just binaries. One constraint has a data-dependent polynomial degree that trips a Winterfell debug-only self-check stricter than actual soundness requires — --release compiles that check out; the same tests pass either way once that specific assertion is skipped. See Architecture for the full explanation.
cargo clippy --release --workspace --all-targets should be clean.cargo test --release --workspace and forge test should both pass — CI runs both on every PR, and a red check means it isn't mergeable as-is..zkasm semantics or the AIR, add a test — including, where relevant, a negative test (tampering with a claim should be rejected). Soundness is a thing the test suite checks, not a slogan.Check the real roadmap's ordered next steps (loops, addressable memory, RISC-V compatibility). If you want to work on something not listed there — especially anything touching contracts/'s trust model or the on-chain verifier — open an issue first. Those are the parts where a well-intentioned change can quietly break a soundness guarantee.
No fake backends named after real projects they don't implement, no todo!() or "coming soon" left in place of real code (put it in the roadmap docs instead), and no verifier logic that accepts something it shouldn't just to make a demo pass. If a PR's tests are testing that the wrong thing was accepted, that's a bug in the PR, not in the test.
Don't open a public issue for a soundness bug in the AIR, or a bug in contracts/ that could let an invalid proof get accepted or paid out. See the Security page.