> ## Documentation Index > Fetch the complete documentation index at: https://docs.walletwall.org/llms.txt > Use this file to discover all available pages before exploring further. # vNext Kernel Prototype Status > What the vNext vault kernel prototype is, what its assurance evidence does and does not establish, and how verifier admission is bound to provenance rather than to any administrator. # 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`](https://github.com/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](/features/vault) 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. | Evidence | What it records | Where its vocabulary lives | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- | | **Stateful adversarial campaign** | A deterministic, seeded search for sequences of individually valid actions that compose into an unauthorised outcome. Its ledger lists remediated defects *and* defects it has not closed, with known gaps and what the campaign does not prove. | `STATEFUL_AUTHORITY_EVIDENCE.json` | | **Authority-path checker** | A per-entry verdict on whether each path that can change authority is accounted for. | `AUTHORITY_CENSUS.json` | | **Scanner triage** | A per-finding classification of every distinct Slither finding, bound to the scanner run it adjudicated by a receipt. | `slither-triage.json`, receipted by `SCANNER_EVIDENCE.json` — see [Scanner Evidence & Assurance Model](/vault/scanner-assurance-model) | 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. ```mermaid theme={null} %%{init: {'theme': 'base', 'themeVariables': {'actorBkg': '#BF4E32', 'actorBorder': '#8B3120', 'actorTextColor': '#FAF8F3', 'actorLineColor': '#8B6F47', 'signalColor': '#1E1A14', 'signalTextColor': '#1E1A14', 'labelBoxBkgColor': '#E6DED2', 'labelBoxBorderColor': '#9A9186', 'labelTextColor': '#1E1A14', 'loopTextColor': '#1E1A14', 'noteBkgColor': '#C9A47A', 'noteBorderColor': '#8B6F47', 'noteTextColor': '#1E1A14', 'activationBkgColor': '#FAF8F3', 'activationBorderColor': '#C9A47A', 'sequenceNumberColor': '#FAF8F3'}}}%% sequenceDiagram accTitle: Verifier admission at vault initialization accDescr: The generation's factory deploys a clone whose immutable arguments carry the verifier provenance root. During initialize, the clone reads the root from its own code and makes one read-only STATICCALL asking whether the candidate verifier was created by that root. If the answer is no, initialization reverts. The candidate verifier itself is never asked. autonumber participant F as Generation factory participant V as New vault clone participant R as Verifier provenance root F->>V: deploy clone (root bound in its immutable args) F->>V: initialize(genesis, key) Note over V: Initialized flag set before any external call V->>R: STATICCALL isAdmissibleVerifier(candidate) R-->>V: true only if the root created it Note over V,R: Read-only precondition. The candidate is never asked. V-->>F: admitted, or revert ``` * **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](/vault/scanner-assurance-model#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`](https://github.com/Wallet-Wall/walletwall-vault/commit/6463caee352beda7a27009d29f1a48b42b063fd8), 19 September 2026). A dated snapshot, not a permanent property. | Item | State | | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Deployment | None, on any network | | External audit / formal verification | None | | Stateful campaign ledger | 11 defects remediated, 2 conditionally remediated (the verifier-admission pair above, with their condition published beside the verdict), 2 sustained and open | | Scanner triage | 42 distinct findings adjudicated, 0 untriaged — see [Scanner Evidence & Assurance Model](/vault/scanner-assurance-model#status-at-the-v0-13-15-checkpoint) | ## Read the source The prototype's own boundary, question and measured answer. The governing invariants the prototype is measured against. Named hazards and the residuals accepted against them. Append-only record of authority cuts, including the verifier-admission closure and what it does not close. ## Related How scanner output becomes evidence, and why an alert count is not a vulnerability count. Custody, testnet and quantum-security boundaries for every Vault surface.