Skip to main content

​
vNext Kernel Prototype Status

EXPERIMENTAL · NOT AUDITED · NOT PRODUCTION · NO DEPLOYMENT. The vNext kernel is a research prototype in the public Wallet-Wall/walletwall-vault repository. It has no audit and no formal verification, and it has not been — and may not be — deployed anywhere, including testnets. Merging work into the prototype does not authorize deployment or custody use. The Sepolia rehearsal described under Stablecoin Vault & Vault Simulator uses the separate, existing vault contracts, not this kernel.

​
What the prototype is

The vNext kernel is a measurement prototype for a smaller vault architecture. It exists to answer one question:
Can the vault’s authority model be expressed as a small, clone-safe, understandable kernel without silently re-importing the authority of the existing monolithic contract?
Each vault is a minimal clone produced by one immutable factory per kernel generation. A factory has no owner, no upgrade path and no authority over any vault it has already produced; registering a new generation means deploying a new factory. The prototype lives in its own directory, outside the compilation unit of the existing vault contracts, which it leaves untouched. Its governing invariants are stated in the repository’s architecture and hazard documents, not in the prototype directory itself.
The first verdict on this prototype was wrong, and the repository says so. An early head declared the kernel’s authority cuts sound. An independent review reproduced four paths to total loss against that exact kernel; the verdict was withdrawn, the findings were fixed, and the result was re-earned. The failed claims are kept in the record rather than deleted.

​
What its assurance evidence is — and is not

The prototype carries three kinds of evidence. Each has its own scope and its own vocabulary, and none of them is an audit or formal verification. Tests and assurance artifacts demonstrate properties of the repository at a specific commit. Evidence about this prototype must not be generalised into a claim about a deployed WalletWall vault.

​
Verifier admission: provenance, not permission

A vault’s post-quantum authorization path depends on which verifier contract it trusts. The prototype binds that choice to provenance established by construction, not to approval by an administrator.
  • Bound once, per generation. The factory binds a verifier provenance root at its own construction, exactly as it binds the kernel implementation. The root is copied into every clone’s immutable arguments, and each vault reads it from its own code, so no transaction can change which root a vault consults.
  • Checked at every admission edge. The check runs wherever a value can later become the active verifier: at initialization, when a verifier is changed, and when a recovery proposes one. Recovery execution installs only the stored proposal, whose one writer is the checked recovery initiation.
  • One read-only call. The check is a single STATICCALL to the root asking whether it created the candidate. The candidate is never asked — a verifier that vouches for itself proves nothing.
  • A precondition, not an authorization mechanism. Admission is checked before any authorization gate, nonce or write, and it is never consulted on authorization. Passing it permits nothing on its own; every existing authorization requirement still applies.
  • No administrator. The root records a verifier only in the same step that creates it, and never clears a record. It has no owner, no setter and no second writer. The prototype introduces no kernel admin and no administrator-editable verifier registry.
  • Having code is not admissibility. The check is not a bytecode-hash pin: a byte-identical copy of an admitted verifier deployed outside the root is refused. Arbitrary verifier bytecode is not trusted merely because it exists.
  • Fail closed. A vault with no root in its arguments admits nothing.
The check deliberately does not decide which attestor a vault trusts, which remains an authorised admission decision, and it does not establish that a committed post-quantum public key is well formed. That second limit is recorded as an open defect in the stateful ledger.
initialize is not free of external interaction. Since this change, vault initialization makes one STATICCALL. That fact invalidated a scanner rationale that had been written earlier — see stable identity, stale rationale for how it was found and pinned.

​
Status at the v0.13.15 checkpoint

Recorded at walletwall-vault v0.13.15 (6463caee, 19 September 2026). A dated snapshot, not a permanent property.

​
Read the source

Prototype README

The prototype’s own boundary, question and measured answer.

vNext architecture

The governing invariants the prototype is measured against.

Hazard register

Named hazards and the residuals accepted against them.

Authority record

Append-only record of authority cuts, including the verifier-admission closure and what it does not close.

Scanner Evidence & Assurance Model

How scanner output becomes evidence, and why an alert count is not a vulnerability count.

Vault Boundaries & Disclosures

Custody, testnet and quantum-security boundaries for every Vault surface.