By Eco research. Updated Apr 2026.
​

RISC Zero is a zero-knowledge virtual machine (zkVM) company that lets developers write programs in Rust and generate cryptographic proofs that those programs executed correctly, without revealing the input data. The RISC Zero zkVM is built on the RISC-V instruction set architecture, meaning any program that compiles to RISC-V can be proven. Its cloud proving service Bonsai and its Ethereum state proof library Steel extend this capability to smart contract verification onchain.
​

RISC Zero is a zkVM platform that compiles Rust programs to the RISC-V instruction set and generates zero-knowledge proofs of their execution. A proof, called a receipt, contains a cryptographic commitment (the journal) and a proof of correct execution (the seal). Any party with the public verifier key can confirm the computation ran correctly without re-executing it. The company was founded in 2021 and is headquartered in Seattle.
​

The RISC-V architecture choice is deliberate. RISC-V is a mature, open instruction set standard with a large toolchain ecosystem. By targeting RISC-V rather than a custom virtual machine, RISC Zero can leverage the entire Rust compiler infrastructure and standard libraries. Developers write idiomatic Rust, compile with the RISC Zero toolchain, and get a provable binary without learning a domain-specific language. This contrasts with earlier ZK development workflows that required writing arithmetic circuits directly in tools like Circom or Halo2.
​

RISC Zero raised a $40M Series A in February 2023 led by Blockchain Capital and Sequoia Capital, according to their company announcement. The company's open-source zkVM codebase is maintained at github.com/risc0/risc0, with over 1,800 GitHub stars as of Q1 2026.
​

The RISC Zero zkVM runs a program in two components: the guest and the host. The guest is the computation being proven, compiled to RISC-V and executed inside the VM. The host is the controlling environment that sets up the guest's inputs, runs the prover, and handles the resulting receipt. The prover generates a STARK-based proof of the guest execution, which can be compressed to a SNARK for efficient onchain verification. The output is a receipt containing the journal (public outputs) and the seal (the proof itself).
​

The proving system uses a STARK construction over the Goldilocks field for speed, then applies a SNARK wrapper (currently Groth16) for the compact onchain verifier. STARKs are fast to generate but produce large proofs; the SNARK wrapper compresses the proof to roughly 256 bytes suitable for Ethereum verification in a single contract call. This two-layer approach is common across modern ZK proving stacks and lets RISC Zero optimize prover speed separately from verifier cost.
​

The guest program communicates with the host through a structured interface. The host writes inputs to the guest's standard input; the guest reads them, runs the computation, and writes public outputs to a journal. The journal is committed inside the proof, so the verifier knows exactly what the program output without needing to see the inputs. This separation of public outputs from private inputs is the core privacy property of zero-knowledge proofs.
​

Proving time scales with the number of RISC-V clock cycles the guest program executes. A simple computation might take milliseconds on a GPU prover; a complex contract state proof might take minutes. RISC Zero's Bonsai service parallelizes this work across cloud hardware, and the company's Continuations feature allows proofs of programs that exceed a single segment limit by chaining multiple sub-proofs into one composite receipt. As of Q1 2026, RISC Zero reports proving throughput of approximately 1 million RISC-V cycles per second on its Bonsai cloud infrastructure, according to their developer documentation.
​

RISC Zero ships three distinct product layers: the open-source zkVM SDK for local development, Bonsai as a managed cloud proving service, and Steel as a library for generating verifiable proofs of Ethereum contract state. Each addresses a different stage of the developer workflow from prototyping to production onchain verification.
​

The zkVM SDK is the open-source core of the RISC Zero stack. Developers install it via Cargo, Rust's package manager, and structure a project as two crates: one for the guest program and one for the host. The SDK handles compilation to the RISC-V target, execution in the VM, and proof generation locally. Local proving is slow (many minutes without GPU), but it's sufficient for development and testing. The SDK also ships with a development mode that skips proof generation entirely for faster iteration cycles. The full SDK including documentation is at dev.risczero.com.
​

Bonsai is RISC Zero's cloud proving network. Instead of running a GPU cluster locally, developers submit a guest binary and input data to Bonsai via REST API and receive a receipt. Bonsai handles proof parallelization, hardware allocation, and the SNARK wrapping step. The service is designed for production workloads where proving latency matters and local hardware is unavailable or uneconomical. Smart contracts can request Bonsai proofs via an onchain callback pattern: the contract emits a request event, a Bonsai relay service generates the proof off-chain, and a callback transaction delivers the receipt back to the requesting contract. This pattern, documented in RISC Zero's Foundry template, is how most production integrations with Ethereum work today.
​

Steel is a Rust library, maintained at github.com/risc0/risc0-ethereum, that allows a RISC Zero guest program to make verified reads of Ethereum contract state. A developer writes a guest that calls an ERC-20 balanceOf or a Uniswap V3 slot0 read inside Rust code. Steel fetches the actual Ethereum state at a given block, generates an eth_getProof Merkle proof of that state, and passes it into the guest as verified input. The guest's receipt then proves not only that the Rust computation was correct but that it ran against real Ethereum state from a specific block hash. This allows smart contracts to consume Ethereum state proofs without running an onchain oracle or full state read.
​

RISC Zero's primary use cases are zkVM-based rollup proving layers, verifiable oracle computations, offchain contract logic, and ZK coprocessors that bring historical or complex state into smart contracts. Each uses the same basic primitive: a receipt that proves a Rust program ran correctly on specific inputs, verifiable onchain at low gas cost.
​

Rollup proving is the highest-profile use case. A rollup's validity prover can be a RISC Zero guest program that verifies a batch of transactions against the previous state root and outputs the new state root. The resulting receipt is submitted to the rollup's Ethereum settlement contract, which calls the RISC Zero verifier to confirm the proof before accepting the state transition. This architecture allows rollup teams to write their STF (state transition function) in ordinary Rust rather than a ZK-specific language. Taiko and other EVM rollup projects have experimented with RISC Zero as a proving backend for their zkEVM approach.
​

ZK coprocessors use Steel and Bonsai to bring historical Ethereum data into live contracts. A smart contract that needs to verify a user's average balance over 90 days, or prove that a specific Uniswap price never exceeded a threshold during a given window, would traditionally require either an oracle (which introduces trust) or onchain computation (which is prohibitively expensive for 90-day windows). A ZK coprocessor reads the historical state via Steel, generates a receipt proving the computation, and delivers it to the smart contract as a verified result. Axiom, a competing ZK coprocessor project, uses a similar model with its own proving stack.
​

Verifiable credentials and identity proofs represent a third category. A user who wants to prove membership in a set (KYC-compliant jurisdiction, minimum balance, DAO governance tier) without revealing their identity can generate a RISC Zero proof that their private input satisfies the membership predicate. The smart contract verifies the receipt, not the raw data. This is architecturally equivalent to ZK identity proofs built on specialized circuits (like Semaphore or Noir-based stacks), but RISC Zero's advantage is that developers use Rust standard libraries rather than custom constraint systems.
​

As of Q1 2026, RISC Zero competes primarily with SP1 from Succinct Labs, Nexus zkVM, and Jolt from a16z crypto. Each targets the same developer audience (Rust developers who want ZK proofs without writing circuits), but they differ in proving system, performance benchmarks, production maturity, and ecosystem integrations. The table below summarizes the key dimensions.
​

SP1, released by Succinct Labs in late 2023, is RISC Zero's closest competitor. Both use RISC-V and target Rust developers. SP1 uses Plonky3, a proving system developed by Polygon and contributed to as open infrastructure, while RISC Zero uses its own STARK construction. In public benchmarks from the zkvm-benchmarks repository maintained by Succinct Labs (as of Q1 2026), SP1 reported faster proving times on several Fibonacci and SHA-256 benchmarks, while RISC Zero reported lower memory usage on large programs. Independent benchmarks vary; teams evaluating both should run their specific guest program on both systems rather than relying on published comparisons.
​

Jolt, from a16z crypto research, uses a fundamentally different architecture based on Lasso lookups rather than traditional STARKs or SNARKs. The academic paper (eCrypt 2023/1217) argues Lasso achieves better prover performance on specific circuit types. Jolt is in active research and early development as of Q1 2026, without a production cloud service. Nexus takes a folding-scheme approach (based on Nova, developed at Microsoft Research) which is better suited to recursive proving of long computations but remains in testnet phase.
​

RISC Zero functions as a proving backend for ZK rollups, meaning rollup developers write their state transition logic in Rust, run it inside the RISC Zero zkVM, and use the resulting receipt as the validity proof submitted to Ethereum. This approach is called a "zkVM rollup" or "programmable validity proof" model, distinct from purpose-built zkEVMs like Scroll or Linea that build ZK circuits specifically for the EVM opcode set.
​

The trade-off is proving overhead versus development simplicity. A purpose-built zkEVM that proves EVM execution step-by-step (Type 1 zkEVM in Vitalik's zkEVM classification) has high circuit complexity but proves the exact same execution environment developers already know. A RISC Zero-based rollup proves RISC-V execution of a Rust-implemented EVM, adding one layer of abstraction. The proving overhead from this abstraction layer is partially offset by the maturity of the Rust toolchain and the absence of hand-optimized ZK circuit work.
​

For cross-chain applications and rollup settlement, RISC Zero's Steel library enables a class of applications called ZK light clients. A ZK light client generates a receipt proving that a block header on one chain is valid and that a specific state commitment is included in that block. The receiving chain verifies the receipt without running its own full node for the source chain. Several bridge and interoperability protocols are exploring RISC Zero-based light clients as a trust-minimized alternative to optimistic fraud-proof bridges.
​

Understanding cryptographic proofs more broadly is useful context for evaluating zkVM claims. The distinction between interactive and non-interactive proofs, and between knowledge-soundness (ZK) and computational soundness (just SNARKs), affects the security claims each zkVM makes. RISC Zero's receipts are succinct non-interactive arguments of knowledge (SNARKs) after the Groth16 wrapping step, which provides computational soundness under standard cryptographic assumptions.
​

RISC Zero primarily supports Rust, which compiles to the RISC-V target the zkVM executes. Any language with a RISC-V compiler backend, including C and C++, can in principle run inside the RISC Zero guest, though the toolchain and standard library support is best for Rust. Solidity cannot run directly inside the RISC Zero guest; it requires an EVM interpreter written in Rust.
​

As of Q1 2026, Bonsai is available under a paid API model with a free tier for development and testing. Pricing is based on proving cycles consumed. Teams running production workloads pay per million RISC-V cycles proved. RISC Zero's pricing page at dev.risczero.com/api/bonsai has current tier information.
​

Yes. The Steel library lets a RISC Zero guest program read verified Ethereum state from any historical block. The guest uses eth_getProof Merkle proofs to confirm the state data is legitimate, then runs arbitrary Rust logic against that state. The resulting receipt proves both that the computation was correct and that it ran against real Ethereum state, verifiable by any smart contract that calls the RISC Zero verifier.
​

zkSync is a full rollup product: it provides a complete EVM-compatible chain with its own sequencer, bridge, and ecosystem. RISC Zero is a proving infrastructure layer that rollup developers use as one component. A team could build a rollup using RISC Zero as the prover, zkSync's Boojum proof system, or any other proving backend. RISC Zero does not operate a public chain itself.
​

A zkEVM generates proofs specifically for Ethereum Virtual Machine execution, proving that EVM opcodes ran correctly. A zkVM is more general: it proves execution of a given instruction set (RISC-V in RISC Zero's case), which may include an EVM interpreter implemented in Rust, or any other program. zkEVMs are purpose-optimized for EVM compatibility; zkVMs offer more flexibility at the cost of additional abstraction.
​

RISC Zero removes the constraint that computationally expensive logic must run inside the EVM. Smart contract developers have historically faced a trade-off: complex computations are either done onchain at high gas cost, done offchain with no verifiability, or delegated to oracles that introduce trust. RISC Zero adds a fourth option: compute offchain in Rust, generate a receipt, and verify the receipt onchain for a flat, predictable gas cost independent of the computation's complexity.
​

The gas cost of RISC Zero verification on Ethereum is approximately 200,000-300,000 gas for the Groth16 verifier call, regardless of how many cycles the guest program executed. A 10-million-cycle computation and a 1-billion-cycle computation both cost roughly the same to verify. This is the core economic value proposition: move complexity out of the EVM without sacrificing verifiability, and pay a fixed verification cost rather than a proportional one.
​

Consider a smart contract that implements a lending protocol wanting to price collateral based on a time-weighted average price (TWAP) calculated over 30 days of onchain data. Computing a 30-day TWAP for 1,440 data points inside the EVM would consume hundreds of millions of gas. The same computation as a RISC Zero guest program reads all historical price data via Steel, computes the TWAP in Rust, and produces a receipt that the lending contract verifies in a single 250,000-gas call. The protocol pays a 250,000-gas verification fee instead of an infeasible computation fee.
​

RISC Zero's proving architecture also opens options for more complex protocol logic. Governance systems that need to count delegated votes across historical snapshots, prediction markets that need to settle against onchain historical outcomes, and cross-chain protocols that need to verify another chain's state all fit this pattern. The common thread is computation that is cheap to express in Rust but expensive or impossible to express in Solidity.
​

The developer experience has improved significantly from RISC Zero's 2021-era tooling. The current zkVM 1.0 release, launched in Q4 2024, standardized the receipt format, introduced a stable verifier contract address on Ethereum mainnet, and added tooling for Foundry-based Solidity development workflows. Teams building on RISC Zero now use Cargo for the guest code and Foundry for the Solidity integration, with the RISC Zero Foundry template providing a project scaffold that handles the cross-language build pipeline.
​

RISC Zero's primary limitations are proving latency, prover hardware cost, and the trust assumptions of its proving system. While the verifier is trustless and the receipts are cryptographically sound, the current proving pipeline has practical constraints that teams must evaluate before committing to it as production infrastructure.
​

Proving latency is the most immediate constraint. As of Q1 2026, generating a proof for a moderately complex computation (10-50 million RISC-V cycles) on Bonsai takes between 30 seconds and several minutes depending on parallelization. Applications that require sub-second proof availability, such as high-frequency trading or real-time MEV protection, cannot use RISC Zero's current proving speed. Competing approaches like optimistic execution with fraud proofs or simpler SNARK circuits remain faster for latency-sensitive use cases.
​

The Groth16 SNARK wrapper that RISC Zero uses for onchain verification requires a trusted setup, a one-time ceremony where multiple parties generate toxic randomness that must be discarded. RISC Zero conducted its Groth16 trusted setup ceremony in 2024 with multiple independent participants. A fully trustless alternative would use a transparent proving system (like STARKs directly on-chain), but STARK proofs are too large for efficient Ethereum verification today. The Groth16 ceremony is a pragmatic compromise widely used in the industry; teams with extreme trust minimization requirements should evaluate whether the ceremony's participant set is sufficient.
​

Memory constraints on the RISC-V guest are another practical limitation. Programs that require more than a few gigabytes of working memory may not fit in a single proving segment and require Continuations, which introduces complexity. Cryptographic operations that are efficient in native RISC-V code (like SHA-256) are proven cheaply; operations that require custom arithmetic circuits (like elliptic curve pairings used in many ZK proof systems) are expensive to prove because they run as general RISC-V instructions rather than hardware-accelerated operations.
​

RISC Zero has shipped accelerated precompiles for common cryptographic operations, including SHA-256 and Keccak-256, that run as efficiently as hardware instructions within the proving system. As of Q1 2026, the accelerated precompile list covers the most common cryptographic primitives needed for blockchain applications. Teams that need operations not yet accelerated must evaluate whether the proving cost fits their application's economics.
​

Sources and methodology. RISC Zero funding and founding details verified against the company's Series A announcement. GitHub star counts and proving benchmarks sourced from public repositories as of Q1 2026. zkEVM type classifications reference Vitalik Buterin's zkEVM classification post. Competitor status verified against published documentation and GitHub activity as of Q1 2026.
​