ERC-8126 primary sources — 2026-05-07

Project status in this pass

• No standalone ERC-8126 whitepaper or litepaper surfaced.
• The clearest source of truth was the draft ERC itself, backed by the raw ERC markdown.
• The sources consistently frame ERC-8126 as a verification-provider standard layered on top of ERC-8004 agent identity.

Primary-source snapshots

1) Canonical ERC page

• URL: https://eips.ethereum.org/EIPS/eip-8126
• Key excerpt/signals:
  • The abstract says the ERC defines a standard interface for verifying AI agents that have been registered via ERC-8004.
  • It names five verification processes: Ethereum Token Verification, Media Content Verification, Solidity Code Verification, Web Application Verification, and Wallet Verification.
  • It says verification providers use Private Data Verification to generate ZKPs and produce a unified 0-100 risk score.
• Why it mattered:
  • This is the clearest evidence that ERC-8126 belongs in the corpus as agent-verification and trust-attestation infrastructure rather than as identity or wallet execution logic.

2) Raw ERC markdown / metadata resolution and mandatory verification types

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-8126.md
• Key excerpt/signals:
  • Providers MUST begin from an ERC-8004 agentId and resolve metadata through the Identity Registry’s tokenURI.
  • Direct submission of individual parameters without an agentId is explicitly forbidden.
  • Compliant providers MUST implement all five verification types and apply them using the resolved metadata.
• Why it mattered:
  • These details show that ERC-8126 is not just a generic attestation schema; it is a tightly scoped verification layer anchored to portable agent identity.

3) Raw ERC markdown / off-chain architecture and optional on-chain surface

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-8126.md
• Key excerpt/signals:
  • The Interface section says ERC-8126 is primarily an off-chain standard and does not require an on-chain contract interface to submit verification requests or run verification types.
  • Optional on-chain components may emit events, expose recent results, or record final scores.
  • Providers MAY post final scores and proof IDs into ERC-8004’s Validation Registry.
• Why it mattered:
  • This is the strongest evidence that the real trust surface is the verifier marketplace and its attestations, not a single canonical settlement contract.

4) Raw ERC markdown / risk scoring and provider model

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-8126.md
• Key excerpt/signals:
  • The overall risk score MUST be calculated as the mean of all applicable verification scores.
  • The rationale explicitly says the design is provider agnostic and intended to enable competition, specialization, and price competition.
  • The same rationale says PDV-generated proofs and optional QCV are meant to preserve privacy while keeping verification results portable.
• Why it mattered:
  • This highlights the main analytic tension in ERC-8126: it invites a market of verifiers while also standardizing the headline score that downstream systems may treat as authoritative.

5) Discussion thread

• URL: https://ethereum-magicians.org/t/erc-8126-ai-agent-verification/27445
• Key excerpt/signals:
  • Only the thread title surfaced cleanly in this pass, but it confirms the active discussion venue for the draft.
• Why it mattered:
  • Even without useful body extraction, the thread anchors ERC-8126 in the live standards discussion process and links it to the broader agent-standards cluster.

Working conclusion

ERC-8126 is best cataloged as a provider-facing verification and attestation layer for ERC-8004 agents. The decisive evidence in this pass was the mandatory five-check design, the requirement to derive inputs from ERC-8004 identity metadata, the off-chain-first architecture, and the normalized 0-100 risk score that can later feed into portable validation records.