The target is simple to state: a programmer writes a computation, marks a value as traced, and runs the program natively on whatever hardware is at hand — a laptop, a server, a phone. When the program finishes, its output comes with a proof that the output follows from the inputs under the program as written. Anyone with the source code can regenerate and verify the proof on their own machine — no virtual machine to install, no network to join, no cluster to trust.

What follows is an argument for why that target is worth aiming at now, what the library is built on, and what the trust chain looks like in practice.

The Problem, With Teeth

Zero-knowledge proofs are becoming settlement infrastructure. Bridges, rollups, cross-chain messaging, machine-learning attestation — consequential flows are increasingly gated by proof systems. As this happens, the question of who can audit the code that decides these flows, and who can generate and re-verify the proofs themselves, becomes a systemic one.

The failure mode of infrastructure at this scale is rarely cryptographic. It is operational: the most centralized component in a nominally decentralized system determines its security. The KelpDAO incident of April 2026 is a concrete and recent instance. LayerZero’s DVN architecture distributes message attestation across multiple independent validators, each running its own infrastructure — yet those validators depended on off-chain data sources that were not verified end-to-end by the attestation layer itself. When that upstream data was polluted, the decentralization of the validator set was irrelevant: every honest validator signed the same poisoned input. Adding more validators, more GPUs, or more independent RPC endpoints treats the symptom. The disease is that the security of the system rests on data the application did not itself verify.

This is precisely the shape of problem that application-level verifiable computing is positioned to address. If a computation can be proven on any commodity machine, there is no structural need for a validator cluster at all — the application itself, or its user, can generate the proof locally and post only the verifiable result on-chain. The cryptographic proof replaces the social trust in a cluster of replicated computers running the same computation. Every user with the source code can recompute the proof on their own laptop, the same way any Ethereum full node re-executes blocks to verify consensus. Responsibility for pinning the inputs — RPC data, oracle feeds, signed messages — falls where it actually belongs: on the application developer, who knows which inputs are load-bearing and designs the program so that the user can verify them without trusting the server.

zkVMs are a structural continuation of the cluster-scale pattern. Their per-cycle overhead — several committed field elements per guest instruction, layered on top of interpreter slowdown of one to three orders of magnitude — pushes proof generation for any non-trivial computation into datacenter territory, which reintroduces the operator-concentration problem the proofs were meant to solve. Recent work such as Jolt Pro improves constant factors but does not change the shape. Projects like ZeroOS (Zou et al., 2025) fix the ergonomics above the zkVM boundary — unmodified toolchains, a modular library OS — but do not shorten the chain beneath it. A proof system can only serve as public infrastructure if ordinary participants can both inspect its code and run it on their own machines.

What Wrappers Is

Wrappers is a C++ library for verifiable computing, built on the family of sum-check-based protocols. Its soundness derives from a single classical observation: a low-degree polynomial, evaluated at a random point in a sufficiently large finite field, cannot hide a disagreement with the correct polynomial for long. From this observation alone, an interactive proof can reduce a claim about a sum over an exponentially large set to a single polynomial evaluation. The resulting proof system is post-quantum secure — it uses no elliptic-curve assumption, no trusted setup, and no structured reference string.

From the programmer’s perspective, the library is one type import and a type annotation:

#include <wrappers>

int main() {
    Traced<int> sum = 0;
    for (int i = 0; i < 10; ++i)
        sum += i * i;

    return sum.value();
}

When this program compiles and runs, it executes natively on whatever hardware the user happens to be sitting at. Each operation on sum — the initial assignment, each accumulation, each multiplication of the loop index — is recorded into a trace. The trace is arithmetized into a layered circuit and a proof is produced alongside the returned value. Anyone with the source code and the claimed output can recompute the proof on their own machine and verify that the result follows from the program.

Three words carry the thesis.

Optional. Proof is not an environment, a virtual machine, or a runtime setting. It is a local property of specific values, entered by the act of typing something as Traced<T>. A program may have one traced variable, twenty, or none. Values typed as plain int are ordinary native integers and do not participate in the proof. The programmer draws the boundary by deciding which values deserve to be traced.

Application-level. What is traced is the application’s own arithmetic — the loop, the multiplications, the accumulation — not the operating system’s syscalls, not the compiler’s lowered instructions, not the CPU’s microarchitectural state. The proof attests that sum equals the sum of the squared indices, as written in the source, not that the CPU executed a particular sequence of RISC-V instructions. The boundary is visible in the source code.

Executor-agnostic. The program compiles and runs under any standard C++ toolchain, on any machine. There is no zkVM to install, no specialized validator cluster to join, no coordination protocol to participate in. Once the source code is public, any observer — a user auditing the result, a counterparty checking a settlement figure, a researcher reproducing an experiment — can recompile and regenerate the proof on their own laptop, in the same way an Ethereum full node re-executes blocks locally to verify consensus. The machine that produced the proof can be compromised, misconfigured, or adversarial; if the proof verifies, the output is correct.

The Threat-Model Inversion

The difference between Wrappers and the zkVM approach is not which protocol is used. Both ultimately rest on sum-check. The difference is what the proof is about.

A zkVM proof states: “this RISC-V execution trace is the correct evaluation of this program, given these prover-supplied inputs and syscall returns.” The proof is about the machine’s behavior.

A Wrappers proof states: “this function, given these inputs, produces this output.” The proof is about the function. Everything that is not the function — the machine, the OS, the executor’s environment — is moved outside the boundary and marked as such in source.

This inversion is cleaner in two ways.

It is honest about input provenance. A zkVM cannot prove that a getrandom syscall returned a value drawn from a true RNG, that a file descriptor returned the real contents of a file, or that a network read returned a genuine response from the claimed peer. Those return values come from the real host and are, at the proof-system layer, chosen by the prover. Every production zkVM deployment therefore relies on application-level pinning — public inputs, Merkle commitments, signed oracle feeds — to make its proofs meaningful. Wrappers requires the same pinning, but visibly, at the source line where the traced value is constructed, where the programmer is forced to decide how each input is attested.

It is shorter in trust. The verifier must trust their own verification code, the cryptographic assumption underlying the chosen backend, and the library’s implementation of the protocol. That is the trusted computing base. It fits in a single directory of C++ headers and — crucially — fits in the head of an individual reader.

The Thompson Lineage

Forty-two years ago, Ken Thompson’s Turing Award lecture brought the elephant in the room to the table: trust is chained, and the chain can never be fully escaped. The compiler that compiled your compiler may contain a backdoor that no amount of source-level auditing will find. The moral was not despair. It was that trust must bottom out somewhere, and the shorter and more inspectable the chain, the better the position one is in.

The elephant is in the proof-system room too. A zkVM proof rests on a stack of trust that includes the zkVM implementation, its patched standard library, its arithmetized kernel, the toolchain that produced the guest binary, and the host environment that supplied non-deterministic inputs. If any single link in that chain is compromised, the proof is rendered meaningless, regardless of how rigorous the cryptography is above it. This is not a bug in any particular zkVM; it is a structural consequence of building a proof system that tries to cover an execution environment as deep as an operating system.

Wrappers does not claim to resolve this fundamentally. No proof system can. What it does is move the security model to a layer where more people can meaningfully participate in the auditing. The global community working on zkVM internals is small — comparable in size to the teams building production compilers, if that. The community of application developers writing C++, Rust, Python, and JavaScript is many orders of magnitude larger. When the proof boundary is drawn in application code, the people best positioned to read, review, modify, and extend it are the ones already writing that code. That is a different axis of decentralization than the one offered by distributed provers: it is the decentralization of who can inspect the work.