Summary: Nexus zkVM is best understood as the proving-runtime layer inside the broader Nexus stack, not merely as a feature page for a future chain. Its reusable mechanism is a modular zkVM built around a custom prover-oriented RISC-V machine, a fully specified AIR, a default Stwo-based proving path, and an architecture that explicitly keeps room for alternate folding schemes, precompiles, languages, and proving architectures. That makes Nexus zkVM a useful comparison class beneath or beside broader proving networks: the real control surfaces are the machine design, memory model, proof-system defaults, extension policy, and the boundary between a local prover toolkit and the larger Nexus Network distributed proving layer.
What it does:
Lets developers generate succinct proofs for arbitrary computation through a Rust-first zkVM stack
Uses a custom RISC-V32im-oriented machine and runtime rather than treating the VM as a thin wrapper around an existing execution environment
Ships with a fully specified AIR and offline memory-checking approach aimed at prover performance and auditability
Defaults to a Stwo/S-two-based prover integration while preserving compatibility with other proving constructions such as the Nova family
Exposes a developer-facing runtime, SDK, and documentation stack for guest programs, public/private inputs, outputs, logging, and examples
Positions itself to scale from local proving on a single machine to the broader Nexus Network distributed prover architecture
Key claims:
The docs define Nexus zkVM as a modular, extensible, prover-optimized, fully specified zkVM written in Rust and explicitly mark it as focused on performance and security
The docs and README both stress an open science posture: no code obfuscation, no proprietary components, no closed-source code, and fully/publicly specified cryptographic components
The architecture page says the stack includes a custom from-scratch modified-Harvard RISC-V machine, a fully specified AIR over the full RISC-V32im instruction set, and efficient offline memory checking, which makes machine design and memory policy first-order analytical surfaces rather than implementation details
The same page says the default proving path integrates StarkWare’s Stwo prover but keeps compatibility with the Nova family and future proving constructions, which means Nexus is trying to keep the runtime distinct from any single proving backend
The docs say developers will be able to extend the zkVM with new languages and custom precompiles, so extension policy and curated acceleration become part of the practical control plane
The whitepaper page describes a wider Nexus architecture spanning the Nexus Virtual Machine, coprocessors, recursive proof systems, and a distributed prover network meant to aggregate heterogeneous compute for very large workloads
The public README currently labels the zkVM experimental and not yet recommended for production use, which is important context when comparing it against more mature proving runtimes
Whitepaper: The official docs host a readable Nexus whitepaper landing page describing the Nexus 1.0 design and its distributed prover architecture. The most useful current primary-source packet is the docs plus public README; see ../whitepapers/nexus-zkvm-primary-sources-2026-05-13.md.