Category: agent verification standard / privacy-preserving attestation infrastructure / off-chain trust-scoring control plane
Summary: ERC-8126 is best cataloged as verification-provider infrastructure for AI agents rather than as an agent registry, wallet, or payment rail. Its core move is to require standardized multi-layer verification against an ERC-8004 agent identity, then compress the result into portable proof IDs and a unified risk score that can optionally be posted back into ERC-8004’s validation layer. The important categorization clue is that ERC-8126 is mostly an off-chain standard for competing verification providers, so the real control surface sits in who performs verification, how they score risk, and whether downstream wallets or marketplaces treat those attestations as mandatory trust gates.
What it does:
Requires verification requests to start from an ERC-8004 agentId, resolve the agent’s registration metadata through tokenURI, and derive verification inputs from that canonical registration data rather than ad hoc user-supplied fields
Defines five mandatory verification tracks for compliant providers: Ethereum Token Verification (ETV), Media Content Verification (MCV), Solidity Code Verification (SCV), Web Application Verification (WAV), and Wallet Verification (WV)
Standardizes a 0-100 risk-scoring model with named tiers so agent verifications can be compared across providers and surfaced as a single headline signal
Uses Private Data Verification (PDV) to generate proof IDs and frames Zero-Knowledge Proofs as the privacy layer that lets providers attest to checks without exposing underlying sensitive data
Lets providers optionally post final scores and proof IDs into ERC-8004’s Validation Registry, linking private verification work to a portable on-chain trust surface
Treats payments as optional and off-chain, but recommends gasless settlement via EIP-3009 when providers charge for verification services
Key claims:
The abstract says ERC-8126 defines a standard interface for verifying AI agents registered via ERC-8004, which is the clearest signal that it belongs in the corpus as a verification layer sitting above agent identity rather than as identity itself
The specification says compliant providers MUST implement all five verification types, which makes ERC-8126 unusually prescriptive compared with looser attestation or reputation standards
The ERC requires providers to resolve metadata from ERC-8004 tokenURI and forbids direct submission of individual parameters without an agentId, showing that verification is intentionally anchored to portable registry identity instead of to provider-specific intake forms
The Interface section explicitly says no on-chain smart-contract interface is required because this is primarily an off-chain standard for verification providers, which matters because trust concentration will likely sit with verifier brands, scoring models, and accepted proof formats rather than with one canonical contract
The Integration with ERC-8004 section says providers MAY post final risk scores and proof IDs to the ERC-8004 Validation Registry, making ERC-8126 best understood as an attestation-producing trust layer that feeds a broader agent discovery stack
The rationale frames the design as provider-agnostic and competitive, but the standard still pushes convergence around one normalized 0-100 score, implying a likely future control point where wallets or marketplaces inherit third-party verifier judgment as default policy
The Payment Protocol section recommends EIP-3009 gasless settlement, reinforcing that ERC-8126 is trying to make verification a service marketplace rather than an on-chain proof system with mandatory protocol fees
The discussion thread title and draft text consistently position ERC-8126 alongside ERC-8004 and ERC-8196 as part of a larger agent trust stack: discover, verify, then authorize execution
Whitepaper: No standalone ERC-8126 whitepaper or litepaper surfaced in this pass. The clearest current sources were the canonical ERC page and raw ERC markdown; see ../../whitepapers/erc-8126-primary-sources-2026-05-07.md.