Verified Cryptography

Zero-Knowledge Proofs

Aethelred treats zkML verification as a first-class protocol surface in the March 2026 whitepaper. Validators can attach proofs to Proof-of-Useful-Work execution, the x/verify module enforces deterministic checks, and smart contracts can verify proof envelopes through the zkML precompile at 0x0300. Use this page alongside TEE attestation, Infinite Sandbox, and the toolchain stack when choosing how a workload should be verified.

5 Proof Systems EVM 0x0300 Hybrid Verification Digital Seals

Review Proof Systems Open TEE Surface

WHITEPAPER V1.1 / MARCH 2026

Protocol-native verification path

Proofs are part of the current consensus and verification architecture, not an off-chain afterthought or a generic research note.

Deterministic, gas-metered checks

The verifier enforces proof size limits, verifying key matches, domain binding, and fail-closed behavior before a result is accepted.

Designed for hybrid assurance

Jobs can combine zkML proofs with TEE attestation so the same output hash is cross-validated before seal minting.

5 Systems Current proof-system matrix

1 MB Max Global proof-size ceiling

18s EZKL Achieved on small models

Overview

What zkML means on Aethelred right now

This page reflects the current protocol model, not the older standalone marketing copy. On Aethelred, a zkML proof is one of the documented verification modalities available per job, alongside TEE attestation and the hybrid mode that cross-checks both.

ZKML

Current Role

Proof-backed model execution without disclosing private inputs or weights

The current whitepaper defines zkML proofs as mathematical evidence that a specific model was applied to a specific input to produce a specific output, without revealing the model weights or raw input data. This makes zkML useful when verifiability matters but confidential application logic still needs to stay private.

Protocol Placement

Validators may generate proofs during vote extension execution, while x/verify and the 0x0300 precompile enforce deterministic verification.

Operational Outcome

Accepted proofs contribute to a workload result that can later be minted as a Digital Seal when supermajority agreement is reached.

Evidence Package Proof bytes, proof-system identifier, verifying key hash, job identity, and output commitment validation.

Contract Surface Smart contracts consume proof verification through the zkML precompile and sealed result flows.

Build Surface Use the developer docs, Infinite Sandbox, and testnet path to move from local proof generation into public rehearsal.

SEAL

Network Effect

Proofs are useful because they flow into consensus evidence

Aethelred does not stop at proof generation. When validators converge on the same output hash and the network reaches >= 2/3 + 1 agreement power, that result can be promoted into a Digital Seal with provenance, consensus evidence, and relayable verification data.

Seal Binding

Each seal records model hash, input hash, output hash, block height, timestamp, chain ID, and the validator evidence that supported the result.

Cross-Chain Path

Proof-backed seals can be consumed on-chain via 0x0500 or relayed across IBC on port aethelred.seal.

Model Registry Current documentation stores model hashes, circuit hashes, verifying keys, TEE measurements, and per-circuit gas multipliers.

Auto-Compilation ONNX models auto-compile to EZKL circuits when that mode is enabled in the registry workflow.

Dev Surface The documented local environment includes a zkML prover with GPU passthrough inside the 10-service devnet.

Supported Systems

Precompile

0x0300

Seal Threshold

2/3 + 1

Max Proof Size

1 MB

Achieved EZKL

18s

Proof Systems

The current proof-system matrix in the whitepaper

The protocol currently documents five supported proof systems. These values are taken from the March 2026 verification framework table and should be treated as the current reference surface for proof selection.

System	Min Proof Size	Gas Multiplier	Primary Use Case
EZKL	256 bytes	2x	ML model inference
RISC Zero	512 bytes	4x	General zkVM computation
Plonky2	256 bytes	3x	FRI-based, fast proving
Halo2	384 bytes	2x	IPA commitment, no trusted setup
Groth16	192 bytes	1x	Most compact proofs

Proof selection should follow workload shape, not aesthetics

Compact proofs, fast proving, and general zkVM flexibility are different tradeoffs. Use the precompile and SDK surface in Developer Documentation to match the proof system to the application path you are actually shipping.

Open Precompiles

On-Chain Verification

Deterministic checks in x/verify

The verifier is strict by design. Proof handling is gas-metered, registry-aware, domain-bound, and fail-closed when a production requirement is missing.

x/verify

gas = base_gas + (proof_size * gas_per_byte) * system_multiplier * circuit_multiplier

domain_binding = SHA-256(job_id || chain_id || block_height)

RULES

Security Invariants

What the verifier checks before a proof is accepted

Proof size is gated against the global maximum and any circuit-specific ceiling.
Gas is calculated deterministically from proof size, proof system, and circuit multiplier.
Unregistered circuits are rejected in production mode.
Verifying key hashes must match the circuit registry entry.
The in-memory circuit cache is rebuilt atomically from on-chain state at each BeginBlock.

FAIL

Fail-Closed Model

How the current verifier blocks bad or replayed proof data

Anti-replay is embedded through SHA-256(job_id || chain_id || block_height) in the public inputs.
Groth16 proofs receive subgroup and field checks before acceptance.
If a registered verifier is missing and simulated mode is disabled, verification fails immediately.
Proof envelopes without the right shape, domain binding, or registry context do not degrade gracefully into acceptance.

Hybrid Verification

The high-assurance path cross-checks TEE output and zkML output

Hybrid verification is the current highest-assurance mode documented by Aethelred. TEE attestation and zkML verification run in parallel, then the protocol checks that both sides agree on the same output commitment.

STEP 01

Execute the workload

The validator runs the job inside a TEE and/or generates a zkML proof during the vote-extension window.

STEP 02

Cross-validate commitments

The TEE output hash must match the output commitment published through the zkML public inputs. A mismatch fails both results.

STEP 03

Promote into seal evidence

When the network reaches supermajority agreement, the result can be minted as a Digital Seal with proof and attestation evidence attached.

Verification Mode	Evidence	Security Level	Best Fit
TEE	Attestation quote bound to workload and chain	High	Confidential execution and regulated inference
ZKML	Proof bytes plus verifying-key and domain checks	High	Privacy-preserving proof of model execution
Hybrid	TEE + ZKML cross-validation	Highest	High-value or adversarial workloads that need defense in depth

Build Path

How teams move from proof design into network rehearsal

The current zk surface already connects the model registry, the local devnet, the SDKs, and public network rehearsal. There is no separate research-only stack required to start using it.

MODEL

Registry

Model registration and proof compilation are part of the same control plane

When ONNX auto-compilation is enabled, models are compiled into EZKL circuits and registered with the hashes and keys needed for deterministic verification. That means the proof surface is tied to the same operational registry that defines deployable model state.

Stored Data Model hashes, circuit hashes, verifying keys, TEE measurements, and per-circuit gas multipliers.

Developer Surface The SDK docs and tooling page already expose the surrounding workflow.

Contract Surface Use EVM precompiles when proof verification needs to be consumed directly in smart contracts.

DEVNET

Rehearsal

The documented local environment already contains the prover path

The current development environment includes a 10-service Docker Compose devnet with three validators on heterogeneous TEE platforms, a zkML prover with GPU passthrough, API and explorer surfaces, and monitoring. That is the shortest path from experimentation to testnet readiness.

Local Control Infinite Sandbox gives teams a place to inspect proof-backed execution before exposing workloads to public infrastructure.

Public Rehearsal Testnet moves the same operational model into a public validation environment.

Assurance Pairing Use TEE attestation when the workload also needs hardware-backed confidential execution.

Choose the verifier to match the risk model

Use pure zkML when mathematical proof is the center of trust, TEE attestation when blind compute is the center of trust, and hybrid mode when both need to agree before a result is promotable.

Open Infinite Sandbox

Implementation References

Where zk verification meets the contract surface

Teams that get through proof-system selection usually need the next layer immediately: how those proofs are consumed in Solidity, precompiles, and application policy.

SOL

Contract Reference

Smart Contracts

The Smart Contracts page documents the current contract-facing path for zk-aware integrations: precompile lanes, oracle reads, callback patterns, seal gating, and the supporting token, bridge, and governance contracts in the live repository.

Best For Application teams that need to consume proof-backed outcomes in Solidity instead of only at the SDK or module layer.

Current Surfaces 0x0300, 0x0500, IAethelredOracle, and conservative copyable contract patterns.

Open Smart Contracts →

RUN

Rehearsal Path

Sandbox and precompile workflow

If the contract path is still too early, the better next stop is the rehearsal surface. The sandbox and developer docs let teams compile, test, and verify proof-backed execution before they wire contract policy around it.

Best For Teams moving from circuit experimentation into devnet testing, SDK integration, and staged contract rollout.

Next Pages Infinite Sandbox, Developer Precompiles, and Developer Tools.

Open Infinite Sandbox →