proof of model · attested inference · in build
Prove which model answered.
Proof of Model puts an attested gateway in front of model serving: every response leaves with a dual-signed receipt binding what was asked, what answered, and the measured runtime that carried it — sealed into a public daily checkpoint, checkable offline by anyone.
In build. There is no gateway endpoint to point at yet. What is already running is the half underneath: the receipt envelope, the daily seal and the published checkpoints, live on the ledger and arriving in the open on the receipt feed. Verification is live too, and free — check a receipt and the work happens in your browser.
the gap
Providers quantize, downgrade and reroute under load, and the buyer cannot tell from the outside: am I getting the model I am paying for? The router and reseller layer makes the claim unverifiable by construction — the response looks the same whichever weights produced it, and the console reporting on it belongs to the party being asked. The academic answer, zero-knowledge machine learning, is computationally absurd at this scale. The practical one — an attested runtime plus a signed receipt — has sat unproductized.
the shape of it
what a receipt binds
- input_hash
The digest of the exact request. The prompt itself is never on the receipt and never in the seal — you hold the content, and the hash is what ties the two together later.
- output_hash
The digest of the exact response. Change one token of what you were shown and the receipt stops matching it.
- weights_digest
The pinned digest of the model that served the request. This is the substitution detector: a provider who changes what answers changes this value, and the change is public on the next sealed checkpoint whether or not anyone announced it.
- enclave_measurement
The fingerprint of the runtime the gateway itself ran inside — code identity, as distinct from the model identity above. New to you? The academy starts there.
- signature
Ed25519 and ML-DSA-44 over the canonical body, against a key id in the published keyset. Two signatures because one of them is expected to outlive quantum computers and the other is what everything can check today.
The wire schema froze before the first receipt was issued, with golden vectors and an offline verify kit, the way the attestation receipt did — no field is added to it without a version bump. Watch it work: paste a receipt and your own browser checks the signatures, and the seal if it has been sealed.
two tiers, and the line between them
commitment
Externally served models, any size
The receipt proves which declared endpoint and which pinned weights digest served each request, through a gateway whose own code is attested. It does not claim the inference happened inside the enclave, because it did not. What it gives you is that a change of pin cannot be quiet: it lands in the next sealed checkpoint.
computation
Small and medium models, inside the enclave
When the model runs inside the attested runtime itself, the receipt proves the computation: this inference happened in this measured enclave, on these weights. It is the stronger claim, and it is bounded by what a CPU enclave can hold — which is why the tier above exists at all.
what it does not prove
- Not in-enclave execution for an externally served model. That tier proves the commitment and the routing, and stops there.
- Not frontier-scale inference inside an enclave. Nitro Enclaves are CPU-bound. Confidential-computing GPUs are the named roadmap for that, and a roadmap is not a capability — when the hardware path ships, the claim changes here first.
- Not training-data provenance. A digest pin says which artifact answered you. It says nothing about how that artifact was made, and no amount of signing will make it say otherwise.
- Not a verdict issued by a public chain. A daily anchor is a witness to a commitment and stops there. What was measured is checked by you, offline, against artifacts we publish and cannot retract — the mechanism is written out on the ledger.
how it is delivered
The gateway ships as a sealed appliance, pulled from a private registry under your own license role and run on enclave-enabled instances in your AWS account. Your keys, your compute, your custody, your bill for the compute. The metered part is the proof layer on top: receipts issued, seals published, measurements watched.
The image is closed and stays closed. What replaces “read the source” is the measurement: published release fingerprints, receipts that bind them, and a public ledger anyone can check us against without asking permission. Charging for issuance and never for verification is the whole commercial logic; the MCP server already runs that way.
three seats
- the provider
Deploys the gateway in front of their model serving and pins a digest in a short ceremony. Their API is unchanged except that every response carries a receipt. Billed per sealed receipt; this is the seat that pays.
- the buyer
Turns a receipt into a verdict — on a page, or offline from a command line against published checkpoints, or as a standing watch that says the day a weights digest changes. Free, no account, and it stays free.
- the agent
Checks the receipt on an inference before acting on it, with no human in the loop. The MCP server already does this for attestation receipts; inference receipts join it when the schema freezes.
early access
The first deployments will be hand-run with us, in the customer’s account, with the ceremony recorded. There is nothing to sign up for here yet — the notify list on the front page is where the first gateway release is announced.