Overview

This page introduces ZisK as a STARK-based zkVM that proves the correct execution of RISC-V programs while keeping a familiar Rust/C model. It covers the kinds of applications this unlocks, the four formal guarantees a ZisK proof carries (soundness, completeness, succinctness, zero-knowledge), and a worked example of the trust boundary — what you are and are not trusting when you verify a proof.

What is ZisK

ZisK is a STARK-based zero-knowledge virtual machine (zkVM) that executes programs compiled from standard instruction set architectures and produces succinct, transparent proofs of their correct execution. ZisK targets the RISC-V ISA, allowing developers to keep a familiar Rust/C programming model while building through the ZisK toolchain.

ZisK's modular architecture enables the addition of optimised constraint systems for expensive operations such as elliptic-curve arithmetic and bulk memory access, making it practical to prove complex computations at scale.

What it unlocks

Recent advances in zero-knowledge proof systems make it possible to verify the correct execution of arbitrary computations without revealing private inputs, and to do so in time and space sublinear in the original computation. ZisK is built to make applications practical at production scale. Examples include, but are not limited to:

Application	Summary
ZK Rollups	Layer-2 chains posting a single proof of millions of transactions instead of replaying every transaction on Layer-1.
Verifiable co-processors	Off-chain workloads such as large-state reads or complex business logic, whose output a smart contract can trust without re-running them.
Trustless bridges	A chain consumes a ZK proof of another chain's state directly with verification handled by the proof system rather than by a multisig committee or oracle.
Off-chain computation	Services that publish proofs of their outputs alongside the outputs themselves, so third parties can confirm the computation happened correctly without re-executing it.
Privacy-preserving computation	The guest operates on private inputs but reveals only the outputs it explicitly commits, letting a verifier confirm the result of a computation without ever seeing the underlying data.

What it guarantees

A ZisK proof carries four formal guarantees inherited from the underlying STARK proof system. They are the shorthand the rest of the docs uses for what a valid proof actually means:

Property	What it means
Soundness	A verifier cannot be tricked into accepting a proof of a computation that did not actually run that way. The prover cannot fake a result without breaking a cryptographic assumption.
Completeness	Every honest execution can be proved. If the guest ran correctly, the prover can always produce a proof a verifier will accept.
Succinctness	The proof and the verification cost are small and roughly independent of the original computation's size.
Zero-knowledge	The proof reveals nothing about the inputs beyond what the guest explicitly committed as public outputs. Private inputs stay private even though their effect on the outputs is verifiable.

These properties are formal statements about the cryptography. What they buy you in practice depends on a specific trust boundary; what you actually have to trust for a proof to be meaningful, and what you do not. It helps to walk through this with a concrete scenario rather than in the abstract.

Imagine someone publishes a program together with a proof that they ran it on a specific input. You want to confirm the ouput is correct without re-running the computation yourself, and without ever seeing the underlying inputs. So, what can the proof actually tell you?

If verification succeeds, you know:

• The exact compiled program was executed.
• It produced the public outputs that came with the proof.

For those conclusions to hold, the trust boundary looks like this:

You are trusting	You are not trusting
The underlying cryptography. Well-studied and independently audited primitives, not specific to ZisK.	The prover. Soundness guarantees that a verifying proof can only come from an honest execution, regardless of intent or hardware.
The source code and the compiler . A proof attests to one specific binary; the source still needs auditing, and the standard Rust/LLVM toolchain is itself auditable.	The integrity of the proof in transit. A proof is cryptographically self-validating, so any modification invalidates it.
The provenance of the inputs. A proof shows the program ran on some input, not that it is authentic; validating it is the program's responsibility.	—

Notice that based on previously stated properties you have confirmed the output of a program without re-running it and without ever seeing its inputs. Two out of the four formal properties from the table above made that exchange possible:

Property	How it showed up here
Succinctness	Verifying the proof was cheaper than running the program; that is what let you skip the re-execution entirely.
Zero-knowledge	The inputs stayed with the prover. You saw only the public output the program explicitly committed.

Where to go next

If you are reading this section in order, Background and Why ZisK continue the introduction with the historical context and the design principles that follow from it.

To see how the system actually works end to end, How ZisK works covers the pipeline, the host/guest model, the chips, and the scaling story.