Kenosian Vault

The verification layer above code and weights.

One call tells you whether the mathematics a paper rests on passed the Lean 4 kernel. On the left is what you type. On the right is what the kernel answers. Nothing here is mocked.

Developer input
# no dependencies, no Lean toolchain pip install kenosian-vault from kenosian_vault import Vault c = Vault().theorem("KLean.Modular.Burnside .m24_irrep_count")
Oracle output
c.claim "There are exactly 26 irreducible representations of M₂₄." c.verified True c.axiom_level "kernel-standard" c.olean_sha256 89b6fac7a9badc3ff64928f0… c.commit 9ee4d06 X-KLV-Commit-Hash: 9ee4d06
What it is

Ask whether it passed the kernel

One call. No Lean toolchain, no dependencies, and an answer you can check without us.

Source
A Lean 4 proof
Written by whoever made the claim — a paper, a lab, you.
.lean
Checked by
The Lean 4 kernel
Not by us. No sorry, no added axiom, or it does not pass.
— kernel-standard
Recorded by
The Kenosian oracle
Which axioms the proof leaned on, and the sha256 of the compiled artifact.
— modules · — domains
Sealed by
TTTPS
Fixes those bytes to a moment. Tamper-evident afterwards, verifiable without a key.
commit —
What this does not answer, and what verified means

It does tell you whether a mathematical claim was accepted by the Lean 4 kernel, which axioms the proof leaned on, and the sha256 of the compiled artifact so you can confirm the answer offline.

It does not reproduce a paper’s experiments. GPU nondeterminism, closed simulators and shifting datasets are a different problem and we make no claim on it.

verified is true or null, never false. Null means the compiled artifact is absent at that commit — that is unknown, not false. We do not sell a true we cannot back. And when a proof uses native_decide the level drops to compiler-trusted, because the compiler enters the trusted base and hiding that would be the whole game — which is why the count above is the kernel-standard one.

Install and ask

The client is a thin shell. It computes nothing — parsing, hashing and the dependency graph are done ahead of time by the Rust indexer, and this reads the answer.

# no dependencies, no Lean toolchain pip install kenosian-vault from kenosian_vault import Vault c = Vault().theorem("KLean.Atoms.Bio.AccelerationMonotone.acceleration_monotone") c.verified # True c.axiom_level # 'kernel-standard' — propext, Classical.choice, Quot.sound c.olean_sha256 # the compiled artifact, checkable without us c.commit # the vault commit that answered

Auditing something? Pin the commit. A vault that moves under you gives different answers to the same question.

v = Vault(expect_commit="a475917") # raises StaleVaultError if the server moved on

Python is the only client verified live above. TypeScript and Rust clients cover the same calls and are in progress, not yet published.

# in progress — not yet on npm or crates.io npm i @kenosian/vault cargo add kenosian-vault
Core Verification Oracle

The same answer, riding on a sealed moment

theorem() above always tells you whether the kernel accepted a claim. Every certificate it returns also carries a seal field — not a fresh stamp for that one query, but the TTTPS receipt for the moment this vault's currently-served commit was itself admitted. Ask about two unrelated theorems at the same commit and you get back the identical receipt_id, because it is the snapshot that is sealed, not each answer inside it.

# same call as above, reading one field further c = Vault().theorem("KLean.Modular.Burnside.m24_irrep_count") c.seal # dict — the vault's admission receipt, or None if absent c.seal["receipt_id"] # 'd017cc7dffff572a7adc3c1d' c.seal["sealed_at"] # '2026-08-10T03:30:24.740384+00:00' c.seal["time_source"] # 'roughtime_chain'

Check that receipt independent of us, the same way TTTPS's own verify endpoint does — no key, no account, no trust in this page required:

curl 'https://kpp.kenosian.com/v1/verify?receipt_id=d017cc7dffff572a7adc3c1d' # {"verified": true, "reason": "Signature and timestamp match the anchored digest.", …}

This is a different layer from the LangChain / LlamaIndex / Ragas integrations TTTPS ships for sealing general LLM and agent output — those seal what a model said; this seals the moment this vault's own snapshot was let in. The full install matrix for this SDK (Python published; TypeScript and Rust in progress) is also listed on the TTTPS API reference page, described there as the core oracle beneath those framework integrations.

What is in it

Sixteen filing domains, and under them the thing a directory listing cannot show: what rests on what. Every point below is a Lean module in the vault. Every line is an import — a dependency the kernel had to discharge before the module on the other end could compile. Nothing is typed by hand; the picture is read from the index at the commit the console below is serving.

Start with the domains. Tick one to open it, or search — the box reaches every module name and every claim at once. Pick a module and its theorems are fetched from the same endpoint you would call yourself, one request per name, so what you read here is what you would get back.

Prove your Lean

The other direction. Above, you ask the vault what it holds; here you hand it something. The order is the point: the kernel on your machine decides whether the proof stands, and only then does anything leave the room. We never run your Lean.

Yours
A Lean 4 file
Whatever you have proved, in the project you already build in.
my_proof.lean
Judged by
Your own kernel
Counts sorry and axiom in the source, runs your lake, then reads what #print axioms actually says.
kvault check
Sent
The digest, not the file
Only what passed as kernel-standard, and only its sha256. The proof stays on your disk.
kvault submit
Admitted as
A pull request
Hand back the receipt with the file. If the sealed digest matches the bytes, a branch opens against the vault repository. Merging stays a human decision.
POST /v1/klv/submit

The second step is the one worth reading twice. It calls the Lean toolchain already on your machine and nothing else — our server can be switched off and it still returns a verdict. Passing means the axiom list came back a subset of the standard three; a proof leaning on native_decide is reported as compiler-trusted and the command stops there rather than sealing something we would not stand behind.

Build and run
# a Rust CLI, not on crates.io yet cargo build --release -p kvault kvault login you@example.com # a key at once, no approval kvault check my_proof.lean # your kernel only. no network call kvault submit my_proof.lean # seals the digest of what passed # step four is one call, not a subcommand yet POST /v1/klv/submit X-API-Key: ... { receipt_id, path, content }
What comes back
PASS kernel-standard axioms propext, Classical.choice, Quot.sound sha256 b6f355903b0f02fbbee75aab… SEALED receipt_id 636cdc88d80db576941cfcfc time roughtime_chain verify /v1/verify?receipt_id=…

The last step does not run Lean either. It re-hashes the bytes you send and refuses unless they are the bytes the receipt was sealed over, then opens a branch on the vault repository. Nobody at this end decides whether the mathematics is right; the kernel already did that on your machine, and a person still has to read the pull request before it merges.

That receipt is a real one, from this vault. Ask the same question the page asks and you get the same answer: /v1/verify?receipt_id=636cdc88d80db576941cfcfc. The source of the client is on GitHub — Helm-Protocol/kenosian-vault — because a tool that tells you what your kernel said is a tool you should be able to read.

Why the local check is a filter and not a gatekeeper

The verdict comes from your machine, so you could edit the file and print anything you like. That is fine, because nothing rests on it. Its whole value is that a failure is known before you open a pull request rather than after.

What decides a listing is the same kernel run again where you cannot touch it. It reads the two things Lean itself says — the declaration uses 'sorry' warning and the axiom list. It does not grep for the word: a comment reading “zero sorry” is prose. It does not trust the exit code either, since a file whose only theorem is by sorry compiles and exits 0.

The two seals answer different questions. The first says you had this at this time. The second says the kernel accepted it at this time. Collapsing them into one would suggest that sealing something makes it true, and sealing a false claim only records that the false claim existed.

Try it

Open-source compute, sealed in time.

The kernel is open and the contracts are public, so anyone can recompute what you got. Sealing takes that reproducible result and fixes it to a moment, tamper-evident afterwards. One establishes what is true; the other establishes when it existed. Everything below also works as plain HTTP in the reference.

1
Choose what to seal
2
Enter a value

Checked against the bound proved in Lean 4 for that metric. No key needed, nothing recorded.

Supply your own digest to bind the receipt to a full run record (cohort, model version, fold) without transmitting any of it.

3
Seal it with TTTPS

Creates a timestamped, tamper-evident receipt. This is the only step that writes a permanent record and spends one seal from your quota.

No key yet? with a thousand free seals, no approval, no card.
4
Verify the receipt

Runs with no key at all, which is the point: whoever you hand a receipt to can re-check it without an account here.

Values you enter are used to answer the request and discarded. Only a SHA-256 digest is stored, and a receipt attests when a result existed and that it has not changed since, not that it is scientifically correct.

Two ways in

One asks. The other computes.

GET — ask whether it was proved

GET /v1/klv/theorem/{fqn} answers one question: did this statement pass the Lean 4 kernel, on which axioms, and with what compiled artifact. No key, no account. The URI is the citation — paste it in a footnote and whoever reads it gets the same verdict, pinned by the X-KLV-Commit-Hash header. The graph above maps this layer: every statement inside those modules is reachable this way, including the ones that take no input.

POST — hand it numbers

The contracts below take your inputs, compute, and return a certificate naming the theorems that stand behind the formula. This is the narrower layer, and deliberately so: a contract only makes sense when there is something to vary. A closed fact — M₂₄ has exactly 26 irreducible representations — has no input to give it, so it lives in the layer above and is queried, not called.

So the two lists are not the same length, and that is not an omission. Most of what the vault holds is a closed fact that can be looked up but not run. If a domain appears in the graph and not in the sections below, it means we have proved things there and have not yet written a calculator for them — the proof is the asset, the calculator is a handle on it.