SP1 v6.5.0 Moves Prover Identity Into the SDK Boundary

Succinct’s SP1 v6.5.0, released on August 26, adds a small but consequential control to the SDK: applications can now provide an mTLS client identity explicitly when connecting to the prover network.

The change matters because the SDK no longer needs to decide how certificates and private keys are discovered. The merged implementation adds async and blocking builder methods, passes the identity through the network prover and lazy gRPC channel, keeps the existing standard-TLS path when no identity is supplied, and rejects malformed identities or mTLS requests sent to a non-HTTPS RPC URL. In operational terms, an application can load credentials from its own secret manager, mounted secret, or startup policy before injecting them into the client. The private key therefore stays outside source code and container images, consistent with the accompanying OP Succinct documentation.

This is an authentication boundary, not a proof-system change. mTLS authenticates the client to a private endpoint during connection setup; it does not by itself alter what a guest program proves or how a proof is verified. Teams adopting the feature should define certificate issuance, renewal, revocation, and failure handling alongside their prover-network configuration.

The release also changes the curves implementation to use Dalek for Edwards arithmetic. That is a performance-oriented implementation change, but the v6.5.0 release notes publish no numerical benchmark, so builders should measure their own proving and verification workloads rather than assume a fixed speedup. The pull request reports 53 passing sp1-sdk tests and notes that the macOS host could not link the optional GPU feature because the required icicle native libraries were unavailable; GPU-linked jobs were covered by pull-request CI.

For ICP-adjacent ZK systems, the practical takeaway is architectural: prover access can now bind a client certificate without forcing the SDK to own the application’s secret-loading mechanism. Upgrade testing should focus on the new identity-injection path, HTTPS enforcement, certificate rotation, and the exact curve-heavy workloads used in production.