ERC-8126: AI Agent Verification

ERCs
, ,
13

Update: Refining ERC-8126 as a Pure Verification Standard – Deep Integration with ERC-8004

Hi everyone,

It’s been a couple of months since the initial ERC-8126 draft (“AI Agent Registration and Verification”) was published on January 15, 2025. The thread has stayed relatively quiet (a few early comments on trust primitives, off-chain/on-chain balance, and risk scoring — thanks for those!), but the AI agent space has moved quickly since then.

Most notably, ERC-8004: Trustless Agents (created August 2025, core registries deployed to mainnet January 29, 2026) has gained real traction. It delivers a canonical ERC-721-based Identity Registry for portable agent identities (agentId + tokenURI-resolved JSON metadata with walletAddress, endpoints, contractAddress, stakingContractAddress, chainId, etc.), plus pluggable Reputation and Validation Registries for composable trust signals. Reference implementations and early integrations are emerging, and it’s now referenced in Ethereum Foundation materials.

This creates a clear opportunity to streamline ERC-8126 and align it more tightly with the ecosystem’s direction — especially the EF’s push (articulated by the dAI team in early 2026) to position Ethereum as the public, governance-less verification and coordination layer for AI agents, with standards like ERC-8004 as foundational building blocks.

Proposed Architectural Shift

The current ERC-8126 draft combines on-chain agent self-registration (via its own Agent Registry + EIP-712) with verification in one standard. With ERC-8004 now live and maturing, I believe separating these concerns is the stronger path:

  • Registration & portable identity → handled by the general-purpose ERC-8004 standard (ERC-721 NFT identity, cross-chain CAIP compatibility, metadata resolution, pluggable reputation/validation).
  • Verification → a lightweight, provider-agnostic, off-chain-focused complement that builds directly on ERC-8004 identities.

This avoids duplicating registries, reduces fragmentation, and makes verification results naturally composable with other trust signals.

Key Changes in the Updated Draft

  • Removes the on-chain Agent Registry entirely — no duplicated registration logic.
  • Requires pre-registration via ERC-8004:
    • Verification requests MUST supply an agentId (uint256 token ID from the canonical ERC-8004 Identity Registry).
    • Providers MUST call tokenURI(agentId) → resolve to standardized JSON → extract walletAddress, url/endpoints, contractAddress, stakingContractAddress, chainId, etc.
    • Direct submission of raw parameters (without agentId) is explicitly forbidden to enforce canonical identity and prevent fragmentation.
  • Retains the core verification stack:
    • Mandatory (where applicable): ETV, SCV, WAV, WV.
    • PDV → ZKPs for privacy-first architecture.
    • Optional QCV for quantum-resistant encryption.
    • Unified 0–100 risk score (simple average of applicable checks, with five clear risk tiers).
    • x402 micropayments via ERC-3009 (gasless USDC support).
  • Adds optional posting to ERC-8004’s Validation Registry:
    • Providers MAY submit final risk scores + Proof IDs as attestations → verification becomes discoverable and portable alongside reputation entries and other validations.
  • Off-chain-first interface:
    • No required on-chain submission/verification component.
    • Optional IERC8126 interface for providers/integrators who want to emit AgentVerified events or expose getLatestRiskScore(agentId).
  • Other refinements: Expanded error codes (as custom Solidity errors), access control (detailed proofs visible only to wallet holder), stronger OWASP alignment, and explicit test cases.

It remains fully provider-agnostic, privacy-focused, and future-proof.

Rationale & Ecosystem Alignment

  • Eliminates competing registries → lowers gas/deployment costs and maintenance burden.
  • Leverages ERC-8004’s momentum (mainnet live, EF dAI roadmap integration, growing builder interest).
  • Enables portable verification: any ERC-8004-registered agent (AI or human-controlled) can seek checks without redundant registration.
  • Directly supports the Ethereum Foundation’s 2026 vision (and related RFPs in the Ecosystem Support Program) of Ethereum as the trust/verification layer for AI agents — providing coordination, identity, cryptographic proofs, and composable trust without centralised choke points.
  • Preserves competition among verification providers (on depth, speed, cost) while standardising metadata and output formats.

Feedback Requested & Next Steps

  • Does decoupling registration (ERC-8004) from verification (8126) still make sense given ERC-8004’s progress?
  • Concerns about the hard dependency on ERC-8004? (It’s Draft but mainnet-deployed with growing adoption.)
  • Validation Registry posting: RECOMMENDED (for discoverability) or keep fully OPTIONAL?
  • Risk scoring: stick with simple average, or add configurable weights per type (e.g., higher weight on WV/ETV)?
  • QCV: still valuable as optional/future-proofing, or premature given quantum timelines?

I will open a PR to the ethereum/ERCs repo to move this refined version toward Review status — potentially with input from the EF dAI team or ERC-8004 maintainers. I’m open to all feedback and happy to iterate.

Looking forward to your thoughts!

Thanks,
Leigh
@cybercentry
cybercentry.base.eth

2 Likes