Proof of
inference.
A 2026 guide.

What is proof of inference?

Proof of inference is the cryptographic claim that a specific AI model produced a specific output for a specific input at a specific moment in time. It is the AI counterpart of what “proof of execution” means for traditional programs: not just “we say it ran,” but “here is a record that anyone can verify it ran, with this model, on this data, in this order.”

Proof of inference is what regulators, courts, customers, and counterparties will increasingly ask AI operators to produce. The EU AI Act, NIST AI RMF, and ISO/IEC 42001 all converge on the same demand: “show me the audit trail.” What changes is how you produce one that survives a five-year subpoena.

Application logs, vendor dashboards, and screenshots are not proof of inference — they are assertions of inference, made by the same party being audited. Proof of inference requires a record signed by hardware, attested by independent parties, or anchored to a chain the operator does not control.

The audit market arrives in 2026.

Three independent regulatory regimes hit binding-or-near-binding status in the same window:

• EU AI Act Article 12 requires high-risk AI systems to automatically record events for the lifetime of the system, with traceability sufficient for post-market monitoring. General-purpose obligations applied from August 2025; full obligations roll forward through 2026 and 2027.
• NIST AI Risk Management Framework (AI RMF 1.0) shipped in early 2023; the GenAI Profile shipped July 2024. US federal contracting and finance regulators are increasingly treating NIST AI RMF compliance as table-stakes.
• ISO/IEC 42001:2023 is the first certifiable AI management system standard. Certification audits use the same evidence patterns auditors are familiar with from ISO 27001 — and require demonstrable AI decision records.

Together these create the first generation of AI auditors— a professional category that did not meaningfully exist in 2024. Their first question to every AI operator is the same one regulators will ask in five years: what verifiable evidence can you produce?

Two cryptographic paths.

There are exactly two production-grade approaches to proof of inference shipping today, and they make opposite tradeoffs.

ZKML — math instead of trust.

Zero-knowledge machine learning (ZKML) generates a succinct proof that a particular model, given a particular input, produced a particular output. The proof is short (typically kilobytes), and verifying it is much cheaper than re-running the model.

The trade is on the prover side: generating a ZK proof of a modern transformer inference takes seconds to minutes, often requires specialized hardware, and scales linearly with model size. Today this means ZKML is practical for small models (sub-100M parameters) and for cases where the inference cost can absorb the prover cost.

ZKML is the right call when you need the strongest possible guarantee and the prover cost is acceptable: high-value financial decisions, regulator-mandated proofs for specific high-risk classifications, on-chain games where ZK fits the architecture natively.

Cryptographic anchoring — receipts you can replay.

Cryptographic anchoring takes a different angle: don't prove the computation itself, prove the record of the computation. Every span, event, decision, and tool call becomes a node in a rolling-hash chain. The chain is bundled into a Merkle tree. The Merkle root is anchored to a public chain (in our case Cardano L1, metadata label 2222).

What this guarantees:

• Tamper-evidence. Reorder, insert, or delete any event and the rolling-hash chain breaks. Every chain mutation is detectable.
• Public verifiability. Anyone with the txHash can verify the inclusion proof against Cardano. No API key, no token gating, no trust in Flux Point Studios required.
• Selective disclosure. Merkle proofs let you reveal a single decision, a single tool call, or a single observation without exposing the rest of the trace.
• Model-state pinning. Anchor a manifest hash (model checkpoint + tokenizer + system prompt + training-data fingerprint) with every inference. Drift is cryptographically detectable across the trace history.

What this does not guarantee: the trace itself is correct. If the wrapper lies about which tool was called, the lie is faithfully anchored. Mitigation: embed signed tool receipts (HTTP Message Signatures, webhook signatures, on-chain TX receipts) as events. See orynq-sdk issue #60 for the standardization work in progress.

Cryptographic anchoring is what Orynq ships — both as a self-hosted SDK (~0.2–0.3 ADA per anchor) and as a managed Anchor-as-a-Service. The Materios partner chain adds committee certification on top for high-throughput cases.

When to use which.

These are not mutually exclusive. The advanced pattern is: anchor every inference cheaply with Orynq; selectively ZK-prove the small handful of decisions a regulator or court actually pulls. You get the throughput economics of anchoring and the math-grade guarantee where it matters.

How to ship proof of inference today.

If your stack involves an LLM, an agent framework, or a model server, you can add cryptographic anchoring in an afternoon. The shape:

1. 01

   Instrument the agent.

   Wrap each span / tool call / decision with the Orynq tracing primitives. Hash-chain events as they happen.

2. 02

   Pin the manifest.

   Compute a manifest hash from the model checkpoint, tokenizer, system prompt, and training-data manifest. Pass it to createTrace() before execution starts.

3. 03

   Finalize the bundle.

   At trace close, Orynq builds the Merkle tree and produces the root hash + manifest hash + bundle metadata.

4. 04

   Anchor.

   Submit a Cardano metadata transaction with the bundle under label 2222 — either with your own wallet (self-hosted, ~0.2–0.3 ADA per anchor) or via the managed Anchor-as-a-Service (x402 / Flux payment).

5. 05

   Verify.

   Anyone can replay the inclusion proof using Blockfrost, Cardanoscan, or the Orynq open verifier. No API key. No token gating. No trust.

Open questions we're still working.

Both paths have real limitations. Naming them keeps the discussion honest.

• Wrapper truthfulness. Anchoring proves the trace you recorded matches what you anchored. It doesn't prove the wrapper wrote down what actually happened. Mitigation: signed tool receipts (RFC 9421 HTTP Message Signatures, webhook signatures). Tracking issue #60.
• Manifest pinning enforcement. Model-state guarantees require the manifest hash to be pinned before execution, not backfilled. The SDK currently warns; v1.0 will enforce strictly. Tracking issue #59.
• Long-term retrievability. The on-chain anchor proves a bundle existed; you still need to preserve the bundle itself. Working on durable storage adapters (IPFS, Arweave, S3 WORM) so the retrieval guarantee ships with the SDK. Tracking issue #61.
• Governance attestation schema. Encoding “compliance officer X approved this” as a signed event inside the same Merkle bundle is currently per-operator. Standardizing the schema closes the “who governed it” gap. Tracking issue #58.
• ZKML prover economics. Practical for sub-100M-param models today; not yet for frontier LLMs. EZKL and Giza are pushing the ceiling; production usage on multi-billion-param models is a 2027+ question.