ERC-7992 and Keryx Split Verifiable AI Into Contracts and Settlement Layers
Two emerging frameworks—ERC-7992 for Ethereum and Keryx for a dedicated L1—reveal a converging architecture for verifiable ML inference on-chain, with standardized verifier interfaces, proof-of-model mining, and optimistic challenge layers.
Verifiable ML inference on-chain is undergoing a schism, splitting into two complementary strata: standardized contract interfaces and protocol-native settlement. ERC-7992 gives Ethereum smart contracts a uniform way to accept zero-knowledge attestations of model outputs. Keryx builds a dedicated L1 that turns inference into a slashable, economically settled work unit. Together, they define the infrastructure stack for AI×crypto—a system that feels like watching the early days of TCP/IP, but with more GPU heat and less idealism.
ERC-7992 standardizes how contracts reference ML models and verify inferences[^claim_1911]. It defines a registry that binds a modelId to a ModelCommitment containing hashes of model weights/architecture, proving circuit/AIR, verifying key, and a proofSystemId. The verifyInference(modelId, inputCommitment, output, proof) interface must revert on failure and supports Groth16, Plonk, or STARK without ABI changes[^claim_1911]. That pluggability means a single contract can accept proofs from different proving systems—critical for DeFi risk engines or prediction markets that might switch proving backends like a Wall Street trader rotating sectors. The standard also adds replay protection: inputCommitment must be domain-separated and should include a nonce/salt when single-use or non-deterministic behavior is possible[^claim_1912]. An optional storage extension persists verified inference records for auditability and deterministic settlement[^claim_1912]. For protocols like Polymarket or Aave, this means inference-based oracles can be audited and settled without locking into one proving system—a kind of financial diversification for truth.
Keryx takes a different approach: it makes AI inference a first-class operation on its own L1. Its AiRequest transaction carries a 32-byte model_id, max_tokens, inference_reward, and a separate burned priority_fee, plus a token surcharge of 0.05 KRX per 64-token increment[^claim_1913]. Miners declare loaded models via coinbase extra_data using /ai:cap:<model_ids>[^claim_1913]. The AiResponse stores only a 34-byte CIDv0 on-chain while the full output lives on IPFS; the on-chain payload is fixed at 78 bytes and includes request_hash, challenge_window_end, response_ipfs_cid, and response_length[^claim_1914]. This compact on-chain footprint is designed for deterministic settlement—the full output can be fetched off-chain, but the commitment is enough for challenge logic. It’s like a hardboiled spy novel describing a dead drop: the message is tiny, but the payload is everything.
Keryx’s Optimistic Proof of Inference (OPoI) uses a 36,000-block challenge window (roughly one hour at 10 BPS) and routes 20% of the block subsidy into a CSV-locked escrow[^claim_1915]. If fraud is proven, the challenger can obtain the escrow. But on-chain slashing is temporarily disabled pending a deterministic redesign[^claim_1915]. That’s a critical caveat: the economic security of inference is not yet fully live. The protocol’s Phase 4 Proof-of-Model (PoM) hardfork replaces the matrix-multiply PoW with a data-dependent walk over resident model weights, proving possession of the full model in VRAM[^claim_1916]. PoM is byte-exact and deterministic, and maps GPU tiers to specific model sizes—a 4 GB card for Qwen3-1.7B, a 32 GB card for LLaMA-3.3-70B (Q2)[^claim_1916]. The miner implementation is Rust/CUDA-based, requires NVIDIA GPUs with SM 7.5+ and driver ≥ 535, and shares resident weights between PoM and inference to avoid a second VRAM copy[^claim_1917]. This is the kind of hardware stratification that makes you wonder if we’re building a new feudal system, where GPU lords hold the keys to the kingdom.
For blockchain developers, verifiable AI is converging on three layers: standardized verifier interfaces (ERC-7992), operator-side execution frameworks with model commitments (Keryx’s PoM), and settlement layers that turn outputs into economically accountable events (OPoI). ERC-7992 is immediately usable on Ethereum today for any contract that needs to verify an inference proof. Keryx offers a more integrated stack but comes with the caveat that its slashing mechanism is not yet active—the economic guarantees are aspirational. Watch for ERC-7992 adoption in DeFi oracle designs and for Keryx’s slashing redesign to go live, which would make it the first L1 with fully economically enforced AI inference. The yield on trust just went ex-dividend.
Provenance ledger
7 claims web-citedEvery claim below cites a source URL, and each URL was checked for validity before publish. The excerpt shown is the researcher's own summary of the page — it is not re-derived from the source, so it is not a verified verbatim quote. Follow the link to confirm any claim against the original. Citation markers in the text jump here.
[1] ERC-7992 standardizes verifiable ML inference for smart contracts by defining a registry that binds a `modelId` to a `ModelCommitment` containing hashes of the model weights/architecture, proving circuit/AIR, verifying key, and a `proofSystemId`; its `verifyInference(modelId, inputCommitment, output, proof)` interface must revert on any failure and can support Groth16, Plonk, or STARK proof systems without ABI changes. web-cited
“This ERC standardizes how smart contracts reference machine-learning (ML) models and accept zero-knowledge attestations of their inferences... It defines a registry that issues a `modelId` for a `ModelCommitment`... and exposes discoverability via ERC-165... proof systems (e.g., Groth16/Plonk/STARK) are pluggable without ABI changes.”
This excerpt was not re-derived from the source page, and may paraphrase or condense it. Check the source before relying on it.
[2] ERC-7992 explicitly adds replay protection guidance by requiring `inputCommitment` to be domain-separated and recommending a nonce/salt when single-use or non-deterministic behavior is possible; it also allows an optional storage extension that persists verified inference records for auditability and deterministic settlement. web-cited
“`inputCommitment`... Implementations MUST domain-separate and SHOULD include a nonce/salt when single-use or non-deterministic behavior is possible... An optional extension persists verified inference records to enable auditability and deterministic settlement.”
This excerpt was not re-derived from the source page, and may paraphrase or condense it. Check the source before relying on it.
[3] Keryx’s July 2026 whitepaper says its Phase 3 `AiRequest` transaction carries a 32-byte `model_id`, a `max_tokens` field, an `inference_reward`, and a separate burned `priority_fee`; it also enforces a token surcharge of `0.05 KRX per 64-token increment` and publishes model capabilities in coinbase `extra_data` using `/ai:cap:<model_ids>`. web-cited
“Binary payload layout (52 bytes minimum): [model_id: 32 bytes] ... [max_tokens: 4 bytes LE] ... [inference_reward: 8 bytes LE] ... [priority_fee: 8 bytes LE] ... The effective minimum is: `base[model] + ⌈max_tokens / 64⌉ × 0.05 KRX`... miners declare which models they have loaded by embedding ... `/ai:cap:<model_id_hex64_1>,...`”
This excerpt was not re-derived from the source page, and may paraphrase or condense it. Check the source before relying on it.
[4] Keryx claims its `AiResponse` format stores only a 34-byte CIDv0 on-chain while the full output lives on IPFS; the on-chain payload is fixed at 78 bytes and includes `request_hash`, `challenge_window_end`, `response_ipfs_cid`, and `response_length`. web-cited
“AiResponse... Binary payload layout (78 bytes, fixed): [request_hash: 32 bytes] ... [challenge_window_end: 8 bytes LE] ... [response_ipfs_cid: 34 bytes] ... [response_length: 4 bytes LE]... The full inference output is stored off-chain on IPFS — only a compact CID is committed on-chain.”
This excerpt was not re-derived from the source page, and may paraphrase or condense it. Check the source before relying on it.
[5] Keryx’s OPoI design uses a 36,000-block challenge window at 10 blocks per second, routes 20% of the block subsidy into a CSV-locked escrow, and states that the challenger can obtain the escrow if fraud is proven; the protocol also says slashing was temporarily disabled pending a deterministic redesign. web-cited
“The challenge window is tracked by the node using the blue score of the DAG... a 36,000-block window (~1 hour at 10 BPS)... route 20% of the block subsidy to a CSV-locked escrow output... Current status (June 2026): on-chain slashing is temporarily disabled while the settlement mechanism is redesigned.”
This excerpt was not re-derived from the source page, and may paraphrase or condense it. Check the source before relying on it.
[6] Keryx’s Phase 4 `Proof-of-Model (PoM)` hardfork replaces the matrix-multiply PoW with a data-dependent walk over resident model weights; the whitepaper says this proves possession of the full model in VRAM, is byte-exact and deterministic, and maps GPU tiers to specific model sizes, including a 4 GB card for Qwen3-1.7B and a 32 GB card for LLaMA-3.3-70B (Q2). web-cited
“The matrix-multiply core of KeryxHash is replaced by Proof-of-Model (PoM)... the proof-of-work itself depend[s] on the model weights... Possession of the entire tier's weights in VRAM is therefore the only competitive configuration... A 4 GB card walks Qwen3-1.7B... a 32 GB card walks LLaMA-3.3-70B (Q2)... verification is byte-exact and fully deterministic.”
This excerpt was not re-derived from the source page, and may paraphrase or condense it. Check the source before relying on it.
[7] Keryx’s miner implementation is described as Rust/CUDA-based and requires NVIDIA GPUs with SM 7.5+ and driver ≥ 535; the miner also shares resident weights between inference and PoM, avoiding a second copy in VRAM. web-cited
“The Keryx miner is a GPU-first application... via CUDA... Both PoM and inference go through the CUDA runtime... requires an NVIDIA GPU (SM 7.5+, driver ≥ 535)... the resident weights are shared between the PoM walk and inference so there is no second copy in VRAM.”
This excerpt was not re-derived from the source page, and may paraphrase or condense it. Check the source before relying on it.