AI Agents also need to check "credit reports": ERC-8126 is filling the gap of on-chain trust.

Author: Xiao Bai
This article is an original submission by the author, and the views only represent the author's personal understanding. ETHPanda has edited and organized the content.

After the AI Agent is on-chain, the question is no longer just "Can it chat?".

It may sign, receive payments, initiate transactions, deploy contracts, manage wallets, call APIs, and even collaborate with other agents to complete tasks. At this point, what users really care about is not whether it has a nice name, but rather:

Is this agent reliable?

Is its wallet clean? Do the contracts it is associated with really exist? Does its website and API pose risks? Is the media content it releases forged? Does its Solidity code have obvious vulnerabilities? Has it already been attacked?

ERC-8126 targets this type of verification issue.

In simple terms, ERC-8126 is the verification layer for AI Agents. It is built on top of the ERC-8004 agent registration, allowing independent verification providers to perform multi-layer verification around the same agent identity and turn the results into risk signals consumable by wallets, markets, applications, and other agents.

It does not aim to prove that a certain agent is always trustworthy, but rather to standardize "how to verify an agent, how to express verification results, and how other systems can read these results".

Having an identity does not equal trustworthiness

ERC-8004 addresses the identity issue of agents.

You can understand it as: first, let AI Agents have a registrable, discoverable, indexable identity on the chain. This identity corresponds to an agentId and describes the agent's name, wallet, endpoint, website, contract address, and other information through metadata.

But identity itself does not equal trust.

A malicious agent can also register an identity. A phishing agent can also write a beautiful metadata. An agent that is normal today does not guarantee that its endpoint will not be hijacked tomorrow. An agent with an avatar, an official website, and a wallet address also does not guarantee that its contract is secure, wallet is clean, or content is genuine.

Therefore, ERC-8004 is more like answering:

Who is this agent?

ERC-8126 further asks:

Is this agent worth interacting with?

How does ERC-8126 perform verification?

First, the verification request will reference the agentId in the ERC-8004 Identity Registry. The verification provider will then read the corresponding metadata through this agentId and parse information such as wallet, contract, website, endpoint, media content, etc., ultimately generating risk ratings and verification proofs.

This process can be broken down into four steps:

The AI Agent first registers an identity through ERC-8004.
The ERC-8126 provider reads this agent's agentId and metadata.
The provider conducts multi-layer verification on the agent.
The verification results are consumed by wallets, markets, dApps, or other agents in the form of risk scores, proofs, attestations, etc.

The key point here is: ERC-8126 does not introduce a unique "official certifying authority".

It is more like an open market for verification providers. Different providers can perform security checks using their own methods, but the output results must be expressed in a standardized format. This way, wallets, agent marketplaces, task markets, and other applications can read these signals across platforms.

This goes further than "the project party claims its own security": it splits the trust judgment into signals that can be checked, recorded, and read by third parties.

Five layers of verification: breaking down the agent

ERC-8126 primarily defines five types of verification, covering several aspects that are most prone to issues after the agent is on-chain: contracts, media, code, websites, and wallets. It standardizes the types of verification, result expression, and consumable interfaces, rather than turning every type of security check into a unique official auditing method. Different verification providers can still use their own detection processes and risk models.

ETV: Token / Contract Verification

ETV checks the tokens or contracts associated with the agent.

If the agent metadata lists a contractAddress, the provider will check whether there really is contract code at that address on the corresponding chain, whether there are obvious risks, and whether it is just a random fake address.

For users, ETV answers:

Is the on-chain asset or contract that this agent claims to be associated with really legitimate?

Once an agent starts receiving payments, issuing tokens, staking, or executing strategies, the underlying contracts are no longer decoration but the actual place where user funds will be encountered.

MCV: Media Content Verification

MCV checks the media content used by the agent, such as avatars, images, brand materials, proof images, etc.

This may not sound like a core issue, but it is very important in the AI Agent scenario. A fake agent can impersonate project logos, forge official screenshots, or even use AI-generated images to create an endorsement feeling.

MCV needs to check content sources, integrity, signs of tampering, watermarks, signatures, and other information.

It answers:

Is the content that this agent displays to users forged or tampered with?

SCV: Solidity Code Verification

SCV checks the Solidity code or contract security associated with the agent.

If the metadata includes relevant code or contract information, the provider can check for common risks such as re-entrancy, permission issues, dangerous calls, and flash loan attack surfaces.

SCV can reduce some common contract risks, but it does not equal a complete manual audit.

It is more like a standardized entry for contract security checks. Passing SCV does not mean that the contract is absolutely secure; it indicates that the code or contract of this agent 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, although they have on-chain identities, still have actual interaction entry points off-chain, such as official websites, APIs, MCP servers, A2A endpoints, or dashboards.

If these places encounter problems, the risks may be no less than those of contracts. An invalid website certificate may expose users to man-in-the-middle attacks; an API being hijacked may cause the agent to execute incorrect commands; if the front end is injected with malicious scripts, users may sign dangerous transactions.

WAV answers:

Are the web entry and server endpoints of this agent secure?

WV: Wallet Verification

WV checks the risks of the agent's wallet.

It will look at whether this wallet has a transaction history, whether it is a newly created shell, whether it is associated with high-risk addresses, phishing addresses, attackers' addresses, or other objects in threat intelligence databases.

WV answers:

Is the on-chain behavior record of this agent clean?

Unified risk scores: making wallets and applications truly usable

ERC-8126 will convert the verification results into a risk score ranging from 0 to 100.

The lower the score, the lower the risk; the higher the score, the higher the risk.

0-20: Low risk
21-40: Moderate risk
41-60: Rising risk
61-80: High risk
81-100: Severe risk

This design has very direct product significance.

Wallets cannot require ordinary users to read a complete security report every time. Marketplaces also cannot rely solely on project parties' self-reports for ranking. A unified risk score can serve as an input for product strategy.

For example:

If the risk score is too high, the wallet can alert or prevent interaction.
If there are no verification results, the marketplace can lower display weight.
If the wallet has abnormal risk, the task market can limit order-taking.
If the web endpoint has high risk, the front end can prompt users to tread carefully.

However, a total score cannot represent all situations.

Contract risks, wallet risks, website risks, media risks are all different types of risks. Better product design is to display both the total score and itemized scores, letting users know exactly where the problems lie.

PDV and ZKP: Proving through verification does not equal publicizing all details

Verifying an agent will involve many sensitive information.

Such as source code, infrastructure configurations, security reports, private logs, wallet profiles, etc. If all details are made public, it may actually expand the attack surface.

Thus ERC-8126 introduces PDV and ZKP.

PDV is Private Data Verification, and ZKP is Zero-Knowledge Proof. Their function is to allow the agent to prove that it has passed a certain verification without having to disclose all underlying details.

It can be understood as:

The external world sees "the verification has passed, the risk score is how much, where the proof is," rather than the complete internal security materials.

This makes ERC-8126 resemble a verifiable due diligence summary, rather than directly laying all data bare for the whole network to see.

ERC-8004 / ERC-8126 / ERC-8183: Identity, Verification, Transactions

If we decompose the AI Agent economy into three layers, it can be understood in this way. Here it is necessary to clarify the status: ERC-8126 has entered the Final state, while ERC-8004 and ERC-8183 are still in the Draft stage, so the three are better understood as a direction for infrastructure that is being formed, rather than a fully shaped protocol stack.

ERC-8004: Identity allows agents to have identity, be registrable and discoverable.
ERC-8126: Verification allows the security and risk signals of agents to be verifiable and consumable.
ERC-8183: Commerce allows agents to receive tasks, submit results, and enter custody and settlement processes.

To put it more straightforwardly:

ERC-8004 answers: Who are you?
ERC-8126 answers: Are you reliable?
ERC-8183 answers: Can you work, get paid, and settle?

When these three are put together, they present a relatively clear narrative of the agent economy:

First there is identity, then verification, and finally it becomes easier to enter transactions and settlements.

This relationship can also be refined. ERC-8126 is indeed built upon ERC-8004; ERC-8183 and ERC-8126 are more naturally complementary rather than having a strong binding relationship.

In other words, commerce protocols like ERC-8183 can naturally consume the verification signals of ERC-8126, such as checking its risk score before the agent takes on a task, or verifying proofs before an evaluator disburses funds. But this is more like an engineering combination direction, rather than a stringent dependency of ERC-8183 on ERC-8126.

What does it mean for developers?

If we only look at AI Agents from a market narrative, discussions can easily stop at tokens, launches, marketplaces, and trading heat. But for those who genuinely want to develop agent products, wallet integrations, task networks, or protocol infrastructure, the more critical question is: when an agent begins to manage assets, call services, submit results, and collaborate with other agents, who bears the cost of trust?

In the past, this cost largely fell on the users. Users had to assess whether the project was reliable, check if contracts had been audited, verify if the wallet was clean, identify if the official website was fake, and ultimately bear the consequences of being scammed or failing interactions.

The value of ERC-8126 lies in its attempt to break these judgments into standardized, composable, and product-readable verification signals.

It will not eliminate risk, nor can it guarantee that a certain agent is always trustworthy. But if such verification signals are adopted by more wallets, marketplaces, dApps, and agent networks, many product decisions could no longer rely solely on the project parties' self-reports.

Specifically:

For wallets, risk scores can become an input for pre-transaction risk control and alerts.

For agent marketplaces, verification results can affect ranking, filtering, display weight, and risk labels.

For AI x ETH applications, it can serve as a security check before integrating agents.

For agent-to-agent collaboration, it can help agents filter out obviously high-risk objects before cooperation.

This is also why ERC-8126 is worth paying attention to: it is not just another AI conceptual ERC, but an attempt to advance on-chain agents from "registrable" to "verifiable and manageable for risk control".

It is still a standard, not a fully operational network

This part can be viewed from another perspective.

ERC-8126 defines standard interfaces and verification frameworks. It specifies how verification can be conducted, how results can be expressed, but does not imply that there is now a mature public verification network operating across wallets, marketplaces, and chains.

From the current specifications, it has clearly established a few things:

ERC-8126 defines the standard process for agent verification.
It requires verification to anchor to the ERC-8004 agentId.
It covers five types of risks: token / contract, media, Solidity, web, and wallets.
It supports risk scores, proofs, and attestations.
It provides a foundation for wallets, marketplaces, and dApps to consume verification signals.

These capabilities will truly take effect only if many providers, wallets, marketplaces, and applications are willing to adopt them. In other words, it is not currently in the following state:

All wallets have been integrated.
All agent marketplaces have adopted it.
All providers are using completely consistent scoring standards.
The entire industry has formed a mature verification network.
ZKPs and risk scores have been fully unified in production environments.

In other words:

ERC-8126 has standardized the verification language for AI Agents. For it to become a public trust layer, providers, wallets, markets, and applications still need to continue integrating.

Conclusion

After AI Agents enter the on-chain economy, identity is just the starting point, and a more practical question will arise: Can it be verified?

ERC-8004 gives agents an identity. ERC-8126 enables the risks behind that identity to be verified. ERC-8183 allows agents the opportunity to use these verification signals in task, custody, and settlement scenarios.

Thus, the significance of ERC-8126 is not to grant agents a "permanently trustworthy" badge, but rather to standardize a more realistic question:

When an AI Agent is about to enter wallets, markets, task networks, and on-chain transactions, how should we check it? How should the inspection results be expressed? How should other systems consume these results?

This may be the trust layer that the AI Agent economy needs to complement next.

References

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。