What problem is Nexus actually solving?
Strip away blockchain and ZK terminology for a moment. Someone runs a program and hands you an output. You have two unattractive options: trust them, or recompute the entire thing yourself. Trusting is cheap but unverifiable; recomputing is verifiable but expensive.
Nexus is built around the third option: the executor produces a cryptographic proof alongside the output, and a verifier checks that proof without re-running the computation. Nexus's stated goal is to make this work not just for one machine, but as a distributed, planet-scale compute system — a network of untrusted machines whose combined work can still be trusted, because bad computation simply cannot produce a valid proof.
Don't make everyone repeat the computation. Make computation produce cryptographic evidence that it was done correctly — then distribute the proving itself.
zkVM ≠ Network ≠ Layer 1
A common confusion when reading Nexus material is treating "Nexus" as one monolithic thing. It is more useful to hold three layers apart in your head, each solving a different problem.
The current Nexus documentation frames the L1 explicitly around three separated layers — execution, verification, and consensus — sharing a single, unified global state, rather than one undifferentiated "chain."
Why a virtual CPU, and why keep it simple?
An ordinary CPU repeatedly fetches, decodes, executes, touches memory, and
updates state. A computation is really just a sequence of machine states
S0 → S1 → S2 → ... → Sn, where each transition is caused by
one instruction. A zkVM's job is to prove that every one of those
transitions was computed correctly — not merely to say it happened.
Normal VM zkVM
Program Program
│ │
▼ ▼
CPU / VM CPU / VM
│ │
▼ ▼
Output Execution Trace
│
▼
Constraints
│
▼
ZK Proof
│
▼
Output + Proof
Building a bespoke circuit for every possible program doesn't scale — you'd
need a separate circuit for square, another for SHA-256,
another for sorting, and so on. Instead, a Rust program is compiled down to
machine instructions that run on one general virtual CPU,
and that single machine architecture is what gets proven.
This is also why Nexus cares intensely about keeping the CPU itself simple: every instruction the machine supports becomes something that must be arithmetized and constrained on every cycle. A machine with 10,000 instructions is expensive to prove; a small, RISC-V-like instruction set with specialized functionality carved out separately is not.
The Nexus Virtual Machine
The original Nexus whitepaper introduced the NVM — a minimal, extensible, prover-optimized virtual CPU. The current zkVM architecture has evolved toward a machine close to RISC-V RV32I, with a modified Harvard-style memory architecture, 32 registers, and 32-bit words.
Rust guest program
│
▼
Rust compiler
│
▼
Guest ELF
│
▼
Nexus VM / ISA
│
▼
Execution trace
│
▼
ZK proving system
Machine state
PC + registers + memory state + execution metadata, transformed one instruction at a time.
S(i+1) = Transition(S(i), instruction)
The equation the zkVM must prove holds for every single cycle of execution.
How execution becomes something provable
Suppose a program computes c = a + b. The machine produces a
row-by-row record of its state over time — a trace. The prover doesn't ask
the verifier to simply trust this table; it generates algebraic
constraints that enforce the required relationships between rows.
Cycle PC r1 r2 r3
────────────────────────────────────────
0 0 5 0 0
1 4 5 7 0
2 8 5 7 12
3 12 5 7 12
constraint:
r3(next) = r1(current) + r2(current)
constraint:
PC(next) = PC(current) + instruction_size
Real constraint sets are much richer: instruction validity, register updates, memory reads and writes, branching, and I/O all need their own enforced relationships between consecutive rows.
Memory is the hard part
Proving the CPU is only half the problem. If MEM[100] = 42
and a later instruction does LOAD r2, [100], the proof has to
establish both that memory really held 42 and that the load
correctly produced 42 in the register — you can't just trust memory.
The current Nexus machine specification proves only the memory a program actually uses, via a two-pass tracing approach: a first pass determines the memory layout the proven execution will need, and a second, proven pass runs against that fixed layout.
Program │ ▼ First execution │ ├── determine memory usage │ ▼ Fixed memory layout │ ▼ Second / proven execution │ ▼ Memory constraints
Separate segments
Program, public input, private input, associated data, stack, heap, public output, and exit code are tracked as distinct regions during tracing.
Unified fixed layout
Those segments collapse into a single, structured memory layout that the prover can constrain efficiently.
Why not put everything in the CPU?
Running something like SHA-256 through ordinary VM instructions means thousands of cycles and a correspondingly huge proving cost. Nexus's answer, much like an EVM precompile, is to move specialized operations into dedicated co-processor circuits the prover checks directly, rather than fully emulating them cycle by cycle.
NVM
│
┌────────┼─────────┐
│ │ │
ADD MUL SHA256
│
▼
Co-processor
│
▼
specialized
circuit
More CPU functionality means more constraints on every single cycle, which means slower proving. A small general-purpose CPU paired with efficient, purpose-built co-processors keeps the common case cheap while still supporting expensive cryptographic primitives when needed.
Proving a billion cycles without one giant proof
A real program might run for a billion cycles. Rather than building one enormous proof, execution is split into chunks, each proved independently, and then the resulting proofs are folded together instead of being kept as a large, unwieldy collection.
π1 ─────┐
├──► π12
π2 ─────┘
π3 ─────┐
├──► π34
π4 ─────┘
π12 ────┐
├──► π1234
π34 ────┘
π1234
/ \
π12 π34
/ \ / \
π1 π2 π3 π4
The original Nexus whitepaper builds this on a research stack of Nova, CycleFold, HyperNova, and parallel variants, using CCS (Customizable Constraint Systems) as a generalized constraint representation. The current SDK's proving path has moved to a STWO-based prover, while legacy zkVM modes still document Nova / HyperNova / Jolt — worth keeping straight when reading whitepaper material alongside current docs.
IVC
Incrementally Verifiable Computation: each step S(i) → S(i+1) produces a proof that recursively accumulates the proof of everything before it.
PCD
Proof-Carrying Data generalizes IVC beyond a single sequential chain, letting independently computed branches merge their proofs together.
The Nexus Network
Folding is what makes it possible to hand different chunks of the same computation to different, mutually untrusted machines. The whitepaper describes the Nexus Network as a heterogeneous network of CPUs and GPUs whose collective proving capacity scales the zkVM's throughput.
USER PROGRAM
│
▼
COMPILATION
│
▼
VM EXECUTION
│
▼
EXECUTION TRACE
│
▼
┌─────────────────────┐
│ Split into chunks │
└──────────┬──────────┘
│
┌──────────┼──────────┐
▼ ▼ ▼
Node A Node B Node C
│ │ │
πA πB πC
│ │ │
└──────────┼──────────┘
▼
Folding
│
▼
Accumulated proof
│
▼
Compression
│
▼
Final proof π
Volunteer computing needs redundancy to catch a lying node. Proof-carrying computation doesn't: bad computation cannot produce a valid proof, so a single honest verifier can catch a dishonest worker without re-running its work.
Folding is not the final proof
Folding is excellent for cheaply accumulating many proofs, but the resulting accumulated object can still be relatively large. Nexus's architecture historically separates fast accumulation from a final SNARK compression step that produces a small, succinct proof suitable for on-chain or lightweight verification.
π1 π2 π3 π4 π5 ... πN
│
▼
Folding / IVC
│
▼
accumulated proof
│
▼
compression
│
▼
succinct proof
Folding ≠ final succinct proof — they solve different problems, and mixing them up is a common source of confusion when reading Nexus's proving stack.
Execution, consensus, and verification as separate layers
Nexus's L1 pairs a general-purpose smart-contract environment with a specialized, high-performance financial execution engine, under one consensus layer and a distributed proof system.
| Layer | Components | Role |
|---|---|---|
| Execution | NexusEVM · NexusCore | Runs general-purpose contracts and specialized financial co-processors. |
| Verification | Compute Network | Progressively produces validity proofs of execution that anyone can independently verify. |
| Consensus | NexusBFT | Orders transactions and finalizes blocks with single-slot finality. |
NexusEVM
Ethereum-compatible virtual machine producing 1-second blocks, supporting the standard Ethereum toolchain.
NexusCore
High-performance engine hosting enshrined financial co-processors — order matching, risk, oracles, liquidations — running deterministically at 200 ms intervals.
NexusBFT
Custom BFT consensus built on CometBFT. Blocks are final when committed — no probabilistic finality window, no reorgs.
Compute Network
Generates validity proofs of execution using the Nexus zkVM; proof coverage expands incrementally toward both NexusEVM and NexusCore.
NexusEVM and NexusCore interoperate through atomic cross-core messaging, so a contract call and a native financial co-processor can act within a single, consistent transaction — combining smart-contract flexibility with exchange-grade execution.
From transaction to Universal Proof
USER
│
│ transactions / programs
▼
┌───────────────────┐
│ Nexus Layer 1 │
└─────────┬─────────┘
│
┌─────────────┴─────────────┐
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ NexusEVM │ │ NexusCore │
│ general │ │ specialized │
│ execution │ │ execution │
└──────┬──────┘ └──────┬──────┘
│ │
└─────────────┬─────────────┘
▼
Execution State
│
▼
┌─────────────┐
│ NexusBFT │
│ Consensus │
└──────┬──────┘
│
▼
Finalized State
│
▼
┌─────────────────┐
│ Nexus zkVM │
│ CPU · Memory │
│ Precompiles │
│ Trace │
└────────┬────────┘
│
▼
Proof Generation
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Prover A Prover B Prover C
│ │ │
▼ ▼ ▼
πA πB πC
│ │ │
└─────────────┼─────────────┘
▼
Folding
│
▼
Proof Aggregation
│
▼
Proof Compression
│
▼
┌──────────────────┐
│ Universal Proof │
└──────────────────┘
Today, a developer submits an EVM transaction, NexusEVM executes it, and NexusBFT commits the block with single-slot finality; the Compute Network is live on Nexus Testnet and progressively expands proof coverage. As NexusCore comes fully online, a trader's signed order will be routed through matching, risk checks, and position updates at 200 ms intervals before the same consensus and proving pipeline finalizes and proves it.
Verifiable ≠ automatically private
It's a common interview mistake to describe a zkVM as inherently private. More precisely: a zkVM proves verifiable computation, which may or may not also be zero-knowledge. Correct execution is the core guarantee; what the proof reveals about inputs is a separate, additional property.
x = public = 5
y = private = 3
program:
output = x * y
proof establishes:
5 × 3 = 15
verifier checks:
Verify(program, x=5, output=15, π) = TRUE
without ever learning y.
Nexus stack, layer by layer
| Level | Concepts | Purpose |
|---|---|---|
| L1 | Rust | Language of the zkVM implementation and SDK. |
| L2 | CPU, registers, RAM, compiler/ELF | Computer-architecture fundamentals behind the machine model. |
| L3 | Finite fields, curves, commitments, Fiat-Shamir | Cryptographic primitives underneath the proof system. |
| L4 | ISA, execution trace, memory, precompiles | zkVM internals — the CPU/memory model actually being proven. |
| L5 | R1CS, CCS, AIR, polynomial constraints | How execution becomes an algebraic statement. |
| L6 | Nova, HyperNova, CycleFold, STWO | Folding schemes that accumulate proofs cheaply. |
| L7 | IVC, PCD, proof aggregation | Sequential and distributed proof composition. |
| L8 | NexusEVM, NexusCore, NexusBFT, Nexus Network, Universal Proof | The Layer 1 and distributed proving infrastructure built on top. |
How to study the Nexus codebase
Since folding, IVC, and zkVM fundamentals transfer directly from other proving systems, the most efficient path skips straight past "what is a zkVM" and into Nexus's specific machine and proving choices.
-
Machine architectureNexus's RISC-V-like ISA, registers, and modified Harvard memory model.
-
Execution traceHow cycle-by-cycle state becomes a table with enforced row-to-row constraints.
-
Memory provingThe two-pass tracing approach and the fixed memory layout it produces.
-
Constraint systemsCCS / R1CS and how they generalize the constraints derived from the trace.
-
Precompiles / co-processorsWhy expensive primitives like SHA-256 are moved out of the general CPU.
-
Folding stackNova, CycleFold, HyperNova, and the current STWO-based prover.
-
IVC / PCDHow sequential and distributed proof accumulation actually compose.
-
Distributed provingHow chunks are assigned to untrusted nodes and their proofs recombined.
-
CompressionHow an accumulated proof becomes a small succinct final proof.
-
Nexus L1NexusEVM, NexusCore, NexusBFT, and the Compute Network as separated layers.
Where bugs are most interesting
As with any proving system, the most dangerous class of bug is a semantic mismatch: what the machine actually did diverging from what the constraints, folding scheme, or L1 accepts as valid.
ISA semantics
Can the Nexus ISA and its constraints diverge for an instruction or edge case?
Memory layout
Can the first (tracing) pass and second (proven) pass disagree about memory usage?
Precompiles
Can a co-processor circuit accept an operation it does not actually represent correctly?
Folding boundaries
Does a folded proof really preserve every constraint of its constituent chunks?
Distributed proving
Can a malicious node submit a malformed chunk proof that still folds successfully?
Compression
Does the succinct final proof faithfully represent everything the accumulated proof attested to?
Cross-core messaging
Can NexusEVM and NexusCore disagree about the effects of an atomic cross-core transaction?
Consensus / finality
Can a block be treated as final by one part of the system before NexusBFT has actually committed it?
Execution → Trace → Constraints → Folding → Distributed Proving → Compression → L1 Verification
Nexus in one picture
NEXUS
│
▼
"Compute + prove"
│
┌─────────────┴─────────────┐
│ │
EXECUTION VERIFICATION
│ │
▼ ▼
NexusEVM/Core Nexus zkVM
│ │
▼ ▼
state transition execution trace
│
▼
constraints
│
▼
proof generation
│
▼
distributed
provers
│
▼
folding /
aggregation
│
▼
final proof
│
▼
Universal Proof
Nexus compiles programs onto a small, prover-optimized virtual machine, turns their execution into a constrained trace, folds that trace's proofs across a distributed network of untrusted machines, and composes the result into a small, independently verifiable proof — while a separate Layer 1 keeps execution, consensus, and verification as distinct, coordinated layers around the same global state.