ERC-8126 AI agent verification
Final · Signatures & auth · created 2026-01-15
A standard that checks AI agents registered under ERC-8004 through five specialized verifications covering token, media, code, web and wallet, and provides the results as a 0 to 100 risk score and a zero-knowledge proof.
Why it is needed
As AI agents operating on blockchains increase, a way is needed to confirm whether an agent is genuine and can be trusted. Until now, however, verification methods varied, and there was no unified standard for agent registration or verification. For some agents it was not even confirmed whether a smart contract was actually deployed, and there was no way to know whether a profile image had been manipulated, whether a website was safe, or whether a wallet appeared in a threat database. Moreover, if sensitive data is exposed or stored during verification, that itself becomes a leak risk. This standard bundles the five verifications into one procedure, unifies the results into a 0 to 100 risk score that anyone can compare, and uses a zero-knowledge proof (Zero-Knowledge Proof) so that verification can be shown to have taken place without revealing the original data.
What to implement
function getLatestRiskScore(uint256 agentId) external view returns (uint8);: Looks up the latest risk score for the agent. It may revert if there is no verification record.
In depth
Verification requests must use agentId
A verification request must reference the agentId, which is the uint256 token ID in the ERC-8004 identity registry (MUST). The verification provider must call tokenURI(agentId) on the canonical identity registry contract, fetch the agent registration JSON from the returned URI, and extract all metadata fields, including agentWallet/walletAddress, chain_id, contractAddress, endpoints/url, image/imageUrl, platform_id and solidityCode, according to the ERC-8004 registration schema. Submitting individual parameters directly without an agentId is not allowed. This ensures that the verification target is always linked to an onchain identity.
The five verification types
Compliant providers must implement all five types. ETV (Ethereum Token Verification) checks with eth_getCode, when contractAddress is present, whether a contract is deployed on the given chain_id (that the bytecode is not 0x) and checks for known vulnerability patterns. MCV (Media Content Verification), when imageUrl is present, checks the source and embedded metadata, inspects for signs of manipulation or tampering, and examines watermarks, steganography and signatures. It recommends using frameworks such as C2PA. SCV (Solidity Code Verification), when solidityCode is present, checks for vulnerabilities such as reentrancy and flash loan attacks. WAV (Web App Verification) checks HTTPS responses and SSL certificate validity and recommends following the OWASP WSTG. WV (Wallet Verification) checks the wallet's transaction history and compares it against threat intelligence databases. Each verification must produce a risk score from 0 to 100.
Risk score and rating
The overall risk score MUST be calculated as the mean of all applied verification scores. There are five rating levels. 0 to 20 is Low Risk (minimal concern), 21 to 40 is Moderate (some concern, review recommended), 41 to 60 is Elevated (notable concern, caution needed), 61 to 80 is High Risk (significant concern found), and 81 to 100 is Critical (severe concern, avoid interaction). The 0 to 100 range was chosen because it balances granularity and ease of interpretation better than 0 to 10 or 0 to 255. A score outside the range is an InvalidScore (0x08) error.
Off-chain standard and optional on-chain components
By default, this ERC is an off-chain standard for verification providers. No on-chain contract interface is required to submit or perform verification requests. Off-chain execution removes gas costs, enables complex verification logic that would be too expensive on-chain, lets verification criteria evolve without contract upgrades, and allows multiple providers to compete. However, on-chain components MAY be deployed optionally for recording final scores or attestations, emitting events, and querying results. If deployed, they SHOULD include at least the AgentVerified and AttestationPosted events and the getLatestRiskScore function. Providers may also publish the score and proof ID to the ERC-8004 validation registry.
PDV, zero-knowledge proofs, and QCV
Verification results are produced as zero-knowledge proofs (ZKP) through PDV (Private Data Verification). Because no data is stored, there is nothing to leak, and a third party can cryptographically confirm that verification was completed. Detailed verification results are accessible only to the agent's wallet holder. PDV implementations are recommended to use verified circuits (for example, Groth16) and a trusted setup based on a multi-party computation ceremony. The optional QCV (Quantum Cryptography Verification) encrypts sensitive verification data in a quantum-resistant way with AES-256-GCM or an equivalent algorithm, then provides the record_id and decryption_url of the encrypted data. Elliptic-curve-based ZKPs may be vulnerable to quantum attacks, so QCV is recommended as an additional layer for long-term stored data.
Fees and payment
Verification providers MAY charge fees. If they do, they MUST disclose the fee structure clearly before verification. Support for stablecoin settlement such as USDC is recommended, and supporting gasless payment using EIP-3009 TransferWithAuthorization is recommended (SHOULD). In this approach the provider bears the gas cost, so users can get verified without holding ETH.
Standard error codes
Implementations MUST use the 13 standard error codes from 0x01 to 0x0D. They are InvalidAddress(0x01), InvalidURL(0x02), AgentNotFound(0x03), VerificationFailed(0x04), InsufficientCredits(0x05), InvalidProof(0x06), ProviderUnavailable(0x07), InvalidScore(0x08), ContractNotFound(0x09), SolidityCodeNotFound(0x0A), ImageNotFound(0x0B), SteganographyFailed(0x0C), and MediaVerificationFailed(0x0D). On-chain implementations SHOULD revert with a custom error of the same name.
Things to watch out for
- Verification is only a point-in-time assurance: Passing verification means the agent passed technical checks at a specific point in time. It does not guarantee the agent's future behavior or intent. The risk score is for reference only, so users must use their own judgment.
- Wallet takeover risk: If a registered agent's wallet is taken over, an attacker can impersonate the legitimate agent. Re-verification can update the risk score.
- URL hijacking: If an agent's URL is taken over after registration, an attacker can serve malicious content. It is advisable to check the current state before interacting, and WAV re-verification can detect a hijacked endpoint.
- Provider trust and collusion: Providers may differ in thoroughness, independence, and reliability, and a provider may collude with a malicious agent. For important interactions, using several independent providers is recommended.
- ERC-8004 dependency: Because this standard depends on the ERC-8004 registry, implementations must use the official deployment address and verify the integrity of the tokenURI.