RISC Zero

• Name: RISC Zero
• URL: https://risczero.com/
• Category: zkVM implementation steward / proving-service operator / prover-network company
• Tags: ethereum-ecosystem
• Summary: RISC Zero belongs in companies/ because the practical control surface is not just there is a zkVM or there is a prover market. A named company stewards the Rust toolchain, docs, security model, repository, and the migration path between local proving, the retired Bonsai hosted service, and the newer Boundless proving market. That company boundary matters whenever the real question is who decides the default developer workflow for generating proofs, which proving mode stays supported, and how much of the proving stack is still company-shaped even when some pieces are open source or marketed as decentralized?
• What it does:
  • Stewards the RISC Zero zkVM implementation, Rust-first toolchain, documentation site, and public repositories developers rely on to build verifiable-compute applications
  • Packages the default developer workflow around guest compilation, receipt generation, verifier integration, and the surrounding install / upgrade path through rzup, cargo risczero, and official docs
  • Formerly operated Bonsai, a centralized remote proving service that exposed API-keyed proof generation and quota-governed service policy
  • Now pushes developers toward Boundless as the decentralized proving marketplace and positions that network as the replacement for production remote proving
  • Maintains the primary product and documentation shell tying together the zkVM, proof-system/security framing, historical hosted proving, and the newer prover-market stack
• Key claims:
  • The RISC Zero homepage frames the company around verifiable computation, promising that users can be cryptographically certain computation outputs are correct and verify them much faster than recomputing everything themselves
  • The main risc0 repository README describes RISC Zero as a zero-knowledge verifiable general computing platform based on zk-STARKs and the RISC-V microarchitecture, and points developers to the company-run docs and installer flow via rzup and cargo risczero
  • The current remote-proving docs say Boundless is the path for generating proofs without users running their own hardware, describing it as a decentralized proving marketplace with permissionless provers
  • The Boundless migration docs say Bonsai was RISC Zero's centralized proving service, that it became unavailable in December 2025, and that Boundless is intended to replace it for proving workloads
  • That same migration guide makes the operator boundary unusually legible: Bonsai depended on simple API credentials and offchain proof delivery, while Boundless introduces wallet-funded onchain requests, storage-provider setup, market routing, and asynchronous fulfillment
  • Together, those materials show that RISC Zero is not just a neutral research label over a static protocol. It is the implementation and migration steward that has already moved developers across materially different proving-control surfaces
• Whitepaper: No standalone company whitepaper is the important artifact here. The strongest primary materials are the official site, zkVM / remote-proving docs, the Bonsai-to-Boundless migration guide, and the public repository README; see ../whitepapers/risc-zero-company-primary-sources-2026-08-09.md.
• Sources:
  • https://risczero.com/
  • https://dev.risczero.com/api/generating-proofs/remote-proving
  • https://docs.boundless.network/developers/tutorials/bonsai
  • https://github.com/risc0/risc0
  • https://raw.githubusercontent.com/risc0/risc0/main/README.md

Internal linkages

• Project-layer zkVM note: risc-zero.
• Historical centralized proving surface: bonsai.
• Decentralized proving-market surface: boundless.
• Useful proving-stack comparison: succinct-labs and succinct.

Protocol / company boundary

• risc-zero stays the right project-layer note for the zkVM, receipts, verifier path, and broad verifiable-compute architecture.
• This company note isolates the implementation and operating boundary where release stewardship, toolchain packaging, docs authority, proving-service availability, migration guidance, and the supported remote-proving path are decided.
• bonsai and boundless should stay as distinct product / service notes because they describe different proving modes and market structures, but the company note is the cleaner place to reason about who moved the stack from one mode to the next.
• The analytical question here is not just how does the zkVM work? It is which organization decides the default proving workflow developers inherit, and how much of that workflow still depends on company-run tooling, guidance, and service choreography?

Control surface

• Practical leverage sits in toolchain stewardship, documentation authority, release cadence, installer flow, security framing, and the migration guidance that nudges developers from local proving to hosted or market-based proving paths.

• The Bonsai-to-Boundless transition is the clearest evidence that this company boundary matters: RISC Zero already changed the default production proving path from API-keyed centralized service usage to a different architecture with wallets, storage providers, market bidding, and onchain fulfillment.

• Even when parts of the stack are open source or described as permissionless, many teams will still inherit RISC Zero’s chosen docs, repos, examples, and upgrade path. That is enough to make the entity boundary analytically useful.

• Last reviewed: 2026-08-09 UTC