A zkVM build prompt set is a specification written to be executed rather than read. Every sentence is compressed, most decisions arrive without their reasons, and a single subordinate clause can carry a protocol invariant that nothing later is allowed to revisit. This page puts twenty-eight of those documents in a reader that answers, for every line, the two questions the prompt itself does not: what is this asking for, in ordinary words, and why is it stated so absolutely.
Scope. The finished set runs to a master prompt and twenty-eight build stages. Twenty-eight documents are annotated here — the master prompt and S01 through S27, which carry the system from field arithmetic, through every instruction family, delegated cryptography and sharding, up to the aggregation tree that folds a block's proofs into one. The last stage is added when it is cleaned up, and the reader takes it without changing.
The annotations are commentary on the prompt set. They are not a specification of anything, and where an annotation and a prompt disagree, the prompt is what gets built.
The prompts drive a stage-wise build: one document per stage, each read against a master prompt that outranks it. The builder has no memory between stages, so everything a later stage needs from an earlier one has to be written down — the frozen signatures, the wire encodings, the orderings. That constraint produces a very particular prose. It is dense because nothing may be implied. It is imperative because it is instructions. And it is almost entirely conclusions: the reasoning that produced “absorb the public I/O digest before any challenge is drawn” happened elsewhere, and the prompt carries only the result.
For a machine executing it that is the right shape. For a person reading it, three things go missing at once — the plain meaning of a compressed phrase, the reason a rule is absolute rather than a preference, and the distinction between a section that settles a design question and a section that is the actual specification. The reader restores all three without touching the source text.
Three fields, in a fixed order, and the discipline is that they stay short. A line explained in eighteen words that dispels the confusion completely is better than sixty that circle it. The third field appears only where a line genuinely invites a wrong reading; it is present on 370 of 1,139 lines, and its absence is meaningful. Any term of art the lexicon does not already carry is defined in place, beside the line that uses it.
Gates may multiply at most two values from the layer below. That caps each sumcheck round message at four numbers.
Degree bounds proof size and verifier work directly: a degree-d gate makes every round message d+2 coefficients. Fixing it at construction time means no circuit can be built that the wire format cannot carry.
The ceiling is per gate, not per layer. Deeper products are expressed by adding layers, not by raising the degree.
Two further layers carry what a short annotation cannot. Code and notation: every inline code span, and every formula written straight into the prose, has its own note with each variable read out — 1,455 notes, covering 94% of the 916 distinct code spans, the rest being self-explanatory paths and names. The idea behind it: where a line leans on theory, a few sentences on why the mechanism works, on 267 lines. The LogUp line from S15, as the reader shows it:
One equation proves every lookup: each looked-up value adds 1/(value+g), each table row subtracts (use count)/(row+g), and the total must be zero. Fractions go up a tree as pairs.
Lookups repeat values while the table lists each row once, so counts are what let the sides balance. Counts are prover data: committed after g, they could be solved for to zero any sum. Pairs avoid division, which no gate computes.
In g, each value v gives the sums a pole at −v, cancelling only if v is a table row used mv times; counts never reach Fr’s modulus. Clearing denominators makes any mismatch a nonzero polynomial of degree under N + T, for N lookups and T rows, so a post-commitment g is a root with probability under (N+T)/|Fr|.
Σ_rows 1/(w_i + g) − Σ_table m_j/(t_j + g) = 0
Each looked-up value adds 1/(value+g); each table row subtracts (times used)/(row+g). For a random g the total is zero only if every value really is a table row, used exactly as often as claimed.
- w_ithe value looked up on witness row i
- t_jthe value in table row j
- m_jhow many times row j was looked up: the committed multiplicity
- ga random challenge drawn after the witness and multiplicities are committed
Beside those, a lexicon of 138 terms carries the vocabulary that recurs across the whole set — sumcheck, zerocheck, LogUp, multiset, Montgomery form, negative control, prover advice. Each is defined once, marked in the prompt text the first time it appears in a line, and listed beside every line that uses it. Defining them centrally rather than per line is what keeps the annotations short: a term of art is glossed in one place and never re-explained.
| Two panes | The prompt on the left, exactly as written. Click any line: it highlights, its terms of art light up, and its annotation appears on the right with a breadcrumb naming which section of the prompt it came from and its number inside that section. |
| Section chips | Each heading carries the authority its section holds — Assumed, Build, Settled, Exact, Tests, Frozen. Confusing a settled design note with a testable requirement, or either with the acceptance list, is the most common way to misread a stage. |
| API listings | Frozen signatures are annotated by row group rather than as one block, so a parameter, a return type or a trailing comment can each carry its own note. 93 of the annotations target rows inside a code listing. |
| Code and notation | Every inline code span and every formula written into the prose is underlined, and has its own note beside the line: what the expression computes or asserts, and what each of its variables stands for. Click the span to jump to its note. |
| The idea behind it | Where a line leans on theory — Schwartz–Zippel, the LogUp identity, multiset memory checking, pairings, recursion — a further field explains the mechanism far enough to see why it works, on the line that introduces it. |
| Search | One field over every line of all twenty-eight documents. Useful for following a single object across stages — where the timestamp convention is set, and everywhere later stages are told to cite it rather than restate it. |
| Deep links | Every line has its own URL, so one clause can be pointed at directly. |
| Keys | J / K walk the annotated lines, ← / → change stage, / searches, L opens the lexicon. |
| Stage | What it settles |
|---|---|
| Master | The rules every stage is read against: the specification in one paragraph, twelve implementation rules, thirteen anti-goals, and the frozen protocol invariants. |
| S01 · S02 | The scalar field, then the hash and the running sponge that produce every challenge in the protocol. |
| S03 · S04 | Multilinear polynomials with narrow integer storage, and the sumcheck protocol driven by the real transcript. |
| S05 · S06 | The curve and both point groups, then the field tower and the pairing — deliberately slow, because only the verifier computes one. |
| S07 | Pippenger multi-scalar multiplication, ingestion of a real powers-of-tau ceremony file, and plain KZG end to end. |
| S08 · S09 | Mercury: one multilinear opening at constant proof size, then batching many columns into one opening and deferring the pairings. |
| S10 · S11 | Guest toolchain, system-call convention and ELF loader; then the decoder and the commitment that is the program's identity. |
| S12 | The reference emulator, checked instruction by instruction against QEMU, and the trace it records. |
| S13 · S14 | The GKR engine with circuits stored as data, and the multiset argument that makes memory provable. |
| S15 · S16 | The lookup argument — ranges, timestamp gaps, fixed tables and the decoder — then the first real guest proven through every layer, which freezes the gadget vocabulary the later families reuse. |
| S17 – S19 | The instruction families: jumps, branches and comparisons; shifts, bitwise, multiply and divide; loads, stores and atomics over word-addressed memory. |
| S20 | Cutting a run into fixed-height shards proven in parallel, and the reconciliation checks that stitch them back into one block. |
| S21 – S23 | Delegation: keccak256, secp256k1 ecrecover, and batched Fr arithmetic with Poseidon2, each proven in its own circuit and requested by ecall. |
| S24 · S25 | Ethereum blocks: revm inside the guest on synthetic state, then real mainnet blocks with authenticated state witnesses and a bench report. |
| S26 · S27 | Recursion: a guest that verifies a proof with its pairings deferred, and the aggregation tree that folds a block's shard proofs into one root. |
The prompt set is roughly 43,950 words across twenty-eight files, parsed into 1,270 addressable blocks. Every annotation was written against a fixed contract — a reader model, hard word caps, a list of banned constructions, and worked examples of a bad and a good note for the same line. Each document was then refined on its own, one at a time, by a pass whose instructions were to check every claim against the source and the stages it cites, fill what a reader would still be missing, and cut what merely restated the line.
That refinement is where the value was. It found notes that named the wrong stage or the wrong rule, attributed a soundness purpose to an engineering convenience, overstated a consequence, or restated the line in different words — the last being the failure mode that looks like work and is not. Arithmetic claims were checked by computation rather than recall. And where a prompt is genuinely ambiguous, or two stages disagree, the note now says what is certain and names the open question instead of quietly picking one reading.
- The page is built, not assembled by hand. Prompt text, lexicon and annotations are injected into the script at build time, so an edit to any source file always reaches the shipped file.
- Every annotation is validated before it ships. The reference must name a block that exists; row ranges inside a code listing must lie within it and not overlap; every marked term must be an exact substring of the line it claims to be in; word caps hold; every non-heading block has exactly one annotation; and every inline code span is either explained or deliberately left as self-evident, with the latter capped at a fifth of a document's spans. Coverage is not sampled — it is enforced.
- A notation note cannot drift from its line. The same matching rule decides what is underlined on the left and what is listed on the right, and a test over the shipped script renders all 1,139 annotated units and confirms the two sets agree on every one — 2,320 listings, no mismatch — and that no two lines share an annotation, which is what catches a stale render silently showing one reader the same text.
- One recurring CSS fault is guarded against directly: an uppercase label containing a lowercase symbol. text-transform maps α to Α and g to G, silently renaming the objects a line is about, so every field that can carry algebra opts out of the transform.
It is not a tutorial. An annotation says what a line means and why it is there, and where a line leans on theory it says in a few sentences why the mechanism works; it does not derive Mercury, prove sumcheck sound, or argue the security of anything. Where a reader wants the mechanism rather than the instruction, the walkthroughs elsewhere in Reactor are the better door.
It is also not a review of the prompt set. The annotations take each line as given and explain it. Where a line is genuinely ambiguous, the annotation says so rather than resolving it, because resolving it is the builder's job and the record of that decision belongs in a handoff note.
The system the prompts describe: a RISC-V zkVM over the BN254 scalar field, arithmetized as GKR circuit families, proven with gate-based sumcheck, committed with the Mercury multilinear PCS (Eagen–Gabizon, ePrint 2025/385) over a public powers-of-tau SRS, with a Poseidon2 duplex transcript. Batched openings follow Boneh, Drake, Fisch and Gabizon, ePrint 2020/081.