Oracle-Free Consensus
Whitepaper →
The Gap
zkVMs
Prove execution. Not inputs.

Every major zkVM in production today provides a strong guarantee: the computation ran correctly on the inputs it received. None of them provide a guarantee about where those inputs came from or whether they were manipulated before the circuit executed. That gap is structural, not incidental.

What Each System Guarantees
System
What it proves
Input integrity
Risc Zero
Computation ran correctly on given inputs
Not covered. Inputs are trusted.
SP1 (Succinct)
Computation ran correctly on given inputs
Not covered. Inputs are trusted.
EZKL
Neural net inference ran correctly on given inputs
Not covered. Data pipeline is trusted.
Noir / Barretenberg
Circuit constraints satisfied
Not covered. Witness is trusted.
Halo2
Polynomial constraints satisfied
Not covered. Prover inputs trusted.
Markovian Protocol
HMM inference ran correctly, starting state and observation sequence proven
Structural. Inputs derived from block hash. No external channel.

The Attack Scenario

Consider a fraud detection model deployed inside a zkVM to verify financial transactions. The proof confirms the model ran correctly. A malicious data supplier feeds manipulated transaction records before the circuit executes. The model receives clean-looking inputs, classifies the transaction as legitimate, generates a valid ZK proof.

The proof is mathematically correct. The conclusion is fraudulent. The zkVM did exactly what it was designed to do.

// What the ZK proof verifies
✓ model.run(inputs) produced output O
✓ computation followed correct execution trace
✓ no constraint violations

// What the ZK proof does not verify
✗ inputs were not modified before circuit execution
✗ data source is honest
✗ pipeline between origin and circuit is tamper-free

This is not a flaw in Risc Zero or SP1. It is a gap in the trust model that every zkML deployment inherits by default. The computation layer is verified. The input layer is assumed.

Why This Matters Now

$490M
Lost to input manipulation in DeFi 2022-2024
23%
Of 2026 DeFi exploits via input-layer attacks
0
Production zkML systems with structural input integrity

zkML is moving from research into production infrastructure. Risk models, credit scoring, fraud detection, compliance verification, each use case involves a model receiving inputs from an external source. As the value secured by these models grows, the input layer becomes the primary attack surface.

The ZK proof community has built strong execution integrity guarantees. Input integrity has not received equivalent attention. That asymmetry is where the next generation of exploits will live.

The Structural Solution

The Markovian Protocol solves input integrity for a specific computation class: systems where inputs can be derived deterministically from public chain state.

The starting state vector V is derived from SHA-256 of the previous block hash. The observation sequence O is a function of the same block hash. Both are public, deterministic, and verifiable by any observer without trusting the prover.

There is no external input channel to compromise. The inputs are chain state. A BN128 Schnorr zero-knowledge proof commits the computation result. The verifier reproduces V from the same block hash and checks the proof.

This is a narrow solution. It does not generalize to computations that require off-chain data. For the class of computations where inputs can come from chain state, it provides a stronger guarantee than any existing zkML approach: input integrity is structural rather than assumed.

Full construction in whitepaper section 6.8: Verifiable AI Inference, The Input Integrity Gap.

Technical Specification

The full protocol specification covers the HMM inference mechanism, BN128 Schnorr proof construction, Viterbi determinism, and the input integrity distinction in detail. The binding problem, the pre-computation argument, and the narrow scope of the solution are documented honestly.