How it works.

From model output to verifiable evidence

Think of a sealed envelope. Before anything runs, the model owner seals their weights in one envelope and the input is sealed in another. Sealing produces a short code, called a fingerprint, that they hand out. The fingerprint reveals nothing about the contents, with cryptographic protection against substituting different contents.

Now the model runs and produces an answer. Along with it comes a proof: a small file that says the contents of envelope A, applied to the contents of envelope B, produce exactly this answer. You check that proof against the two fingerprints. Either the mathematics works out or it does not.

Verification requires the receipt, the approved verification key and the agreed fingerprints. You do not need the private weights or input values. The claim covers the specified computation; assessing the model’s quality is a separate task.

What is in a receipt

A receipt contains public evidence for verification. The private weights, input values and salts are not included:

• The model fingerprint: a salted Poseidon hash of the weights and the checkpoint number.
• The input fingerprint: a salted Poseidon hash of the input features.
• The answer: as a fixed-point integer, plus a copy inside the proof's public signals.
• The request details: task id, model id, operation, verification key id, step and a random challenge.
• The proof: three group elements. About 800 bytes of Groth16 over the BN254 curve.

Private random salts protect the fingerprints against guessing attacks. The published result can still reveal information about the model or input, especially across repeated queries.

The mathematics

The claim is expressed as an arithmetic circuit, written in Circom 2. The circuit takes the weights, the salts and the input features as private inputs, and the two fingerprints, the step and the challenge as public inputs. Inside, it enforces three things at once:

• Re-hashing the private weights with the private salt reproduces the public model fingerprint.
• Re-hashing the private features reproduces the public input fingerprint.
• The linear combination of those weights and features equals the answer that is published as a public signal.

Because all three constraints live in one circuit, they cannot be satisfied separately. A proof exists only if the same weights that match the fingerprint are the weights that produced the answer.

The circuit is compiled to a constraint system and proved with Groth16. Verification is a pairing check against a verification key: constant-size, and fast regardless of how the proof was produced. All arithmetic happens in a prime field, so the model is fixed-point, not floating-point. Weights and features are integers scaled by 256, and the prediction is encoded with an offset so negative values survive the field encoding.

The current circuit proves a two-feature linear regression. A second circuit proves a weight update: given a previous checkpoint fingerprint and a data fingerprint, it enforces one step of gradient descent at rate 1/16 with floor rounding, and outputs the next checkpoint fingerprint. That is what makes a retraining step checkable instead of merely announced.

Recorded proofs versus live acceptance

The demo on the home page verifies a proof that was generated earlier on our machine. The pairing check runs in your browser and detects changes to the proved statement. It establishes a mathematical statement, not a fresh event. Replaying it tomorrow proves the same thing it proves today.

Freshness is a separate problem, and it is handled outside the proof. The command-line controller issues each task with a random challenge and an expiry, remembers which tasks it issued, rejects a receipt whose challenge it did not issue, rejects one that arrives late, rejects a replay of one it has already accepted, and advances its checkpoint only after accepting a valid update. The controller's accepted state determines which checkpoint is current. A single proof cannot establish that on its own.

The controller can reject expired or repeated submissions. These checks govern receipt acceptance; they do not prove the physical time of execution or that the computation ran only once.

What it does not prove

The proof is narrow on purpose. It does not establish:

• That the answer is any good. Accuracy, calibration and fairness require separate evaluation.
• That the input is true. The proof binds a fingerprint of the input, not the reality behind it. Source data needs its own authenticity checks.
• How the input was produced. Whatever preprocessing turned raw data into those features sits outside the circuit.
• What else the provider did. A proved computation does not rule out other computations, other models, or a discarded second opinion.
• That the fingerprints mean what you assume. Committing to weights is only useful if you know how the committed model was obtained. That first link is a trust decision, not a proof.
• Anything about a language model. The current implementation covers a small numeric model, not full LLM inference.

Technology status

Inferstamp is a working research prototype from baz consulting. The demonstration uses real Circom circuits and Groth16 proofs. Production use requires further engineering and independent review:

• The trusted setup is a development ceremony, not a multi-party production ceremony.
• There has been no independent security audit.
• In the local demo the worker and the controller run as the same operating-system user. Separate directories are not isolation.
• Update history is checked one step at a time. There is no recursive proof over a whole training run.
• The examples use synthetic data and demonstrate technical capability, not customer deployments.

Measurements

Measured on 17 September 2026, on one laptop, for the two-feature circuit on this site, a deliberately tiny model. Treat these as an order of magnitude, not a benchmark:

• Verifying in a browser: tens of milliseconds, including the fingerprint and key checks. Constant in the size of the computation.
• Proving: roughly half a second per inference, including process startup.
• Receipt size: under a kilobyte of proof, plus the fingerprints.

Verification cost is the number that stays flat as models grow. Proving cost is the one that does not, and it is the reason this technique fits small, high-stakes decisions long before it fits a chatbot.