How the zkVM works

Read this page to understand the machine behind every proof on Rand: what it proves, how a run of a program becomes something a validator can check in milliseconds, and where the privacy comes from. For what a proof costs and how the wallet makes one, see Proofs. For the parameters and hash constructions, see Cryptography. For the instruction set a program is written against, see The RISC-V ISA.

The one statement every proof makes

The zkVM proves one kind of statement, for every program the chain runs:

A program whose digest is hc, started at base_pc, run on a private input committed to by H_IN and a public input segment committed to by H_PUB, halted within 2ᵗ − 1 cycles, spent at most GAS_LIMIT gas and wrote these eight output words.

A shielded transfer is that statement about one fixed program, the hidden-asset bundle guest, whose hc is pinned in the genesis file as hc_bundle. Since chain 17 it is made twice per transfer: a second, small proof about the auth guest (hc_auth in the genesis file) shows that the sender holds the spend key (Proofs); since chain 21 that second proof may instead be the multisig auth guest’s (hc_auth_multisig), which shows that enough of a hidden set of Dilithium2 keys signed, without telling which set or how many. A confidential call is the same statement about a deployed program. There is one machine, one verifier and one set of constraints for all of them. Deploying a program is therefore a data operation (store its words and hc), not a cryptographic one: there is no per-program circuit and no trusted setup.

The proof system is a STARK built with Plonky3. It needs nothing but a hash function: no setup ceremony and no elliptic curves, so it has nothing for Shor’s algorithm to break.

The pipeline

 secret input ──► run the program ──► execution trace ──► polynomials ──► commit ──► FRI ──► proof
 (keys,           (RV32IM emulator)   (nine tables,      (one per       (8× code,   (80 queries,
  notes, paths)                        one row per step)  column)        Merkle)     20-bit grinding)

 every validator:  recompute the challenges from the Merkle roots, open 80 random positions,
                   check the rules there  →  ≈ 16 ms

The top row runs once, on the sender’s machine, in about 100 seconds for a bundle and about 7 seconds for the authorisation proof beside it. The bottom row runs on every validator, from the public fields and the proof alone.

1. Run the program and write down everything

The machine is a 32-bit RISC-V processor: RV32IM minus FENCE, the CSR instructions and EBREAK (The RISC-V ISA). The prover first runs the program on an emulator and records one row per clock tick. The record is the execution trace. Anyone holding it could replay the run step by step; the rest of the scheme exists so that a verifier can be convinced the trace is right without holding it.

A program talks to the outside through eight syscalls and nothing else:

Note commitments, nullifiers and Merkle paths are not built into the machine. They are ordinary guest code that stages a domain-tagged message in memory and calls POSEIDON2. That syscall does not pad, so [a] and [a, 0] hash alike. The shipped guests call it on fixed-length messages only. A new program that hashes data whose length can vary uses POSEIDON2_LEN (The RISC-V ISA).

There is no abort

The processor has no instruction that refuses to finish, so a program cannot stop when a check fails. The bundle guest records the failure instead: each failed check ORs a 1 into a register called bad, and bad is the last word hashed into the output digest:

D = H(64; anchor, nf₀..₃, cm₀..₃, fee, burn_a, burn_r, burn_asset, time, c, bad)

c is the authorisation commitment that the auth proof also publishes (since chain 17; the digest of chains 14 to 16 had no c).

The chain never takes D’s preimage from the sender. It rebuilds the preimage from the transaction’s public fields, sets bad = 0 itself, hashes, and compares. A cheater can make a perfectly valid proof of a run in which a check failed, but that run printed H(…, 1), and the chain is looking for H(…, 0). Matching them needs a hash collision.

2. Split the trace into nine tables

One table describing a whole processor would be wastefully wide, so the trace is split into specialist tables, proved together as one batch:

Two more tables, keccak and sha256, are present only in a proof whose program called them, each at least 2⁷ rows when present; the bundle guest uses neither. Constraint set 9 (chain 21) adds a third optional table the same way, modq: one 1,024-row block per MODQ call, declared in a new header field, modq_log_height, and carried only by the multisig auth guest’s proofs; the cpu table gained the syscall’s columns, which is why every verifier key moved. The floor of 2⁷ rows on every declared table came with constraint set 7 (section 9).

The tier t is one of 10, 12, 14, 16, 18 or 20 and sizes the tables. Every bundle is proved at tier 14: a 16,384-row CPU table, of which the guest uses about 12,400. The auth guest runs 250 cycles at tier 10; the multisig auth guest 85,830 to 251,946 cycles at tier 18 for one to three signatures, with every height that depends on the count floored at three, so a 1-of-N spend looks like a 3-of-N one. The rest is padding, so a proof reveals which tier a program needed, never how many steps it took inside it (Tiers).

The memory table is what makes RAM checkable. Because it is sorted by address and then time, “a read returns the last value written to that address” becomes a rule between two adjacent rows.

3. Connect the tables with buses

How does the verifier know the sum the CPU used is the sum the ALU computed? Through buses. When the CPU needs an addition it sends a message (op, a, b, c); the ALU receives one message for each row it computes. The machine has seventeen buses:

The buses are checked with a logarithmic-derivative argument (LogUp). After the tables are committed a random value α is drawn, and each table keeps a running sum of ±1/(α − m) over the messages it sends or receives. The sums cancel exactly if and only if every message sent was received, the same multiset on both sides. One forged message leaves a residue that a random α exposes with overwhelming probability. The memory bus uses a close cousin, a multiset permutation check.

Each table publishes the final value of its running sum, its terminal, and the verifier checks that the terminals add up to zero. Through constraint set 6 a terminal was a checkable function of its table’s contents. Since constraint set 7 every table carries five extra columns and, on its first row, sends one random value and receives its neighbour’s on the BLIND bus. Each terminal moves by a uniform element of the challenge field, and the sum stays zero.

The digest and read buses are deliberately separate pairs. LogUp balances per message, not per consumer, so one shared bus would let a prover drop a word from the digest while a read of that word still succeeded.

4. Anchor the trace to the outside world

Thirty-five public values leave the trace, all in the CPU table:

Because hc is computed in circuit, a proof about a different program cannot pass as a proof about the bundle guest. The verifier never sees an instruction word; it compares hc with the digest it expects. Because H_IN is salted, it binds the private input without revealing it, even to someone who could guess it. Because H_PUB is unsalted, the verifier can recompute it from words it already has. For a bundle those words are the transaction binding, blake3("rand-tx-bind-1" ‖ chain_id ‖ tx) over the transaction with its proof bytes blanked, so a proof copied onto a transaction with a different destination, memo, envelope or chain id does not verify. Since chain 20 (genesis binding_domain: 1) it is blake3("rand-tx-bind-2" ‖ genesis_hash ‖ chain_id ‖ tx), so a proof does not verify on another chain even under the same chain id; the words are a public input, so this moved nothing in the circuit. The auth proof is made over the same eight words. A call proof since chain 20 is bound the same way: its segment is the program’s deploy-time public words followed by eight words of a call binding (rand-call-bind-2, rand-call-bind-1 before chain 20), so a call proof copied under another fee bundle does not verify.

Gas is the machine’s measure of a run’s weight, in the circuit since constraint set 8. The CPU table carries a GAS column that starts at 1 and adds 1 for every row, 3 for a Poseidon2 absorb row, 64 for a SHA256 row and 192 for a KECCAK row. On the HALT row the circuit proves GAS ≤ GAS_LIMIT through four range-checked limbs of the difference, which are never opened: the limit is public and the gas a run spent is not. The verifier refuses, before it builds a key, a limit above what the proof’s own header could need:

gas_max(t, k, s) = (2ᵗ − 1) + 2ᵗ⁻² + 191·(2ᵏ / 32) + 63·(2ˢ / 64)

with k and s the declared log heights of the keccak and sha256 tables, each term zero for an absent table. A hash-free tier-10 header’s ceiling is 1,279 and a tier-14 one’s 20,479. The chain prices a call by its declared limit (Fees).

5. Turn the rules into polynomial identities

Every column is a list of numbers in the Goldilocks field, integers modulo p = 2⁶⁴ − 2³² + 1. A list of n numbers is the same thing as a polynomial of degree below n: the one that passes through them when they are laid out on a subgroup {1, ω, ω², …} of the field. Goldilocks has such subgroups of every power-of-two size up to 2³², so the conversion is a fast Fourier transform.

A rule of the machine then becomes an equation between column polynomials. “The program counter advances by four unless the instruction jumps” becomes, schematically:

is_jump(x)·(pc(ωx) − target(x)) + (1 − is_jump(x))·(pc(ωx) − pc(x) − 4) = 0

for every x in the subgroup, where pc(ωx) means “the next row”. A table’s full set of such rules is its AIR (algebraic intermediate representation). The CPU and ALU rules reach degree 8; the others stay at 2 to 4.

A polynomial that is zero at every point of the subgroup is divisible by Z(x) = xⁿ − 1. The prover combines all the rules, with random weights, into one polynomial C(x) and divides by Z(x). If every rule holds on every row, the quotient is a genuine low-degree polynomial. If one rule fails on one row, it is not. “Was every step of a 16,000-cycle run correct?” has become “is this function close to a low-degree polynomial?”, and that question can be answered by looking at a few values chosen at random.

6. Commit before the questions are known

The prover must fix its polynomials before it sees the verifier’s random questions, or it could tailor its answers. It evaluates every column on a domain eight times larger than the table (blow-up 8, code rate 1/8) and publishes a Merkle root over the evaluations. That redundancy is a Reed–Solomon code: a low-degree polynomial is fixed by any eighth of its values, so a cheater who changes even one row of the trace has to change most of the extended codeword to stay consistent, and random spot checks will land on the damage.

The Merkle trees use Poseidon2 over Goldilocks: width 8, S-box x⁷, 4 full rounds, 22 partial rounds and 4 full rounds, digests of four field elements (about 256 bits). Every leaf is hashed with four elements of fresh randomness, so a root reveals nothing about the values beneath it. The same permutation is the note commitment and nullifier hash inside the machine. Its 86 round constants are a literal table in the node’s source (poseidon2_constants.rs), so no library upgrade can change them.

7. Spot-check with FRI

The verifier now holds Merkle roots. It first ties the quotient to the trace: it picks a random point z outside the table’s domain, asks for every column’s value and the quotient’s value there, and checks C(z) = Q(z)·Z(z) directly. What remains is to confirm that the committed functions really are low-degree polynomials, and that is what FRI tests.

FRI works by folding. Split a polynomial into even and odd parts, f(x) = fₑ(x²) + x·fₒ(x²). For a random β from the verifier, f′(y) = fₑ(y) + β·fₒ(y) has half the degree on a domain half the size. The prover commits to f′, gets a new β, and folds again (Rand folds by up to eight per round) until a constant is left, which it sends in the clear. A query then picks one random position in the first layer and follows it down, checking at every layer that the values opened above fold into the one below. A function that was far from low-degree cannot keep all those promises consistent.

Rand runs 80 queries. Under the proven proximity-gaps theorem, each query leaves a cheater at most a 9/16 chance, so 80 queries give (9/16)⁸⁰ ≈ 2⁻⁶⁶·⁴. Under the ethSTARK conjecture, which deployed STARKs rely on, each query leaves 1/8, which is far smaller.

8. Remove the conversation

Everything above was described as a dialogue, but a transaction has to be one message that any validator can check alone. The Fiat–Shamir transformation removes the verifier: the prover computes each “random” challenge as a hash of everything committed so far, with a Poseidon2 duplex sponge. Changing any commitment changes every challenge after it, so the prover cannot pick commitments to suit the challenges.

Two further measures close the gaps this leaves:

• Extension field. A field of 2⁶⁴ elements is too small to draw challenges from: a cheater needs a challenge to land on one of a polynomial’s few bad values, and succeeds with probability about N/2⁶⁴ however many queries are run. So the trace stays in Goldilocks, but every challenge is drawn from its quadratic extension, about 2¹²⁸ elements.
• Grinding. Before the query positions are derived, the prover must find a nonce whose hash with the transcript starts with 20 zero bits, about a million hashes. An honest prover pays that once. A cheater re-rolling the query positions until they miss its forgery pays it on every attempt. This is the only proof of work anywhere in Rand, and it has nothing to do with consensus.

Adding up: 66.4 bits from the queries plus 20 from grinding gives 86 bits proven, and about 100 bits under the conjecture, where the extension field’s term is the limit.

9. Where the zero knowledge comes from

A STARK is not zero-knowledge by itself: the values opened at the query positions are values of the trace polynomials, and without care they leak. Rand’s configuration adds four layers:

1. every committed polynomial is randomised (Plonky3’s hiding FRI mixes in four random codewords), so the 80 opened values can be reproduced, in distribution, by someone who never saw the trace;
2. every Merkle leaf is salted, so roots and authentication paths reveal nothing;
3. the prover’s randomness is drawn fresh from the operating system for each proof, so two proofs of the same payment look unrelated;
4. every declared table has at least 2⁷ rows and every LogUp terminal is blinded (constraint set 7). A proof opens each table at 80 query points and two out-of-domain points, and the hiding commitment mixes in as many random rows as the table has rows, so a table is hidden only while it has at least 82 rows. 128 is the smallest power of two that does.

Layer 4 is a correction. The 2026-09-27 review recovered the private inputs of calls with 31 or fewer input words from production proofs, read a program’s fetch counts from its short program table, and told a bundle’s real input slots from its dummies by its unblinded terminals. Those proofs are the ones made on chain 15 and earlier. Chain 16 (constraint set 7, with the branch-free bundle guest) closed all three, and chains 18 to 20 keep the fixes.

The guarantee is statistical zero knowledge in the random-oracle model. What a proof does not hide is exact: its tier, its declared table heights, and its public values, the gas limit among them. A declared keccak, sha256 or modq height of 0 means the run never used that table, so a call proof’s header shows whether the call hashed and, above the floor, how often to within a factor of two. For a bundle the public values and fields are the anchor, four nullifiers, four commitments, fee, burns, burn asset, time, the authorisation commitment and the transaction binding. The asset a transfer moves is a private input, so a zUSD payment and a RAND payment look the same on chain. hc is deterministic, so anyone can tell a proof concerns the bundle guest (every value-moving proof does) or, for a call, which deployed program it ran.

10. What a validator checks

Machine::verify_public(hc, words, proof) runs, cheapest first:

1. the proof’s declared tier and table heights are bounded (check_declared_heights) before anything is sized from them, so a malformed header costs a few comparisons, not a multi-second key build; a bundle must declare tier 14 with neither hash table nor a modq table, a single-key auth proof tier 10, and a multisig auth proof exactly its pinned tier-18 shape (a keccak table of 2¹⁴ rows, a modq table of 2¹⁶, a memory table of 2²⁰); every call, invoke and state proof refuses a modq table before any key is built;
2. there are 35 public values, each a canonical field element, with pv[HC] = hc, pv[TIER] equal to the proof’s tier, every output word below 2³², and GAS_LIMIT at most gas_max of the header;
3. the batch STARK verifies against a verifier key cached per shape (tier, program, input, keccak, sha256, public heights), not per program;
4. H_PUB equals the digest of words, which for a bundle is the transaction binding the node computed itself.

Before any of this the node screens every submitted or gossiped proof for a canonical encoding: its FRI folding schedule must be the one an honest prover makes for the degrees the header declares. Since fullnode v0.6.8 (audit v6, ZKV-4) the screen first refuses any declared degree above 25 bits (MAX_HONEST_DEGREE_BITS, the memory table’s 2²⁴ ceiling plus the zero-knowledge doubling, the most an accepted proof carries). Before that bound, a header declaring a huge degree made the node re-derive an enormous folding schedule on its event loop, holding it for as long as the sender liked; the verifier would have refused the proof anyway, so the bound changes only the cost of saying no. A panic inside the screen now refuses that one transaction rather than stopping the node.

The ledger then recomputes the bundle digest D with bad = 0 and compares it with the proof’s eight output words. Since chain 20 it also requires a bundle proof’s GAS_LIMIT to be exactly the genesis bundle_gas_limit, 20,479, and a single-key auth proof’s to be 1,279 (on chain 21 a multisig auth proof’s 436,159), so every transfer declares the same values. With a warm key the whole check takes about 16 ms.

The parameters, and why they were chosen

Every number below is consensus: the verifier checks it, a proof made with any other value does not verify, and changing one is a new constraint set and a hard fork (Constraint sets). The FRI profile is fixed by the genesis file (fri_profile: production on chain 21, as on chain 20), never by the proof.

What these numbers add up to: 86 bits of soundness proven, about 100 under the ethSTARK conjecture (where the extension field, not the queries, is the limit), and about 85 bits against a quantum adversary, set by the 256-bit transcript hash. The whitepaper keeps both soundness figures side by side on purpose: every deployed FRI-STARK relies on the conjecture for its last bits, and a reader sizing a deployment should know which assumption carries which bits.

Proofs about proofs

At about 1.50 MB a bundle proof is heavy, the 1.37 MB auth proof rides beside it, and every node stores them all. The remedy that is built is recursion: a proof whose statement is “I verified these proofs”. The fullnode carries a second, smaller machine for it, the recursion VM, whose native word is a Goldilocks element and whose instructions are the verifier’s own operations (field arithmetic, Poseidon2, Merkle and FRI steps). Its aggregate program replays the full verification of N bundle proofs and publishes a digest over their public values, bound to the chain, the aggregator and a nonce. Verifying one bundle proof inside it cost 1,968,619 rows under constraint set 6 and 2,044,506 under constraint set 7; it has not been re-measured under set 8 or 9. It is implemented and switched off by genesis on every chain so far, chain 21 included. The aggregate program verifies bundle proofs only, so on a split-authorisation chain the auth proof would stay. Its production proofs also need more memory than was planned for: measured under constraint set 7, 133 GB and more (Upcoming: block aggregation).

What the scheme does not claim

• The quantum margin is about 85 bits, not 128. Quantum collision search on an n-bit hash costs about 2ⁿ/³. The whitepaper’s design calls for a 384-bit transcript hash; the running chain uses the 256-bit Poseidon2 digest. Widening it is a new constraint set and a hard fork.
• 100 bits is a conjecture; 86 is proven. Raising the proven figure to 100 would cost 97 queries, about a fifth more query data per proof.
• The Poseidon2 constants are a seeded draw, not a published instantiation. No attack on that is known; adopting a standard set would change every hash on the chain.
• Some statements are checked beside the proof, not in it. The TIER public value is compared with the proof’s shape by the verifier but not constrained by the circuit (audit ZL1), and the bundle guest’s taint discipline is backed by structural argument, a weakened-guest harness and mutation fuzzing rather than machine-checked.
• A proof’s header is not hidden. The tier and the two hash-table heights are in the clear, so a call proof shows whether the call used KECCAK or SHA256. A prover option that pads both tables in exists and no wallet sets it: it takes a tier-10 proof from about 1.3 MB to about 3.6 MB.
• The POSEIDON2 syscall is not injective over variable-length input. It is kept as it is because every commitment, nullifier, root and program digest depends on it. No shipped guest uses POSEIDON2_LEN yet.
• Proving is slow and done by the sender, or by a prover the sender pairs with: about 100 s and 5.7 GB on a laptop CPU for a bundle. The GPU kernels first ran on a GPU (an NVIDIA H100) on 2026-09-28 and matched the CPU reference; the wallet still proves on the CPU.

Where to read more

• The whitepaper’s section “The Zero-Knowledge Scheme: How a Rand Proof Works” (randprotocol.tex) walks through the same seven ingredients with the soundness theorems.
• The implementation paper (randprotocol_implementation.tex) specifies the instruction set and syscalls, the bundle guest, the sponge and digests, every table and bus, the machine configuration and the recursion VM.
• The code: crates/randprotocol-zkvm/src/ in the fullnode — emulator.rs, tables/, machine.rs, gas.rs, guests.rs, hash.rs, poseidon2_constants.rs.