Security Model
RISC Zero is proud to offer an endtoend solution for verifiable computation. Users can generate proofs for correct execution of software code using the RISC Zero zkVM, and they can verify those proofs onchain using our permissionless verifier contract on Ethereum networks such as Sepolia.
The rest of this document offers an overview of the security model for applications that rely on RISC Zero's tooling.
RISC Zero offers the following components, each of which is ready for use on testnet.
Overview of Components

The cargo risczero tool, which compiles userwritten Rust code into RISCV ELF binaries deterministically.

The RISCV Prover, which executes and proves ELF binaries produced by the
cargo risczero
tool. 
The Recursion Prover, which is used to aggregate proofs from the RISCV Prover. The recursion prover supports a small number of programs, including lift, join, and resolve. Each recursion program is identified by a control ID, and the full list of allowed programs is identified by the control root.

The STARKtoSNARK Prover, which verifies proofs from the RISC Zero Recursion Prover, compressing the STARK into a Groth16 SNARK. The control root is passed to as a public input, allowing for updates to our RISCV Prover without requiring a new trusted setup ceremony.

The onchain verifier contract, which verifies proofs from the RISC Zero STARKtoSNARK Prover. The control root is hardcoded into the onchain verifier contract. Addresses for the onchain verifier contracts we have deployed are available in our verifier contract documentation, and a detailed description of the options for governance, upgrades, and deprecation are available in our Version Management Design doc.
Together, these components allow developers to integrate proofs of arbitrary Rust code into their onchain applications. In order to use these components, developers provide:
 the Rust code for their zkVM guest program.
 a smart contract onchain whose behavior will depend on the output of the Verifier Contract
RISC Zero technology cannot prevent many types of security issues in user guest programs (e.g. applications) or contracts. It is necessary for zkVM adopters to validate the security of guest programs and contracts. This includes secure development lifecycles and external security auditing by qualified providers.
ZeroKnowledge Proving
The RISC Zero zkVM hides all program inputs and all witness data, and targets perfect zeroknowledge.
Nevertheless, we have not written a mathematical argument to prove that our system is zeroknowledge. We are working on some minor engineering changes in order to make it easier to prove that our proof system has perfect zeroknowledge.
We urge those with critical privacy requirements to take caution until the necessary changes have been implemented.
We also point out the following caveats with respect to privacy:
Whoever is generating the proofs can see the secret data. Users may choose to use any of these provers locally to ensure their data stays private.
Proofs generated by the RISCV Prover that haven't been passed through the Recursion Prover leak information about the length of execution. Passing proofs through the Recursion Prover resolves this warning: recursion proofs leak no information about execution length.
Cryptographic Security
In analyzing the cryptographic security of our system, we consider two primary questions:
 Can a malicious user who doesn't know a valid execution trace for the given receipt claim create a fake proof that will trick the verifier?
 Can a malicious user extract secret information from a proof posted onchain?
The first question is about the soundness of the protocol, and the second question is whether the protocol is zeroknowledge.
Soundness is often quantified in terms of “bits” — our system currently targets 98 bits of security.
Prover  Cryptographic Assumptions  Bits of Security  Quantum Safe? 

RISCV Prover   Random Oracle Model  Toy Problem Conjecture  98  Yes 
Recursion Prover   Random Oracle Model  Toy Problem Conjecture  99  Yes 
STARKtoSNARK Prover   Security of elliptic curve pairing over BN254.  Knowledge of Exponent assumption  Integrity of Groth16 Trusted Setup Ceremony  99+  No 
The Toy Problem conjecture, specified in detail in the ethSTARK documentation, says that the best known attack on STARK proof systems is the best possible attack.
The STARK Provers
The RISCV Prover and the Recursion Prover both use STARKbased protocols, which are not known to be vulnerable to attacks via quantum computers.
How secure are the STARK Provers?
We estimate that it would take approximately 400,000 years to brute force a collision against our STARK protocol using GPUs in a parallel attack, using 1 million highend GPUs.
 Currently, we look to the RTX 4090 as a highend reference GPU.
 RTX 4090 benchmarks provide a reference SHA2256 hashrate at less than 25,000 million hashes per second.
 We have seen several examples of large purchases of GPUs on the order of 350,000 so we conservatively suggest that a distributed attacker may be able to operate 1 million RTX 4090s in parallel.
At $2^{98}$ bits of security required to force a collision, we can estimate the time to brute force a collision as follows:
2^98 / (25,000,000,000 Hashes/s * 1,000,000 GPUs) / 60seconds / 60 minutes / 24 hours / 365 days = 401969 years
The analysis for bits of security for the RISCV and Recursion Prover can be found in the security calculator. For a detailed cryptographic description of our STARK system, we refer readers to RISC Zero zkVM: Scalable, Transparent Arguments of RISCV Integrity.
The STARK to SNARK Translator
The STARK to SNARK translator uses a Groth16 prover over the BN254 pairingfriendly curve. The security of this part of the protocol depends on elliptic curve cryptography, and is therefore vulnerable to attacks from quantum computers.
How secure is the STARK to SNARK Prover?
The best known attack vector against our STARK to SNARK Prover is to attack the underlying elliptic curve pairing used with BN254. This primitive has been heavily battletested: it's part of the core cryptography on Zcash and it's included as a precompile on Ethereum (see EIP197).
For a detailed discussion of the security of BN254, we refer readers to the discussion on this GitHub issue from Zcash.