SP1 v6.9.0 adds authentication for standalone clients

SP1 shipped v6.9.0 on October 10, 2026, adding configurable authentication for standalone network clients alongside GPU, library, and CLI changes. Teams using the SP1 SDK should review their client setup and toolchain pins against the release before updating. Release notes

What changed in SP1 v6.9.0

The main SDK change is a public builder for NetworkClient. Pull request #3001 adds optional mutual TLS (mTLS) identity and refreshable bearer-token settings, so a caller can use authenticated Prover Network and Artifact Store RPCs without constructing a NetworkProver. The existing NetworkClient::new() constructor and NetworkProver API stay unchanged, according to the merged change.

The release also includes three performance entries: removing unnecessary data reordering in GPU NTT, simplifying GPU zerocheck constraint evaluation, and improving global trace generation. The NTT change is recorded as merged PR #2990. The release notes do not give before-and-after proving times, so treat these as implementation changes rather than a quantified speed claim.

Two correctness and build items matter to teams compiling or verifying programs. The release says zkvm_bls12_* and zkvm_ripemd160 were made spec conformant. It also says the CLI pins its toolchain with an LTO atomic-lowering fix. That pin is succinct-1.96.0-64bit-v3, as described in PR #3007.

The rest of the release focuses on delivery and CI: upload all release assets before publishing, allow configured runner environments for PR checks, default PR workflow runners to v3, and configure a Go proxy fallback for release builds. The full changelog identifies the comparison as v6.8.1...v6.9.0.

Who is affected and why it matters

The new builder is useful when an application needs to call network or artifact-store RPCs directly through a NetworkClient, without using the higher-level NetworkProver. Before this change, credentials were supported internally but could not be configured through that client's public constructor. Teams that already use NetworkProver can keep that API; the change does not require them to adopt a new client construction pattern.

The authentication options give operators a way to configure mTLS client identity or bearer tokens for those standalone calls. The PR reports that its tests covered both network modes, missing-token rejection, token refresh across client clones, and unauthenticated clients. It also notes that certificate renewal requires creating a new client, while bearer-token refresh can use the existing shared token handle.

GPU prover users should check whether their workloads benefit from the NTT and zerocheck changes, but benchmark their own proving jobs before estimating capacity or cost changes. The release supplies no timing data. Developers who use the affected BLS12 or RIPEMD-160 zkVM operations should review their expected outputs and verifier compatibility after upgrading, since the release specifically calls out spec conformance for those operations.

What to do now

1. Check your dependency and toolchain pins. If you use SP1 crates or the CLI, decide whether to move them to v6.9.0 in your normal dependency update. Keep the version recorded consistently across local development and CI.
2. If you make standalone network calls, inspect the NetworkClient builder documentation and configure only the credentials your service requires. The SP1 docs describe installation through sp1up and checking the installed CLI with cargo prove --version; use your project's existing installation policy when selecting a toolchain. Installation guide
3. Confirm the authentication path in your own environment. In particular, plan client recreation when rotating an mTLS certificate; bearer-token refresh has a different lifecycle.
4. Run your existing proof, verification, and CI checks after the update. Include cases using zkvm_bls12_* or zkvm_ripemd160 if your guest programs call them, and compare GPU proving results on representative inputs before changing operational estimates.

Caveats

The release does not quantify the GPU performance changes. The authentication PR says its TLS tests did not perform an mTLS handshake, so validate the certificate and endpoint behavior in the deployment environment where you will use it. The PR reports 41 network tests and builder documentation checks on Rust 1.98, while full workspace and GPU checks were left to GitHub CI.