Author: Xiaobai
This article is an original contribution by the author. The views expressed are solely those of the author. ETHPanda has edited and organized the content.
Once AI Agents are on-chain, the issue is no longer just 'can they chat'.
They might sign messages, receive payments, initiate transactions, deploy contracts, manage wallets, call APIs, and even collaborate with other agents to complete tasks. At this point, what users truly care about is not whether it has a nice name, but:
Is this agent actually reliable?
Is its wallet clean? Are the contracts it associates with real? Are its website and APIs risky? Is the media content it publishes forged? Does its Solidity code have obvious vulnerabilities? Has it already been attacked?
ERC-8126 targets precisely these types of verification problems.
Simply put, ERC-8126 is the verification layer for AI Agents. It builds upon the agent registration of ERC-8004, allowing independent verification providers to perform multi-layered verification around the same agent identity and transform the results into risk signals that wallets, marketplaces, applications, and other agents can consume.
It does not aim to prove an agent is forever trustworthy, but rather standardizes 'how to verify an agent, how verification results should be expressed, and how other systems can read these results'.
Having an Identity Does Not Equal Being Trusted
ERC-8004 solves the identity problem for agents.
You can think of it like this: first, give an AI Agent a registerable, discoverable, and indexable identity on-chain. This identity corresponds to an agentId and describes the agent's name, wallet, endpoint, website, contract address, etc., through metadata.
But identity itself does not equal trust.
A malicious agent can also register an identity. A phishing agent can also write beautiful metadata. An agent that is normal today doesn't mean its endpoint won't be hijacked tomorrow. An agent having an avatar, an official website, and a wallet address does not mean its contracts are secure, its wallet is clean, or its content is authentic.
Therefore, ERC-8004 is more about answering:
Who is this agent?
ERC-8126 further asks:
Is this agent worth interacting with?
How Does ERC-8126 Do Verification?
First, a verification request references the agentId from the ERC-8004 Identity Registry. The verification provider then reads the corresponding metadata via this agentId, parses information such as wallet, contract, website, endpoint, media content, etc., from it, and finally generates a risk score and verification proof.
This process can be broken down into four steps:
- The AI Agent first registers its identity via ERC-8004.
- The ERC-8126 provider reads this agent's agentId and metadata.
- The provider performs multi-layered verification on the agent.
- The verification results, in forms like risk score, proof, attestation, are consumed by wallets, marketplaces, dApps, or other agents.
The key point here is: ERC-8126 does not introduce a single 'official certification authority'.
It is more like an open market for verification providers. Different providers can use their own methods for security checks, but the output results must be expressed in a standardized format. This allows wallets, agent marketplaces, task markets, and other applications to read these signals across platforms.
This goes a step further than 'a project claiming itself is safe': it breaks trust judgment into signals that can be checked, recorded, and read by third parties.
Five Layers of Verification: Deconstructing an Agent
ERC-8126 primarily defines five categories of verification, covering the most problematic aspects after an agent is on-chain: contracts, media, code, web, and wallet. It standardizes the verification types, result expression, and consumable interfaces, rather than turning every security check into a unique official audit method. Different verification providers can still use their own detection processes and risk models.
ETV: Token / Contract Verification
ETV checks the token or contract associated with an agent.
If the agent metadata includes a contractAddress, the provider will check whether this address actually has contract code on the corresponding chain, if there are obvious risks, or if it's just a fake address filled in arbitrarily.
For users, ETV answers:
Is the on-chain asset or contract this agent claims to be associated with actually real?
Because once an agent starts receiving payments, issuing tokens, staking, executing strategies, the contracts behind it are no longer decorations, but places where user funds will actually interact.
MCV: Media Content Verification
MCV checks the media content used by an agent, such as avatars, images, brand materials, proof images, etc.
This might not sound like a core issue, but it's important in the AI Agent scenario. A fake agent can impersonate a project logo, forge official screenshots, or even use AI-generated images to create a sense of endorsement.
MCV checks for information like content source, integrity, tampering traces, watermarks, signatures, etc.
It answers:
Has the content this agent shows to users been forged or tampered with?
SCV: Solidity Code Verification
SCV checks the Solidity code or contract security associated with an agent.
If the metadata includes relevant code or contract information, the provider can check for common risks, such as reentrancy, permission issues, dangerous calls, flash loan attack surfaces, etc.
SCV can reduce some common contract risks, but it is not equivalent to a full manual audit.
It's more like a standardized entry point for contract security checks. Passing SCV does not mean a contract is absolutely secure; it indicates that this agent's code or contract has been checked by a provider and generated consumable risk signals.
WAV: Web Application Verification
WAV checks the agent's website, APIs, and endpoints.
Many agents, despite having an on-chain identity, still have their actual interaction points off-chain, such as official websites, APIs, MCP servers, A2A endpoints, or dashboards.
Problems in these areas can be as risky as contract issues. An expired website certificate could lead to man-in-the-middle attacks; a hijacked API could cause the agent to execute wrong commands; a front-end injected with malicious scripts could lead users to sign dangerous transactions.
WAV answers:
Are this agent's web entry points and service endpoints secure?
WV: Wallet Verification
WV checks the wallet risk of an agent.
It examines whether the wallet has transaction history, if it's a newly created empty shell, if it's associated with high-risk addresses, phishing addresses, attacker addresses, or other objects in threat intelligence databases.
WV answers:
Is this agent's on-chain behavior record clean?
Unified Risk Score: Making it Actually Usable for Wallets and Apps
ERC-8126 transforms verification results into a risk score from 0 to 100.
A lower score indicates lower risk; a higher score indicates higher risk.
- 0-20: Low Risk
- 21-40: Medium Risk
- 41-60: Elevated Risk
- 61-80: High Risk
- 81-100: Severe Risk
The product rationale for this design is straightforward.
Wallets cannot expect ordinary users to read a full security report every time. Marketplaces aren't suited to rely solely on project self-descriptions for ranking. A unified risk score can become input for product strategies.
For example:
- If the risk score is too high, a wallet can warn or block interaction.
- Without verification results, a marketplace can lower display weight.
- If wallet risk is abnormal, a task market can restrict order acceptance.
- If web endpoint risk is high, a front-end can warn users to visit cautiously.
However, a single total score cannot represent the full picture.
Contract risk, wallet risk, website risk, and media risk are inherently different types of risks. Better product design would be to display both the total score and sub-scores, letting users know exactly where the problems lie.
PDV and ZKP: Proving Verification Without Revealing All Details
Verifying agents involves a lot of sensitive information.
Such as source code, infrastructure configuration, security reports, private logs, wallet profiles, etc. Revealing everything could actually expand the attack surface.
Therefore, ERC-8126 introduces PDV and ZKP.
PDV is Private Data Verification, and ZKP is Zero-Knowledge Proof. Their role is: to allow an agent to prove it has passed a verification without publicly revealing all the underlying details.
Think of it as:
The external world sees 'verification passed, risk score is X, proof is here', rather than the complete internal security materials.
This makes ERC-8126 more like a verifiable due diligence summary, rather than laying all data open for the entire network to see.
ERC-8004 / ERC-8126 / ERC-8183: Identity, Verification, Commerce
Deconstructing the AI Agent economy into three layers, it can be understood like this. It's important to note the status first: ERC-8126 has entered Final status, while ERC-8004 and ERC-8183 are still in Draft stage. Therefore, the three are better understood as an emerging infrastructure direction rather than a fully formed protocol stack.
- ERC-8004: Identity gives agents identity, registration, and discoverability.
- ERC-8126: Verification makes agent security and risk signals verifiable and consumable.
- ERC-8183: Commerce enables agents to accept tasks, submit results, and enter escrow and settlement processes.
More plainly:
- ERC-8004 answers: Who are you?
- ERC-8126 answers: Are you reliable?
- ERC-8183 answers: Can you work, get paid, settle?
Put together, these three present a relatively clear agent economy narrative:
First identity, then verification, and finally, easier entry into transactions and settlements.
This relationship can be elaborated further. ERC-8126 indeed builds upon ERC-8004; ERC-8183 and ERC-8126 are more like natural complements rather than a hard-bound relationship.
In other words, agent commerce protocols like ERC-8183 can naturally consume ERC-8126 verification signals, such as checking an agent's risk score before accepting a task, or verifying proofs before an evaluator releases payment. But this is more of an engineering combination direction, not a hard dependency of ERC-8183 on ERC-8126.
What Does This Mean for Developers?
If looking at AI Agents only from a market narrative, discussions can easily stay at tokens, launches, marketplaces, and trading hype. But for those actually building agent products, wallet integrations, task networks, or protocol infrastructure, the more critical question is: when an agent starts managing assets, calling services, submitting results, and collaborating with other agents, who bears the trust cost?
In the past, this cost was mostly dumped on users. Users judged project reliability themselves, checked if contracts were audited themselves, investigated wallet cleanliness themselves, identified fake websites themselves, and ultimately bore the consequences of scams or failed interactions.
The value of ERC-8126 lies in its attempt to break these judgments into standardized, composable verification signals that can be read by products.
It won't eliminate risk, nor can it guarantee an agent is forever trustworthy. But if such verification signals are adopted by more wallets, marketplaces, dApps, and agent networks, many product decisions no longer need to rely solely on project self-descriptions.
Specifically:
For wallets, the risk score can become input for pre-transaction risk control and warnings.
For agent marketplaces, verification results can influence ranking, filtering, display weight, and risk labels.
For AI x ETH applications, it can serve as a security check before agent integration.
For agent-to-agent collaboration, it can help agents screen out obviously high-risk counterparts before cooperation.
This is also where ERC-8126 deserves attention: it's not just another AI concept ERC, but an attempt to push on-chain agents from 'registerable' to 'verifiable, risk-controllable'.
It's Still a Standard, Not a Currently Operating Network
This part can be viewed from another angle.
ERC-8126 defines standard interfaces and a verification framework. It specifies how verification can be done, how results can be expressed, but it does not mean there is currently a mature public verification network running uniformly across wallets, marketplaces, and chains.
From the current specification, it has clarified several things:
- ERC-8126 defines the standard process for agent verification.
- It requires verification to be anchored to the ERC-8004 agentId.
- It covers five categories of risk: token/contract, media, Solidity, Web, wallet.
- It supports risk scoring, proof, and attestation.
- It provides a foundation for wallets, marketplaces, and dApps to consume verification signals.
For these capabilities to truly work, it depends on how many providers, wallets, marketplaces, and applications adopt it subsequently. In other words, it is not yet in a state like:
- All wallets are already integrated.
- All agent marketplaces have adopted it.
- All providers use completely consistent scoring standards.
- The entire industry has formed a mature verification network.
- ZKP and risk scoring are fully unified in production environments.
In other words:
ERC-8126 first standardizes the verification language for AI Agents. To become a public trust layer, it still needs providers, wallets, markets, and applications to continue integrating.
Conclusion
After AI Agents enter the on-chain economy, identity is just the starting point. A more practical problem will follow: can they be verified?
ERC-8004 gives agents identity. ERC-8126 makes the risks behind that identity verifiable. ERC-8183 then enables agents to use these verification signals in task, escrow, and settlement scenarios.
Therefore, the significance of ERC-8126 is not to give an agent a 'permanently trustworthy' badge, but to standardize a more realistic question:
When an AI Agent is about to enter wallets, markets, task networks, and on-chain transaction processes, how should we check it? How should the check results be expressed? And how should other systems consume these results?
This might be the trust layer the AI Agent economy needs to fill next.
References
- ERC-8126: AI Agent Verification
- ERC-8126 Raw Markdown
- ERC-8004: Trustless Agents
- ERC-8183: Agentic Commerce
- Ethereum Magicians: ERC-8126 Discussion
- DonJohnson X Thread: Introducing ERC-8126
- Cybercentry Web3 Security & Verification Services
- ERC-8126 Scan
