This page lays out ZisK's trust model. The host and executor live in the untrusted zone outside the proof, while the compiled ROM, proving key, minimal trace, and public outputs are what the proof attests to. It details what each actor does, how the constraints bind the witness to the program, what the inputs and hints channels mean, where audit responsibility for the guest sits, and what a verifying proof precisely guarantees.
Host & guest
The proving pipeline page walked through the six lifecycle stages of a ZisK proof from the outside. This page opens up what those stages actually operate on: the three zones that produce and verify a proof and the trust boundary between them.
The host orchestrates the entire pipeline from outside the proof. The executor runs the guest program and produces the minimal trace the prover signs off on. The guest is the compiled program whose execution the proof actually attests to. The trust boundary between these three actors is the most important mental model in ZisK: get it clear and most of the rest of the system follows from it.
The trust boundary
ZisK draws a sharp line between what the proof system constrains and what it does not. The diagram below shows the split at a glance; the sections that follow take each actor and each data channel apart in detail.
The top box (host and executor) is the untrusted zone: the proof system makes no claim about anything that happens there. The bottom box is the trusted zone. What the proof actually attests to. The witness, drawn as the green arrow crossing the boundary, is the bridge between them. The constraints inside the proof bind that witness to the compiled ROM, so a fraudulent witness would have to break the underlying cryptography to produce a verifying proof.
The untrusted zone
The untrusted zone is everything outside the proof's domain. The proof system makes no cryptographic claim about anything that happens here — the components in this zone are taken as given, their behaviour is not constrained, and any data they supply must be checked by the guest before the application relies on it. Two actors live in this zone:
| Actor | Role |
|---|---|
| Host | Orchestrates the entire proving pipeline (build, setup, prove) and supplies the runtime data streams. |
| Executor | Runs the guest program and produces the minimal trace that the prover signs off on. |
Both are detailed below.
The host
The host is the process that runs the proving pipeline from outside the ZKVM. It is ordinary code that orchestrates the proving pipeline from start to finish. Nothing the host does is constrained by the proof system; the proof's domain begins only at the point where the guest's execution starts.
The host's job is to drive three distinct activities, in order:
| Stage | What the host does | What comes out |
|---|---|---|
| Build | Compiles the guest source (Rust or C) into a standard RISC-V ELF binary using the customised ZisK toolchain (essentially stock LLVM/Rust with a different linker script and ROM/RAM address ranges). | A RISC-V ELF. |
| Setup | Takes the compiled ELF, runs a static transpiler to convert RISC-V instructions into ZisK-ISA instructions, prepares the program ROM and precomputes the proving key and the matching verification key. | The ROM, the proving key, the verification key. |
| Prove | Hands the proving key, the input stream, and (optionally) the hint stream to the executor; the executor runs the guest and produces the witness (minimal trace); the proving stage turns this witness into a STARK proof. | The proof and the public values. |
Beyond those three stages, the host is also responsible for two runtime streams: the input stream (the bytes the executor will read when it runs) and the hint stream (optional non-deterministic data used to accelerate minimal trace generation).
After proving, the host is also where verification happens, and where the application reads public outputs and decides what to do with them. The host is, in effect, the entry and exit point of the entire system.
The exectuor
The executor steps through the guest program instruction by instruction and emits the minimal trace, which becomes the witness the prover signs off on. It is untrusted by the proof system, the constraints inside the proof check every row against the program, so a buggy or malicious executor cannot produce a verifying proof of an invalid trace. The executor consumes:
| Input | Source | Role |
|---|---|---|
| Compiled ELF | Setup output | The program the executor runs, instruction by instruction. |
| Input stream | Host | The bytes the guest will read at runtime. Copied into the input-data region before execution begins. |
| Hint stream | Host (optional) | Non-deterministic helper data the executor consumes to skip expensive witness computations. |
The output is the minimal trace: every instruction executed, every memory access, and every public value committed. It is "minimal" because each chip records only the rows for the operations it actually handled, no padding to a worst-case length.
The executor also writes non-deterministic witness values that the constraints verify without recomputing. Division is the canonical example: the executor writes the quotient q and remainder r into the precompile's witness, and the chip's constraints check q · b + r = a with r < b which is far cheaper than encoding a long-division circuit. The pattern is the same shape as host-supplied hints, but the values come from the executor itself rather than from the hint stream.
Finally, the executor plans how the trace will be partitioned per chip and per segment. That plan is what the prove stage consumes: workers just take their assigned segments and start proving.
Two emulator implementations exist (Assembly and Rust). The pipeline page covers them in detail.
The trusted zone
The trusted zone is everything inside the green dashed box in the diagram — the part of the system whose behaviour the proof actually attests to. Four components live here:
| Component | What it is |
|---|---|
| Compiled ROM | The canonical representation of the guest program. Produced by setup and committed byte-for-byte by the verification key — the proof is anchored to this exact program. |
| Proving key | The precomputed cryptographic material the prover needs to generate proofs of this specific program. Produced by setup; a parameter, not a trust anchor — the wrong PK simply fails. |
| Minimal trace | The row-by-row record of the guest's execution. Produced by the executor; every constraint in the proof talks about a row in this trace. |
| Public outputs | The values the guest explicitly commits during execution. The only thing about the run a verifier ever sees. |
The core safety property of the proven zone is that the witness must be a valid execution of the ROM. Three independent constraint families enforce this at the same time, so a forged witness would have to satisfy all three at once while diverging from a real execution, a contradiction the STARK's soundness rules out.
| Constraint | What it checks |
|---|---|
| ROM lookup | At every step, the Main chip looks up the instruction at the current program counter in the committed ROM. A row whose instruction does not match has no valid lookup. |
| Memory consistency | Every memory read must observe the most recent prior write to the same address. The Memory chip orders accesses globally and rejects out-of-order or fabricated reads. |
| Per-chip AIR | Each chip (base operations, precompiles, lookup tables) enforces its own AIR constraints on its own trace rows. Local invariants are checked alongside the global ones. |
Precompiles get the same treatment. Each precompile is its own chip with its own AIR, and every precompile call recorded in the Main trace must match a row in the precompile chip's trace via the Operation Bus, so a precompile is just as proven as a base instruction. Non-deterministic values the executor wrote into a precompile's witness (e.g. the q and r of a division) are verified by the chip's constraints.
The proof attests to what the compiled program did, not to whether what it did is correct or safe. The proven zone guarantees that the exact ROM ran, that memory was used consistently, that every precompile call matched its chip, and that the public outputs are the ones the guest committed. It does not guarantee that the program is well-written or that the inputs were meaningful.
A realistic application therefore has to assume that the guest's logic checks the properties it cares about and commits them through public outputs. The audit responsibility for the guest's source code, and for what the application requires of it, sits outside the proof.
:::info The trust statement, precisely
Given a verification key that pins the guest, and a proof that verifies against that verification key, the verifier knows that some witness exists which corresponds to a valid execution of the ROM and produced exactly certain public outputs. No more, no less. :::
The guest program
The guest is the compiled program whose execution the proof attests to. It is the only actor whose behaviour the proof actually constrains: the host orchestrates and supplies, the executor runs and produces a trace, but only the guest's instructions, memory accesses, and committed outputs are checked by the constraint system.
What the guest is
The guest starts life as Rust or C source code, gets compiled into a standard RISC-V ELF, and is then transpiled at setup time into ZisK's own ISA. The resulting program ROM is hashed into the verification key, so the proof is always anchored to one specific compiled binary; a single byte's worth of difference in the ELF produces a different verification key.
How the guest runs
The guest is a deterministic state machine. At every step, the VM fetches the instruction at the current program counter, decodes it, reads its operands, applies the operation, writes the result, and advances. The guest state is fully determined by the program ROM and the host-supplied data; given the same ROM and the same inputs, the guest produces the same trace every time.
Execution to generate the minimal trace is strictly sequential. There are no threads, no concurrency primitives, and no interrupts. The only way an instruction can be skipped or replayed is through the normal control flow of the program itself and every transition shows up in the minimal trace.
What the guest can read and write
The guest interacts with state at runtime through a fixed set of channels:
| Channel | Access | Notes |
|---|---|---|
| Program ROM | Read-only | Looked up at every instruction fetch; committed by the verification key. |
| Input region | Read-only | The executor fills it from the host's inputs before execution begins. |
| System region & program memory | Read/write | General-purpose RAM the guest uses for its own state. |
| Output region | Write | The only channel whose contents the verifier eventually sees. |
Outside these channels, the guest has no I/O: no file system, no clock, no network.
Where the audit responsibility lies
The proof attests to what the compiled program did, not to whether what it did is correct or safe. The guest's source code is therefore where the application's correctness ultimately lives:
- A buggy guest produces a verifying proof of the bug.
- A guest that consumes an input without verifying its provenance attests only to "the program processed something", not to whether that something was meaningful.
- A guest that skips a critical checks produces a proof that says nothing about that omission.
The verification key tells a verifier which program produced the proof; it does not tell them whether that program does the right thing. That part remains the application owner's responsibility. Audit the guest source the same way you would audit any other security-critical code, because a verifying ZisK proof gives you a precise cryptographic answer to "did this program execute correctly?" and nothing about "is this program one you should trust?"
The host program
The host is the ordinary code outside the proof that drives the entire proving pipeline. It is "untrusted by convention": the system trusts the host to invoke the pipeline correctly, but the proof itself never depends on the host being honest. Anything the host does is outside the proof's domain, and only what the guest explicitly commits ends up in the verifiable surface.
The host supplies data through two distinct channels and reads results from two distinct artifacts. Both data channels are host-supplied byte streams, but they play very different roles inside the proof:
| Channel | Purpose | How the proof treats it |
|---|---|---|
| Inputs | Feed the program the values it needs to run. | Committed by the proof system: the prover cannot retroactively change what the guest read. |
| Hints | Supply pre-computed values the executor uses to skip expensive witness work. | Unconstrained: the proof system makes no claim about hint values unless the guest or a precompile chip explicitly verifies a property of them. |
Provisioning inputs
The host is responsible for provisioning every value the guest will read at runtime via the input stream. The host serialises values or raw bytes into this buffer, which is loaded into the guest's input-data region. From then on the region is read-only, and the guest accesses input values through ordinary memory reads whenever its code needs one.
Three properties of the input stream are worth being precise about:
| Property | What it means |
|---|---|
| Private by default | Input bytes are part of the execution witness, not public proof data. The verifier does not see them unless the guest explicitly commits them as a public output. |
| Constrained | Although the verifier doesn't see the bytes, the proof still commits to them: the prover cannot retroactively change what the guest read. The proof attests that the guest ran on those bytes. |
| Untrusted in origin | The host supplies the bytes. The proof system makes no claim about their provenance or correctness. If the guest needs to trust an input value, the guest must verify it. |
Provisioning hints
Hints are precomputed results that the executor substitutes into the witness in place of operations it would otherwise have to run itself. The guest program emits hint requests describing the operation and its inputs; a native pipeline runs those requests in parallel — outside the zkVM — and streams the results back to the executor, which uses them directly when building the minimal trace. The zkVM's constraints still verify that each precomputed result is correct, so hints only change how the witness is built, never what the proof attests to.
Hints are supported only with the Assembly executor and require a hint-aware setup. Three properties make them what they are:
| Property | What it means |
|---|---|
| Unconstrained | The proof system makes no claim about hint values on their own. The constraints check the relation the result is supposed to satisfy, not the bytes the host supplied. |
| Outside the proof | Hints only affect how the executor builds the minimal trace. The proof's correctness depends on the constraints catching any mismatch, not on the host being honest. |
| Performance-only | Hints accelerate witness generation. They never change the security model or what the proof attests to. |
Hints accelerate; they do not bypass. If the relation a hint is supposed to satisfy is never checked, by a precompile chip's constraints or by guest code, the resulting proof says nothing about whatever the hint was supposed to represent.
Reading the result
After proving completes, the host receives two artifacts: the STARK proof itself and the public values the guest committed during execution. What the host does with them is application logic. The proof system is finished at this point. but the common operations are:
| Action | What the host does |
|---|---|
| Verify locally | Run the verifier against the proof and the verification key produced by setup. Verification is deterministic and cheap; a passing check means the proving pipeline produced a cryptographically valid attestation. |
| Read public values | Pull the committed bytes out of the proof's public-values region. These are whatever the guest committed via the public-output instruction, the only thing the application logic downstream ever sees. |
| Forward the proof | Pass the proof to a third party (an on-chain verifier, an aggregator, a service consuming the result). For on-chain verification, the host can apply a SNARK wrap first to keep verification cheap. |
The host does not have access to anything the guest chose not to commit. Even though the host runs on the same machine as the executor and could observe intermediate state during proving, that information has no cryptographic standing. Only the guest's commitments become part of the verifiable surface, and that surface is what the host and any downstream verifier are limited to.
Why this matters in practice
The host/guest split shapes how ZisK programs are structured:
| Principle | Consequence |
|---|---|
| Anything that doesn't need to be proven goes in the host. | Reading a config file, fetching data, formatting output — all host-side, no proof cost. |
| The guest receives exactly the values the proof needs to attest to. | Smaller surface = cheaper proof, less to audit. |
| Hints are an optimisation, not a security model. | Use them to skip expensive computations the guest can verify; never to trust the host on a security-critical value. |
| What the verifier learns is exactly the public outputs. | Plan public outputs carefully: a verifier with the proof and VK learns the public outputs and nothing else. |
| The proof attests to what the compiled binary actually does. | A well-typed but buggy guest will produce a verifying proof of the bug. The compiled binary needs the same auditing as ordinary code. |
The punchline: host-supplied data is private and untrusted by default; only committed public outputs become verifier-visible. The guest's job is to convert "untrusted-but-supplied" into "verified-and-attested" by committing the smallest public statement the verifier needs.
Where this picks up
You now know what the guest sees, what it doesn't, and where the trust boundary actually lives. The next page, Components, opens up the prover side and shows what's actually inside the zkVM that produces the proof: the chips that execute instructions, manage memory, and run the expensive primitives.