Anthropic's FlashProve Cryptographically Proves Which AI Model Answered You
Anthropic's FlashProve generates cryptographic proofs that a response came from a specific LLM, running 70x faster than prior open-source systems.
- Anthropic released FlashProve, open-source cryptographic proofs that a response came from a specific LLM.
- Generates proofs for 400B Llama 4 Maverick at 110 tokens/second on a single H100 GPU.
- Proofs are ~19 MB and verifiable in seconds on an ordinary 24-core CPU without weights.
- Roughly 70-95x slower than raw vLLM inference, but orders of magnitude faster than prior zkML.
- Soundness guarantees formally verified in Lean 4; weights stay hidden, architecture does not.
- Limited to 1,024-token contexts, greedy decoding, and MoE architectures; shipped as unmaintained research prototype.
Anthropic has released FlashProve, an open-source research prototype that lets a provider prove which model generated an AI response. The system targets a basic problem with hosted inference: customers, auditors, and safety evaluators usually have no independent way to confirm that an API used the promised weights.
Hosted-model customers must currently trust the provider’s routing and infrastructure. A router could substitute a cheaper model, a compromised server could alter responses, or a production deployment could differ from the version examined by an evaluator. FlashProve attaches a cryptographic proof to each proved batch, allowing an external verifier to check the computation without receiving the model weights.
In Anthropic’s research report, one 80 GB H100 produces proofs for Llama 4 Maverick, a 400-billion-parameter mixture-of-experts model, at about 110 tokens per second. A 1,024-token request produces a proof of roughly 19 MB. Proving consumes about 70 to 95 times as much GPU time as native generation with vLLM, excluding the original inference work.
A fingerprint for the model
A zkSNARK, short for zero-knowledge succinct argument of knowledge, allows one party to prove that a computation followed specified rules while keeping selected inputs private. FlashProve first creates a cryptographic commitment, which acts as a fingerprint for one exact set of model weights. The provider can then prove that those committed weights processed a particular prompt and produced the reported output.
FlashProve can reject responses generated with different weights or altered arithmetic because either change breaks verification. Its guarantee covers a defined computation, while adjacent security and governance claims require separate controls:
| Claim | FlashProve’s coverage |
|---|---|
| Response integrity | The proof binds the prompt, output, and committed model computation. |
| Model identity | The proof identifies a commitment. A provider or evaluator must authenticate the mapping between that commitment and the advertised model. |
| Weight confidentiality | Zero knowledge hides the committed weight values and the experts selected for each token. The model architecture remains visible. |
| Server compromise | Altered outputs fail verification. Passive weight theft, prompt theft, and unrelated malicious processes remain outside the security model. |
| Compute accounting | A certificate shows that specified inference occurred. Undisclosed training or other unproved workloads require additional auditing. |
Proofs arrive after generation
During a one-time setup phase, FlashProve commits to the model weights in about 39 minutes under the reported configuration. That commitment can be reused across roughly 16 million requests. During operation, the system generates proofs after responses have been produced and groups requests into batches, reducing repeated cryptographic work.
Why one H100 is enough
- Sparse expert use: Each Maverick token activates about 17 billion of the model’s 400 billion parameters. Proving work scales with the active parameters while concealing which experts were selected.
- Batched openings: The prover opens the weight commitment once for a batch instead of repeating that work for every request.
- Weight streaming: The pipeline streams model segments from about 290 GB of host memory, allowing the proving workload to fit on one 80 GB H100.
FlashProve constructs its zkSNARK from an interactive oracle proof compiled with hash functions. Code-proximity tests, linear constraints, and lookup arguments check that the execution trace follows the model’s arithmetic. The hash-based construction is designed to resist known quantum attacks and resembles techniques used by production blockchain proof systems such as Starknet.
From hours to seconds
Published results from earlier provable-inference systems provide useful scale, although they use different hardware, models, arithmetic formats, batch sizes, and security settings. The figures therefore indicate broad progress rather than a controlled benchmark.
| System | Model | Tokens per second |
|---|---|---|
| ZKML (2024) | GPT-2, 117M parameters | About 0.006 |
| zkLLM (2024) | LLaMA-2-13B | About 2.5, batched |
| zkGPT (2025) | GPT-2 | About 0.05 |
| VerInf | Llama 4 Maverick, 400B | About 0.02 |
| DeepProve | Gemma 3 and GPT-2 | 1.4 to 2.9 |
| FlashProve | Llama 4 Maverick, 400B | 110 |
VerInf offers the closest model-scale comparison because it also targets the full Maverick model. It reports 14.3 hours to prove 1,000 tokens on a DGX Spark, producing a 93.6 GB proof that required almost a day to verify. FlashProve reports a roughly 19 MB proof and verification within seconds on a 24-core CPU, subject to the configuration differences between the projects.
Lean checks the protocol
Anthropic says Claude contributed much of the optimization work, and the team used Lean 4 to check the protocol’s completeness, soundness, and zero-knowledge properties. Machine-checked proofs reduce the risk that an optimization silently invalidates the cryptographic guarantee.
At the quoted security parameters, the probability that a fraudulent proof passes verification is bounded by q/2124 + 2−101 after q hash queries. This bound applies to the formal protocol under its stated cryptographic assumptions.
The release includes a fast C++ verifier for routine use and a slower Lean verifier connected to the soundness theorem. The Lean path provides a higher-assurance reference for checking acceptance behavior, although the entire optimized C++ implementation has not been formally verified.
The deployment constraints
- Short contexts: The prototype supports up to 1,024 tokens, far below the context windows offered by current long-context models.
- Restricted arithmetic: Proofs cover an integer-arithmetic representation of the model. A floating-point production deployment may produce different results.
- Greedy decoding: The proved decoder deterministically selects the highest-scoring token. Random sampling and common controls such as temperature require additional work.
- Visible architecture: Weight values and expert routing remain private, but the verifier knows the mixture-of-experts structure.
- Uncovered side channels: Timing and resource-use patterns could leak information about private values.
- Delayed attestation: Proofs are generated after inference, so applications must tolerate verification latency and retain enough request data to match responses with proofs.
- Research status: Anthropic labels the repository “not maintained” and presents it as an artifact for experimentation rather than a supported production library.
Where it fits today
Teams operating model gateways, safety evaluations, regulated workflows, or high-value automated transactions can use FlashProve as an audit mechanism. A deployment would authenticate the model commitment, preserve request and response identifiers, generate proofs for completed batches, verify them on separate infrastructure, and record the results with the corresponding audit logs.
The reported 19 MB proof size and 70-to-95-times proving overhead make universal coverage expensive. Sampling production traffic, certifying evaluation runs, investigating disputed outputs, and proving selected high-risk transactions offer more practical starting points.
FlashProve moves proof-of-inference for a frontier-scale mixture-of-experts model into measurable engineering territory. Production adoption still depends on longer contexts, sampled decoding, lower proving costs, authenticated commitment distribution, and maintained implementations.
Comments
