# SP1: executing Rust programs inside a zero-knowledge virtual machine

> SP1 compiles Rust and other LLVM-compatible programs for RISC-V, executes them through its zero-knowledge virtual machine, and produces proofs of that execution. It suits blockchain and other developers who need verifiable computation, but adopting it requires accepting a specialized Rust toolchain and proof-system complexity.

**succinctlabs/sp1** — SP1 is a zero‑knowledge virtual machine that proves the correct execution of programs compiled for the RISC-V architecture.

- Repository: https://github.com/succinctlabs/sp1
- Website: https://docs.succinct.xyz/docs/sp1/introduction
- Stars: 1,752 · Forks: 712
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/succinctlabs-sp1

## What SP1 proves, and who needs that proof

SP1 addresses the gap between executing a program and allowing someone else to check that execution without trusting the machine that ran it. Its central abstraction is a zero-knowledge virtual machine, or zkVM, for programs compiled for the RISC-V architecture. The README describes the target workload as programs written in Rust, including programs with std support, and as any LLVM-compiled language that can be compiled into a supported program.

That makes the intended users fairly specific. A blockchain team may want to prove the behavior of a light client or zkEVM component. A developer may want to move an existing computation into a verifiable execution environment. The relevant benefit is not simply faster computation. The important output is a proof that can be checked against a claimed program result, together with the program execution context needed to interpret that result.

The repository examples point to the kinds of workloads being represented: aggregation, Ethereum-related elliptic-curve examples, BLS12-381, BN254, JSON, Keccak, Poseidon2, regex, ELF handling, chess, and cycle tracking. These are examples of applications and proof-oriented primitives, not a promise that every dependency or environment will behave identically to a normal desktop Rust program. SP1 is best understood as a programmable proof target for teams with a specific statement to verify.

## The SP1 execution and proving path

The repository layout separates the system into compiler, executor, machine, runner, prover, verifier, SDK, CLI, and cryptography-related crates. That separation is visible in `Cargo.toml`, where workspace members include `crates/core/compiler`, `crates/core/executor`, `crates/core/machine`, `crates/core/runner`, `crates/core/runner-binary`, `crates/prover`, `crates/verifier`, and `crates/sdk`. The README also identifies the SP1 prover as being powered by the Plonky3 toolkit.

Based on this structure, the broad data path starts with a program compiled for RISC-V. SP1 executes that program in a virtual machine designed to expose the computation to proof generation. The machine and prover produce a proof for the execution. A verifier can then check the proof rather than rerunning the complete computation on trust assumptions. The presence of separate runner, prover, and verifier crates indicates that execution, proof creation, and proof checking are distinct concerns in the codebase.

SP1 also uses precompiles as an extension point for operations that can be accelerated outside ordinary CPU execution. The README explains that this builds on the idea of builtins and aims to make these operations extensible as additional tables alongside the CPU. This is relevant when evaluating an application because cryptographic or other repeated operations may not be treated exactly like arbitrary guest instructions. The exact available precompiles and their interfaces are not enumerated in the README, so an application review must inspect the relevant crates and examples instead of assuming every operation is covered.

## Installation and the first SP1 workload

The README does not provide a self-contained install command or a complete first-program listing. It tells developers to install Rust, then follow the SP1 installation guide and the getting started guide linked from the project documentation. The project also publishes an examples directory, so the first practical use is to select an example that matches the computation being investigated.

A newcomer can begin with the documented setup sequence:

1. Install Rust from the Rust project website.
2. Follow the SP1 installation guide at the linked `getting-started/install` documentation.
3. Read the `getting-started/quickstart` section before building a proof-producing workflow.
4. Inspect one of the repository examples before creating a new program.

The README names `examples/fibonacci` as an example, while `examples/io` is relevant when the program consumes or emits input. Those names identify real repository directories, but they do not by themselves document the commands or code required to build them. The documentation is therefore the correct source for installation details, package versions, prover commands, and SDK configuration. No undocumented flag should be inferred from the directory names.

The repository declares version `6.9.0` in `Cargo.toml`, while the README states a current MSRV of 1.91. The same repository file lists `rust-version = "1.88"`, which conflicts with the README's stated MSRV. That discrepancy needs to be resolved before a build is treated as reproducible. It is a concrete adoption check, not a reason to assume either value is correct.

## Rust compatibility and the boundary around ordinary software

SP1 supports programs written in Rust with std support, and the README says most Rust crates should be supported. That statement is useful, but it is not equivalent to saying that an existing Rust service can be moved into SP1 without review. Compilation target, runtime assumptions, available system interfaces, dependencies, and resource limits all matter to whether a program behaves as intended.

The examples include `invalid-hint`, `mprotect`, `many-traps`, and `cycle-tracking`. Their presence indicates that the repository covers execution edge cases and performance-oriented program behavior, but the README does not describe the behavior or expected output of each example. An engineer should treat those directories as investigation points, not as a guaranteed compatibility matrix.

SP1 also differs from a general-purpose interpreter. It targets RISC-V execution and proof generation, so code that relies on a native host architecture may need modification. LLVM-compatible languages may be usable when they compile into the accepted form, but the README does not enumerate every supported language, compiler version, or library. The `Dockerfile.build` and build scripts may establish additional prerequisites that are not summarized in the README. Dependency review and an actual compilation path are required before assuming that a workload is supported.

## Operational limits and the cost of owning a prover

A proof-generating zkVM is not just a library added to an application. The repository has dedicated prover, verifier, recursion, machine, runner, CLI, SDK, and GPU-related components. That architecture creates operational questions beyond ordinary Rust compilation, including how proofs are generated, how verification is integrated, and how workloads are managed across the different runner and prover pieces.

The repository includes `sp1-gpu`, CUDA-related crates, `bench_test_prove.sh`, and several benchmark-oriented examples. These entries show that proving is a substantial part of the system, but they do not provide hardware requirements, proof-size limits, throughput figures, or memory limits in the README. Consequently, the project cannot be selected on an assumed performance level from this material alone.

There is also a security boundary. The README says SP1 has undergone audits by Veridise, Cantina, Zellic, and KALOS, and links to the audit reports. An application still has to review the exact code, dependency versions, proof verification path, and deployment configuration it uses. The project's disclaimer also limits liability. The stated production recommendation does not remove the need to understand what is being proven and what inputs are accepted.

## SP1 compared with native Rust execution

The practical alternative to SP1 is often ordinary Rust execution with a trusted service or a separate application-specific verifier. That approach avoids moving the workload into a RISC-V zkVM and avoids generating a general zero-knowledge proof, but it does not provide the same verifiability property. The choice depends on whether the result must be independently checkable by a party that does not trust the executor.

RISC0 is acknowledged by SP1 as a source for its Rust toolchain, installation and build scripts, and RISC-V runtime borrow code. That acknowledgement shows a technical relationship, but the README does not provide a feature or performance comparison with RISC0. Based on the confirmed material, the meaningful distinction is architectural: SP1 uses the Plonky3 toolkit for its prover, exposes extensible precompiles as additional tables, and organizes its implementation around compiler, executor, machine, runner, prover, verifier, and SDK crates. A direct product comparison would require documentation not present here.

For teams that only need a normal program to run, SP1 adds complexity without serving the stated problem. For teams that need a proof of execution, a plain Rust service cannot supply that property. This makes SP1 a specialized choice rather than a general replacement for Rust tooling.

## Conclusion

SP1 is a reasonable choice for developers who can express a verifiable workload in Rust or another LLVM-compiled language and already accept a RISC-V execution model, a minimum Rust version, and the operational cost of producing and verifying proofs. It is a poor fit when those constraints are unacceptable or when a native proof system is the better fit. Before adoption, inspect the installation documentation, confirm the required Rust toolchain, and verify that the intended program and its dependencies can run as SP1 inputs.

## FAQ

### What is SP1 and what does it prove?

SP1 is a zero-knowledge virtual machine that proves the execution of programs compiled for the RISC-V architecture. The README specifically describes Rust programs with std support and other LLVM-compiled languages.

### How do I install SP1 and run my first example?

The README says to install Rust and follow the linked installation guide and getting started guide. It does not include the actual install or proving commands, so use the linked documentation rather than inferring them from the repository.

### Does SP1 support normal Rust crates and programming patterns?

The README says most Rust crates should be supported and mentions std support. It does not promise compatibility with every host-specific dependency or operating-system interface, so dependency and compilation checks remain necessary.

## Sources

- [License: Apache-2.0](https://github.com/succinctlabs/sp1/blob/main/LICENSE)
- [Project website](https://docs.succinct.xyz/docs/sp1/introduction)
- [README](https://github.com/succinctlabs/sp1/blob/main/README.md)
- [Releases](https://github.com/succinctlabs/sp1/releases)
- [succinctlabs/sp1 on GitHub](https://github.com/succinctlabs/sp1)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/succinctlabs-sp1