Cryptographically Verified AI Inference Blockchain

The trust problem in AI systems

Modern AI systems are increasingly embedded in high-stakes workflows:

• Financial executionAI output may influence economically sensitive actions.
• Governance automationModel output may shape automated protocol decisions.
• Autonomous agentsSoftware agents may act without immediate human review.
• Smart contract decision logicInference can become an input to deterministic execution.

The problem is not whether an AI result can be observed. The problem is whether independent participants can determine that the result is admissible without inheriting trust in the party that produced it. An output can be available to every network participant and still lack evidence of how it was produced.

Trusted execution environments, off-chain attestations, and operator reputation place confidence in infrastructure or identity. Moving the same workflow on-chain can redistribute that confidence to validators, but redistribution is not verification: the acceptance rule still depends on a party being correct.

Why on-chain AI is not enough

Putting AI on-chain without verifiability only shifts the trust boundary:

Model correctness

Trust moves to operator correctness

Centralized servers

Trust moves to validators

AIMB-X rejects trust aggregation and instead enforces cryptographic correctness.

The source of an output does not determine whether the protocol accepts it. Acceptance depends on whether the required proof verifies under the current execution context. This moves the trust boundary from operator identity to evidence about the computation.

Every AI inference that influences protocol state must be accompanied by a zero-knowledge proof that:

• The model was executed faithfully.
• The inputs were bound to on-chain context.
• The output was not altered or forged.

AIMB-X places a cryptographic verification gate between AI inference and blockchain state mutation.

The execution path begins with a user or autonomous agent and ends with blockchain finality, but inference does not flow directly into shared state. The circuit establishes the computation, verification checks the evidence in context, and only then can the virtual machine apply the result.

ZK-inference circuit

The ZK-inference circuit is the evidence layer between model execution and network acceptance. It proves four related properties of an execution.

• Model weights commitmentBinds the proof to the model weights used for the inference.
• Input tensor commitmentBinds the proof to the input while private inputs remain undisclosed.
• Deterministic execution traceEstablishes faithful model execution along a deterministic trace.
• Output tensor correctnessEstablishes that the stated output follows from the proven execution.

These properties form a chain of evidence. A proof about an output is insufficient if it is not also tied to the model, input, and execution that produced it. AIMB-X treats those relationships as part of the acceptance condition.

Context binding

A mathematically valid proof is not treated as universal authorization. AIMB-X binds each inference proof to four values from its on-chain execution context.

Verification therefore asks two questions at once: is the computation valid, and is this proof valid here? A proof created for one height, chain, VM context, or caller cannot simply be substituted into another execution.

The AIMB-X virtual machine treats AI inference as provable computation rather than an oracle.

The virtual machine is where cryptographic evidence becomes protocol policy. AIMB-X treats inference as a first-class operation and applies one deterministic rule: verification must succeed before the result can mutate state.

• AI inference is treated as a first-class opcode.
• Proof verification occurs before state mutation.
• Unverifiable outputs are rejected deterministically.

The execution path has two explicit outcomes. A verified proof permits the corresponding state transition. An unverifiable output is rejected deterministically; it is not accepted because of operator identity, infrastructure reputation, or an external trust label.

AI execution is not an oracle; it is a provable computation.

Consensus inherits the same verification boundary. Block production is deterministic, execution ordering is proof-first, and AI correctness is verified statelessly.

• DeterministicBlock production
• Proof-firstExecution ordering
• StatelessVerification of AI correctness

Validators do not re-run AI models. They verify proofs only.

This separates model execution from network acceptance. The party that performs an inference does not receive discretionary authority over protocol state, and validator agreement does not substitute for evidence of correct execution.

The testnet token is operational rather than economic. It supports fee-bearing execution, basic spam resistance, and accounting while the protocol architecture is being evaluated.

A zero-balance default and explicit faucet claim require wallets and applications to handle balance discovery, token acquisition, and transaction fees instead of relying on pre-funded accounts. This gives onboarding and execution flows more realistic operating conditions during testnet evaluation.

This preserves realistic economic assumptions from day one.

The public-testnet experience connects wallet fundamentals with proof-aware interfaces. Developers can generate keys, query balances, sign offline, and inspect whether an AI-driven transition was cryptographically verified.

Developer journey

1. Create a walletGenerate keys deterministically.
2. Inspect account stateQuery the wallet balance explicitly through RPC.
3. Claim testnet tokensUse the faucet from a zero-balance starting state.
4. Prepare and signConstruct the operation and use offline signing when required.
5. Request inferenceA user or agent originates the AI inference request.
6. Verify before executionPass through the ZK circuit and proof-verification gate.
7. Observe the resultInspect proof status and the resulting state root.

Interfaces display verification status, not trust labels.

The paper names four attack classes and makes the protocol’s response explicit: verify computation and context before permitting a state change. The matrix below describes how this edition addresses each threat; it is not an audit or an exhaustive security claim.

No assumption is made about operator honesty.

The public testnet is designed to:

• Validate protocol architecture.
• Test developer onboarding.
• Stress adversarial AI scenarios.
• Collect feedback on proof latency and user experience.

Evaluation framework

The roadmap is a progression of research and testnet capabilities, not a published schedule. The paper names four stages and attaches no dates, percentages, or completion claims.

1. Stage SDeveloper Tooling & SDKs

   The developer-facing tooling stage named by the paper.

2. Stage TAdversarial Inference Campaigns

   Evaluation of inference behavior under adversarial scenarios.

3. Stage UGovernance Simulation

   Simulation of governance workflows within the protocol research program.

4. Stage VEconomic Testnet

   The roadmap’s named economic-testnet stage.

Definitions below explain how key terms are used in this public testnet paper.

AI inference

Model execution whose result may influence protocol state.

Zero-knowledge proof

Cryptographic evidence used here to verify inference correctness without revealing raw model parameters or private inputs.

Commitment

A cryptographic binding used to associate a proof with model weights or an input tensor.

ZK-inference circuit

The proof layer that establishes the model, input, execution-trace, and output properties named by the paper.

Context binding

Association of a proof with block height, chain ID, VM execution context, and caller address.

Proof-first ordering

Execution ordering in which proof verification occurs before state mutation.

State transition

A change to protocol state permitted only after successful verification.

Stateless verification

Validator verification of AI correctness without re-running the AI model.

Verification status

The proof-oriented status exposed by AIMB-X interfaces instead of a reputation-based trust label.

Testnet faucet

The explicit mechanism through which a zero-balance wallet obtains non-economic testnet tokens.