SP1 v6.10.0 moves the SDK to Tonic 0.14.6 and fixes x86 JIT remw

Succinct released SP1 v6.10.0 on October 23, 2026. It has one breaking change: the SDK now uses Tonic 0.14.6 and Prost 0.14. It also fixes a native x86-64 JIT bug and a failure when a prover cluster delivers the same shard twice. If you pass your own Tonic types into the SP1 SDK or run sp1-cluster, upgrade your gRPC dependencies together with SP1.

What changed in v6.10.0

The release notes list three code changes that matter to users, plus CI, documentation and repository chores.

Breaking: Tonic 0.14.6 in the SDK (PR #3015). The PR, merged on October 21, moves "the SDK and shared prover transport to Tonic 0.14.6 and Prost 0.14". It switches to the official tonic-prost codec and tonic-prost-build generator, updates the TLS features and removes the unused Twirp dependency. The PR says protocol schemas and configured message limits do not change. The goal is to use Tonic's own size checks on decoded messages instead of keeping a vendored copy of Tonic. The SDK and prover crates share transport types, so both moved at the same time.

Fix: x86 JIT remw for i32::MIN % -1 (PR #3010). The x86-64 JIT backend handles this operand pair as a special case, because idiv would raise a divide error. That branch was copied from divw: it wrote i32::MIN to RAX, but remw reads its result from RDX. The destination register therefore got whatever RDX already held. RISC-V defines the result as 0, and the portable executor, the tracing VM and the AIR all compute 0. On x86-64 Linux hosts that use the native executor (sp1_use_native_executor), execute() could report wrong public values. If the wrong value reached memory, proving failed because the trace no longer matched the executor's memory oracle. The PR notes that safe Rust cannot reach this case, but C or inline assembly can. This is the first contribution from @MatusKysel.

Fix: redelivered core shards (PR #3018). A GPU worker deletes a core shard's record as its last step. It can stop before it reports the result. The coordinator then gives the shard to a second worker, which fails with NotFound. The old recovery check (recover_if_complete, from #2848) needed both the proof and the deferred output. However, the controller deletes the deferred output after reading it, so the check failed and the whole proof failed. The new recover_prove_shard_if_complete check succeeds if the proof exists and either the deferred output exists or the record is gone. The task format stays the same.

CI and chores. The release adds cargo-deny dependency checks (#3019), a Go proxy fallback for CLI Docker builds (#3008), an OSS Scanner Dockerfile and threat model (#3021), and renames SECURITY.MD to SECURITY.md (#3025).

Who is affected

SDK users who share Tonic types with SP1. The PR's compatibility note is direct: callers that pass Tonic types such as Channel or Identity must also use Tonic 0.14, and code that encodes SDK messages directly must use Prost 0.14. If your crate builds its own gRPC channel or mTLS identity and passes it to the SDK, two Tonic versions in one dependency graph will cause type mismatch errors at compile time. The PR reports that its earlier checks included calls from the new client to a Tonic 0.12 server over HTTP and mTLS, so the wire protocol should still work with older servers.

Cluster operators. The shard fix matters most for sp1-cluster, where tasks can be delivered more than once. The matching sp1-cluster PR #208 adopts recover_prove_shard_if_complete and moves the cluster to Tonic 0.14.6. The Succinct network repository made the same Tonic 0.14 move in PR #245. Before this fix, a worker restart at the wrong moment could fail a whole proof.

Programs that use C or inline assembly on x86-64 Linux. If your guest program can execute remw with these exact operands and you use the native executor, earlier versions could return wrong public values from execute(). Pure safe-Rust guests are not affected, according to the PR.

Not affected: the PR states that it "does not update the V5 SDK".

How to upgrade

1. Check your dependency tree for direct uses of tonic and prost. Look at every place where you pass a Channel, Identity or other Tonic type into SP1 code.
2. Move sp1-sdk and the other SP1 crates to 6.10.0 together. If the version is not yet on your registry mirror, use the v6.10.0 git tag.
3. Raise your own tonic to 0.14 and prost to 0.14, following the compatibility notes in PR #3015. Review your Tonic TLS feature flags, because the PR updates TLS features.
4. Install the matching toolchain. The SP1 docs say sp1up installs the latest version by default and support sp1up --version <version>. In CI, the docs recommend pinning with sp1up -C <commit>.
5. If you run sp1-cluster, move to a cluster build that includes PR #208, so workers and the SDK use the same Tonic version.
6. If you use the native executor on x86-64 Linux, run your execute() tests again and compare public values with your earlier runs.

This dependency change follows the PR #3015 compatibility notes for the v6.10.0 crates (shown as Cargo.toml entries):

 [dependencies]
-sp1-sdk = "6.9.0"
+sp1-sdk = "6.10.0"
-tonic = "0.12"
-prost = "0.13"
+tonic = "0.14"
+prost = "0.14"

These are the toolchain commands from the SP1 installation and CI docs:

curl -L https://sp1up.succinct.xyz | bash
sp1up --version 6.10.0
cargo prove --version
cargo update -p sp1-sdk

Caveats

The old Tonic and Prost versions in the diff are examples. Your current versions may differ, so check them with cargo tree -i tonic. The test results in PR #3015 ("All 43 SDK network tests pass") are reported by the maintainers. Projects that still use the V5 SDK keep the old transport stack and get none of these changes.

Other items on the ZK desk this week include a Plonky3 p3-word v0.9.0 release candidate. SP1 users can skip it for this upgrade.