[Draft ERC] Universal AI Inference Verification Registry

ERCs
, ,
1

Hi everyone :waving_hand:,

As on-chain AI and verifiable compute continue to gain traction, we are hitting a massive interoperability wall. We have an incredible Cambrian explosion of verification networks on one side (zkML, opML, TEEs, etc.), and a growing list of agentic/AI-focused ERCs on the other.

However, right now, these two sides speak completely different languages.

TL;DR: We are facing an N × M integration nightmare for on-chain AI. Every dApp or protocol that wants to consume verified AI inference currently has to write custom, vendor-specific adapters for each proof system. This draft ERC proposes a unified, standard verifier registry and interface that sits exactly in the middle—allowing verification projects to plug in once, and consumer ERCs to query a single standard interface.

Would love to get the community’s feedback on this architecture, especially from authors of the related ERCs and teams building inference networks.

Here is the breakdown of the problem and the proposed standard:

Motivation

Verification infrastructure already exists, but it is highly fragmented.

Verification Projects: On-chain AI verification is already live across five paradigms:

Paradigm Representative Projects
zkML RISC Zero, SP1, EZKL
opML ORA Protocol
TEE Automata DCAP, Marlin Oyster
Oracle Chainlink Functions, Band Protocol
Multisig / AVS EigenLayer AVS, Lit Protocol

ERCs: A growing set of ERCs explicitly need on-chain inference verification, but none define a common interface for it:

  • ERC-8183 (Agentic Commerce) — evaluator “may verify a ZK proof” before releasing payment, but no verifier interface is defined
  • ERC-8004 (Trustless Agents) — Validation Registry lists zkML/TEE verifiers as examples, but specifies no contract interface
  • ERC-7992 (Verifiable ML) — defines a registry for ZK proofs only, leaving opML, TEE, Oracle, and Multisig uncovered
  • ERC-7007 (Verifiable AIGC Token) — accepts opaque bytes proof with no model identifier or proof-system identifier
  • ERC-8001 (Agent Coordination, Final) — routes multi-agent task results through opaque executionData bytes with no inference verification module

The problem: these two sides cannot talk to each other. Every protocol that needs verified AI inference today must write a separate adapter per proof system — resulting in vendor lock-in and N×M integration complexity. What’s missing is a standard verifier registry that sits in the middle. This ERC provides exactly that:

   Verification Projects           This ERC                ERCs

   zkML (RISC Zero, SP1…) ─┐  ╔══════════════════╗  ┌─ ERC-8183 (Agentic Commerce)
   opML (ORA Protocol)    ─┤  ║  AI Inference    ║  ├─ ERC-8004 (Trustless Agents)
   TEE  (Automata, Marlin)─┼─►║  Verifier        ║◄─┼─ ERC-7992 (Verifiable ML)
   Oracle (Chainlink…)    ─┤  ║  Registry        ║  ├─ ERC-7007 (AIGC Token)
   Multisig (EigenLayer…) ─┘  ╚══════════════════╝  └─ ERC-8001 (Agent Coordination)

Proposal

This ERC defines two interfaces — one for each side of the registry:

For Verification Projects (left side) — implement IProofVerifier:

Wrap your existing verifier logic behind this single method. The registry dispatches to it when a consumer requests your methodId.

interface IProofVerifier {
    function verify(
        bytes32 modelHash,
        bytes32 inputHash,
        bytes32 outputHash,
        bytes calldata proof  // your existing proof format, unchanged
    ) external view returns (bool valid);
}
  • zkML: wrap your existing verify / verifyProof call
  • opML: adapter handles the async request/callback pattern
  • TEE: wrap the attestation verification call
  • Oracle & Multisig: wrap threshold signature or BLS aggregate check

For ERCs (right side) — call IVerificationMethod:

Call one function. The registry routes to the registered verifier automatically.

interface IVerificationMethod is IERC165 {
    function verifyInference(
        bytes32 methodId,   // e.g. keccak256("zkml.ezkl.halo2")
        bytes32 modelHash,
        bytes32 inputHash,
        bytes32 outputHash,
        bytes calldata proof
    ) external returns (bool valid);

    function registerVerifier(bytes32 methodId, address verifier) external;
    function getVerifier(bytes32 methodId) external view returns (address);

    event InferenceVerified(bytes32 indexed methodId, bytes32 indexed modelHash,
                            bytes32 outputHash, bool valid);
}
  • ERC-8183: call verifyInference() before complete()
  • ERC-8004: deploy as a validation method; InferenceVerified events feed the Reputation Registry
  • ERC-7992: existing verifiers register as IProofVerifier adapters under "zkml"
  • ERC-7007: replace opaque bytes proof with IProofVerifier

Open Questions

  1. Compatibility — Should this ERC extend ERC-7992’s proofSystemId dispatch model, or treat zkML as a peer category alongside opML/TEE/Oracle/Multisig?

  2. Challenge Period Handling — During an opML challenge window, should verifyInference return false, or expose a distinct pending state so callers can differentiate “invalid” from “not yet finalized”?

  3. Model Versioning — modelHash changes after every fine-tune. Should this ERC define a versioning convention, delegate to a companion model registry, or treat version management as out of scope?

  4. Naming Governance — Is self-assigned <category>.<implementer> sufficient to prevent method ID collisions in practice, or does the ecosystem need a lightweight off-chain name registry?

1 Like