Can a cryptographic proof show which AI model answered you?

What the researchers built and measured

The implementation was evaluated on the public 4-bit version of Llama 4 Maverick, a 400-billion-parameter mixture-of-experts model that activates roughly 17 billion parameters for each token. Each verifier request covered a 1,024-token window, and each proof checked one selected token. The prover used one Nvidia H100 GPU and 24 CPU cores. The verifier used a CPU and held only the model commitment, request, claimed token and proof—not the weights.

The offline commitment step took about 39 minutes and produced roughly 6.5 MB of material. Anthropic says one commitment can cover about 16 million requests before it must be renewed. In the online measurement, the prover handled a batch of 24 requests in about 223 seconds, equivalent to 110 processed context tokens per second. Each request produced an 18.78 MB proof. Verification took 17 seconds on 24 CPU threads or 21 seconds on a single thread, including checks associated with the offline phase.

The comparison with plain inference shows the remaining cost. Anthropic ran an FP8 release of the same model in vLLM on eight H100s. On a per-GPU basis, proving a batch of 24 requests took about 72 times as long as processing the same batch in vLLM, with a reported range of 66 to 77 times across runs. Against the highest vLLM load tested, the gap was about 94 times. The systems used different quantisation and hardware layouts, so these are useful engineering reference points rather than a controlled universal overhead estimate.[1][2][3]

How the proof hides weights while binding a response

FlashProve uses a zkSNARK: a compact cryptographic argument that a specified computation was executed correctly. The provider commits to the weights once, creating a fingerprint that later proofs must open consistently. During proving, the system checks the model's integer arithmetic and the relationship between the request, committed parameters and claimed output. The proof hides the weights, intermediate values and which mixture-of-experts routes were selected. The architecture itself is not hidden.

The design is efficient partly because proof work follows only the experts actually activated for a token rather than all 400 billion parameters. It also batches completed requests and proves them after generation, resembling a parallel prefill calculation. That makes the published rate possible, but it means the proof is not generated alongside every streamed token. A service would need to decide how users receive delayed proofs, how long they wait and which requests merit verification.

The team provides Lean statements for completeness, soundness and zero knowledge, plus a Lean verifier and a faster C++ verifier. Formalisation narrows ambiguity about the intended mathematical claim. It does not eliminate every implementation risk. The repository explicitly says there is no formal proof that the fast C++ verifier implements the same protocol as the Lean verifier; the two were tested for agreement. An independent security audit, adversarial review and replication would be needed before a high-stakes deployment could rely on the faster path.[1][2][3]

The boundary conditions matter

The demonstrated model is not a normal floating-point chat deployment. It uses quantised integer arithmetic and greedy decoding, where the highest-scoring token is selected deterministically. Sampled decoding introduces randomness and floating-point serving systems may not reproduce the same arithmetic exactly across hardware and kernels. FlashProve therefore shows that large-model provable inference is technically plausible under a controlled computation; it does not yet cover the full variability of common production serving.

The 1,024-token request window is also much shorter than many marketed context lengths. Each proof covers one output token, so proving a long generated answer would require additional work and data. The prototype runs after the fact and produces an almost 19 MB proof for one request. At high traffic, proof storage, bandwidth and verification become operational questions, not footnotes. The repository labels version 0.16.0 a research artifact that is not maintained, which is a clear warning against treating it as production middleware.

Cryptographic security also sits inside a wider trust chain. A verifier needs an authentic commitment identifier from a trusted source; accepting a commitment supplied by the same possibly compromised server would weaken the assurance. Timing and other side channels are outside the stated guarantee. A valid proof shows the expected model calculation occurred, but it does not show that the same hardware was not also training another model, that the surrounding application did not alter the displayed result or that the authorised model was itself safe.[1][2][3]

What this could change for people and institutions

For customers using third-party model gateways, provable inference could eventually turn a contractual promise into a checkable technical claim. A buyer paying for a particular model could verify that its request was not silently routed to a cheaper substitute. Developers commissioning a security scan could prove which committed model examined a patch. Regulators could sample proofs to check that an approved model was served without demanding the provider disclose proprietary weights.

For workers and public-service professionals, that assurance would be narrow but valuable. A clinician or caseworker should not interpret a valid proof as endorsement of an AI recommendation. It could establish which system generated the suggestion, helping accountability and incident investigation, while domain review, data protection and appeal routes remain necessary. An invalid or missing proof would show an integrity failure; a valid proof would not resolve whether the model's reasoning was appropriate for the person affected.

Providers would face new trade-offs. Proof generation consumes substantial compute and could increase cost and energy use. Organisations may choose verification for selected high-impact transactions, audits or random samples rather than every low-risk response. Standards would also be needed for trusted commitments, proof retention, model updates and what happens when a provider changes quantisation or serving code. Without common conventions, a technically sound proof could still be difficult for customers to interpret.[1][2][3]

Evidence check and what would change the assessment

The release is unusually inspectable for company research: it includes code, protocol documentation, formal statements, a technical report and reproducible verification examples. It also comes from the team that designed and measured the system. The report has not been peer reviewed, the performance result has not been independently reproduced and the security implementation has not been publicly audited. The benchmark uses one model family, one controlled context length and specific hardware, so it cannot establish costs across providers or architectures.

Confidence would rise if independent cryptographers reproduced the proof and performance numbers, found no soundness flaws under adversarial testing and demonstrated agreement between the fast and formally verified verifiers. Practical relevance would rise with longer contexts, sampled decoding, production floating-point models, smaller proofs and lower proving overhead. Evidence from a real service would need to report latency, failure rates, bandwidth, energy use and how commitments are authenticated. Until then, FlashProve is credible progress toward model-identity proofs, not a finished trust layer for everyday AI.[1][2][3]