The current docs make clear that Nexus zkVM should be treated as a distinct runtime and proving layer, not flattened into the broader Nexus chain / network story.
The architecture page is the most useful concise map of the stack: a custom Nexus runtime, a prover-oriented RISC-V machine, a fully specified AIR with offline memory checking, and a default Stwo prover integration.
The docs and README repeatedly emphasize open science / full specification / no proprietary components. That matters because many zkVMs market transparency while still hiding important implementation or extension details.
Nexus explicitly keeps the proving architecture separate from the zkVM definition itself: the same machine can be proven locally or inside the larger Nexus Network distributed prover architecture.
The docs also make extension policy legible as a real control surface through future/custom precompiles, language support, and compatibility with proving constructions beyond the default Stwo path.
The whitepaper landing page is brief but still useful because it names the wider system boundary: the Nexus Virtual Machine, coprocessors, recursive proof systems, and a distributed prover network targeting very large workloads.
The public README currently labels the project experimental and not recommended for production use, which is important comparison context against more mature zkVM stacks.