In Verifiable Reflexivity we argued that every catastrophic failure in crypto has been the same failure - a system making claims about itself that nobody verified - and that the defining property of this industry is the closing of that loop with proofs. We ended with a warning: the next dominant economic actors will be AI agents, and an economy of unverified self-describing machines is the FTX problem at unfathomable speed.
This piece begins the constructive program. If agents must prove themselves, the first question is brutally concrete: what does it mean to prove that a model produced an output?
The question sounds simple. It is not. “The model said X” is actually four distinct claims stacked on top of each other, and almost every project in this space conflates them:
Claim 1 - Identity. This specific model - these weights, this architecture, this version - was the one that ran. Without identity, “the model said X” is meaningless; any output can be attributed to any model.
Claim 2 - Execution. The forward pass was computed correctly: the output is genuinely what those weights produce on that input, not a cheaper model’s answer, a cached answer, or a fabricated one.
Claim 3 - Input integrity. The input the model saw is the input the relying party believes it saw - no prompt substitution, no hidden system-prompt injection, no context tampering.
Claim 4 - Policy conformance. The output was produced under the stated operating policy: the right sampling parameters, the right tools available, the right constraints active.
Call a system that establishes all four fully attested inference. Almost nothing in production today establishes even one.
There are exactly four known mechanisms for making inference claims checkable, and they form a stack - ordered by the strength of the guarantee and, not coincidentally, by cost.
Replication. Multiple independent parties run the same model on the same input and compare. This is what blockchains do for state transitions, and what some decentralized inference networks do for models. It is conceptually simple and economically brutal: N-times redundancy for every inference, plus the unsolved problem that floating-point non-determinism across hardware makes “the same output” a fuzzy predicate. Replication verifies honestly only what is cheap enough to run many times.
Economic verification. Optimistic schemes: assume the result is honest, allow a challenge window, slash the prover if a fraud proof lands. This inherits the deep limitation of all optimistic systems - the guarantee is only as strong as the watchfulness of challengers and the latency of the window. An agent that acts on an inference now cannot wait for finality on whether the inference was real.
Hardware attestation. Trusted execution environments sign a statement: “this enclave ran this binary on this input”. TEEs are fast - near-native inference speed - and they are the pragmatic workhorse of verifiable AI today. But the trust model bottoms out in the silicon vendor, and the history of enclave security is a history of extraction attacks. Attestation relocates trust; it does not eliminate it. It is a claim about a claim, signed by Intel.
Cryptographic proof. Zero-knowledge proofs of the computation itself: the forward pass executed inside a proving system, yielding a certificate that anyone can check, forever, with no trusted vendor, no challenge window, no redundancy. This is the only mechanism in the stack whose guarantee is unconditional. It is also, today, the most expensive - proving frontier-scale inference in real time is beyond the current state of the art, and any project telling you otherwise is selling something.
Here is the position we will defend, and it is not the maximalist one you might expect from a ZK company: the inference trust stack is a stack, not a competition. The error of this moment is treating these four mechanisms as rivals.
The correct architecture composes them - attestation for the heavy tensor work today, cryptographic proofs for the layers where unconditional guarantees matter most, replication and economics as transitional scaffolding - with the boundary between layers migrating downward, year by year, as provers get faster.
The endgame is cryptographic. The path there is hybrid.
If full cryptographic proof of frontier inference is not yet practical, the engineering question becomes: which of the four claims do you prove cryptographically, today, and which do you cover with weaker mechanisms?
The answer falls out of asking where the adversary’s leverage is. An agent operator who wants to cheat does not need to fake a matrix multiplication. The cheap attacks are at the edges: swap the model for a smaller one (identity), tamper with the context (input integrity), silently change the sampling policy or the tool set (policy conformance). The expensive-to-fake middle - the raw forward pass - is paradoxically the part least worth faking, because the edges are unguarded.
This inverts the industry’s instinct. The zkML field has spent years racing to prove Claim 2 - the forward pass - because it is the hardest and most glamorous problem. But a proof of correct execution over an unverified model identity and an unverified input is a proof of nothing in particular. Proof of inference without proof of identity is theater.
So the practical stack, ordered by leverage per proving cycle:
First, identity: a cryptographic commitment to the exact weights - cheap to produce, cheap to verify, and the precondition for every other claim meaning anything.
Second, policy and orchestration: the surrounding program - which model was called, with what parameters, what tools, what context assembly - is ordinary code, exactly the kind of thing a general-purpose zkVM proves efficiently today.
Third, input provenance: where the context came from, which is the oracle problem wearing a new costume. And only then, execution, covered today by attestation-plus-commitment, migrating to full proof as the hybrid pipeline matures.
The layer that most urgently needs unconditional verification is not the neural network, but the orchestration layer - the policy logic wrapped around the model. That layer is where agents make claims about themselves. That layer is reflexive, and is provable now.
What is missing is not any single technology. It is an agreement about what “verified inference” means - a way for a relying party to know, when it sees the word “verified”, which of the four claims are established and by which of the four mechanisms.
We propose the industry adopt the habit of stating inference guarantees as a tuple: identity, execution, input, policy - each annotated with its mechanism. A trading agent might today honestly advertise: identity proven, policy proven, input attested, execution attested. A regulator, a counterparty, or another agent can price that tuple. What nobody can price is the bare adjective “verifiable”, which is currently doing more marketing work than engineering work across this entire sector.
Before we turn this sketch into a formal proposal, we need to establish what each layer demands - and why the agent economy cannot be built on the bare adjective.
One CPU, one vote gave us money whose claims anyone could check. The next system of record is cognition itself. The stack above is how its claims become checkable - layer by layer, mechanism by mechanism, until “the model said X” is nothing short of a verifiable receipt.
ZKM builds Ziren, a general-purpose zkVM and proving stack. zkm.io
In Verifiable Reflexivity we argued that every catastrophic failure in crypto has been the same failure - a system making claims about itself that nobody verified - and that the defining property of this industry is the closing of that loop with proofs. We ended with a warning: the next dominant economic actors will be AI agents, and an economy of unverified self-describing machines is the FTX problem at unfathomable speed.
This piece begins the constructive program. If agents must prove themselves, the first question is brutally concrete: what does it mean to prove that a model produced an output?
The question sounds simple. It is not. “The model said X” is actually four distinct claims stacked on top of each other, and almost every project in this space conflates them:
Claim 1 - Identity. This specific model - these weights, this architecture, this version - was the one that ran. Without identity, “the model said X” is meaningless; any output can be attributed to any model.
Claim 2 - Execution. The forward pass was computed correctly: the output is genuinely what those weights produce on that input, not a cheaper model’s answer, a cached answer, or a fabricated one.
Claim 3 - Input integrity. The input the model saw is the input the relying party believes it saw - no prompt substitution, no hidden system-prompt injection, no context tampering.
Claim 4 - Policy conformance. The output was produced under the stated operating policy: the right sampling parameters, the right tools available, the right constraints active.
Call a system that establishes all four fully attested inference. Almost nothing in production today establishes even one.
There are exactly four known mechanisms for making inference claims checkable, and they form a stack - ordered by the strength of the guarantee and, not coincidentally, by cost.
Replication. Multiple independent parties run the same model on the same input and compare. This is what blockchains do for state transitions, and what some decentralized inference networks do for models. It is conceptually simple and economically brutal: N-times redundancy for every inference, plus the unsolved problem that floating-point non-determinism across hardware makes “the same output” a fuzzy predicate. Replication verifies honestly only what is cheap enough to run many times.
Economic verification. Optimistic schemes: assume the result is honest, allow a challenge window, slash the prover if a fraud proof lands. This inherits the deep limitation of all optimistic systems - the guarantee is only as strong as the watchfulness of challengers and the latency of the window. An agent that acts on an inference now cannot wait for finality on whether the inference was real.
Hardware attestation. Trusted execution environments sign a statement: “this enclave ran this binary on this input”. TEEs are fast - near-native inference speed - and they are the pragmatic workhorse of verifiable AI today. But the trust model bottoms out in the silicon vendor, and the history of enclave security is a history of extraction attacks. Attestation relocates trust; it does not eliminate it. It is a claim about a claim, signed by Intel.
Cryptographic proof. Zero-knowledge proofs of the computation itself: the forward pass executed inside a proving system, yielding a certificate that anyone can check, forever, with no trusted vendor, no challenge window, no redundancy. This is the only mechanism in the stack whose guarantee is unconditional. It is also, today, the most expensive - proving frontier-scale inference in real time is beyond the current state of the art, and any project telling you otherwise is selling something.
Here is the position we will defend, and it is not the maximalist one you might expect from a ZK company: the inference trust stack is a stack, not a competition. The error of this moment is treating these four mechanisms as rivals.
The correct architecture composes them - attestation for the heavy tensor work today, cryptographic proofs for the layers where unconditional guarantees matter most, replication and economics as transitional scaffolding - with the boundary between layers migrating downward, year by year, as provers get faster.
The endgame is cryptographic. The path there is hybrid.
If full cryptographic proof of frontier inference is not yet practical, the engineering question becomes: which of the four claims do you prove cryptographically, today, and which do you cover with weaker mechanisms?
The answer falls out of asking where the adversary’s leverage is. An agent operator who wants to cheat does not need to fake a matrix multiplication. The cheap attacks are at the edges: swap the model for a smaller one (identity), tamper with the context (input integrity), silently change the sampling policy or the tool set (policy conformance). The expensive-to-fake middle - the raw forward pass - is paradoxically the part least worth faking, because the edges are unguarded.
This inverts the industry’s instinct. The zkML field has spent years racing to prove Claim 2 - the forward pass - because it is the hardest and most glamorous problem. But a proof of correct execution over an unverified model identity and an unverified input is a proof of nothing in particular. Proof of inference without proof of identity is theater.
So the practical stack, ordered by leverage per proving cycle:
First, identity: a cryptographic commitment to the exact weights - cheap to produce, cheap to verify, and the precondition for every other claim meaning anything.
Second, policy and orchestration: the surrounding program - which model was called, with what parameters, what tools, what context assembly - is ordinary code, exactly the kind of thing a general-purpose zkVM proves efficiently today.
Third, input provenance: where the context came from, which is the oracle problem wearing a new costume. And only then, execution, covered today by attestation-plus-commitment, migrating to full proof as the hybrid pipeline matures.
The layer that most urgently needs unconditional verification is not the neural network, but the orchestration layer - the policy logic wrapped around the model. That layer is where agents make claims about themselves. That layer is reflexive, and is provable now.
What is missing is not any single technology. It is an agreement about what “verified inference” means - a way for a relying party to know, when it sees the word “verified”, which of the four claims are established and by which of the four mechanisms.
We propose the industry adopt the habit of stating inference guarantees as a tuple: identity, execution, input, policy - each annotated with its mechanism. A trading agent might today honestly advertise: identity proven, policy proven, input attested, execution attested. A regulator, a counterparty, or another agent can price that tuple. What nobody can price is the bare adjective “verifiable”, which is currently doing more marketing work than engineering work across this entire sector.
Before we turn this sketch into a formal proposal, we need to establish what each layer demands - and why the agent economy cannot be built on the bare adjective.
One CPU, one vote gave us money whose claims anyone could check. The next system of record is cognition itself. The stack above is how its claims become checkable - layer by layer, mechanism by mechanism, until “the model said X” is nothing short of a verifiable receipt.
ZKM builds Ziren, a general-purpose zkVM and proving stack. zkm.io
