With the official deployment of the ERC-8004 (Trustless Agents) standard to the Ethereum mainnet, the identity and reputation management of AI agents has entered a new, verifiable, and trustless phase. This standard provides agents with an on-chain verifiable "identity system" through three core registries: an identity registry, a reputation registry, and a verification registry. This article will analyze the key risks of each registry from a security audit perspective, combining the technical details of ERC-8004, and provide developers and auditors with a practical auditing guide.
Technical details and audit points
The key to ERC-8004 lies in its three registry entries:
1. Identity Registry
A minimal on-chain handle based on ERC-721, with URIStorage extensions, resolves to the agent's registration file, providing a portable, censorship-resistant identifier for each agent.
In the ERC-8004 architecture, the identity registry is built on top of ERC-721 and extends the URIStorage functionality. In other words, each agent corresponds to a unique NFT on the chain, and this NFT is called AgentID.
When a developer creates an agent, they call the `register` function of the registry contract to mint a new AgentID. This token is bound to a `tokenURI` that points to a JSON file stored off-chain—the so-called "agent registration file." The registration file must adhere to strict specifications and typically includes three core elements:
- Basic information, such as name, description, and avatar URL;
- The server endpoint, which is the network address that the proxy can access, supports multiple protocols such as HTTP, WebSocket, Libp2p, A2A, and MCP;
- Capability declaration, which is a list of tasks that the agent can perform, such as image generation, arbitrage trading, or code auditing.
Self-declaration alone is clearly insufficient to establish trust, therefore ERC-8004 introduces a domain verification mechanism. Agents must host a signature file under their declared domain, at the path /.well-known/agent-card.json. The on-chain registry verifies this link, thus binding the on-chain AgentID to the corresponding DNS domain. This step is crucial for preventing phishing and impersonation attacks; agents cannot arbitrarily claim ownership of a domain and must use cryptographic signatures to prove control.
Audit Focus:
● Check the access control of the setTokenURI function to ensure that only the proxy owner or authorized roles (such as onlyOwnerAfterMint) are allowed to update the URI.
● Verify that the URI supports immutable storage solutions (such as IPFS or Arweave). If a centralized HTTP connection is used, assess the security of domain control to prevent DNS hijacking.
● Verify the validity of the URI format to avoid contract exceptions caused by null pointers or invalid URIs.
● Verify whether the contract strictly performs cryptographic signature verification (such as EIP-712) when verifying the domain name signature to prevent signature forgery or replay attacks.
● Check the expiration mechanism of domain ownership certificates to prevent long-term valid signatures from being reused.
● Ensure that the domain name resolution process does not rely on a centralized oracle to avoid single points of failure or manipulation.
2. Reputation Registry
A standard interface for publishing and receiving feedback signals. Scoring and aggregation occur both on-chain (composability) and off-chain (complex algorithms), enabling a professional service ecosystem of proxy scoring, audit networks, and insurance pools.
This is used to evaluate and provide feedback on registered AI Agents. Simple feedback submissions are made on-chain, while more complex submissions can be made off-chain, and the aggregated feedback is then uploaded to the on-chain database.
ERC-8004 can also prevent malicious rating manipulation through a "Payment-Proof Linking" mechanism. When agent A completes a review of agent B, the `giveFeedback` function is called. This function not only accepts the rating (0-100) and the review hash, but also allows a `paymentProof` field, typically the hash of an x402 transaction. This makes the cost of manipulating reviews extremely high, significantly reducing the possibility of Sybil attacks. Ultimately, the entire system will naturally reward agents with stable and high-quality performance.
Audit Focus:
● Verify that the `giveFeedback` function mandates the `paymentProof` parameter and check that it is a valid x402 transaction hash (or conforms to other payment standards). Ensure that payment proofs are not reused (e.g., record used hashes) to prevent multiple evaluations of a single payment.
● Check whether the scoring range (0-100) is enforced at the contract level to prevent scores that exceed the boundary from breaking the aggregation logic.
● Evaluate the resistance to manipulation of off-chain aggregation algorithms: for example, whether to use median, prune extreme values or weighted average, and whether to penalize anomalous behavior (such as a large number of evaluations in a short period of time).
● Review whether the conditions for forfeiture are clear and verifiable, such as whether they rely on on-chain evidence or third-party oracles to submit proof of fraud.
● Ensure that the penalty logic does not contain centralized privileges (such as administrators being able to arbitrarily confiscate pledged funds), and that the penalty triggering conditions are executed automatically by the smart contract.
● Test the lock-up period and conditions for deposit withdrawal to prevent agents from urgently withdrawing funds before facing penalties or forfeiture.
3. Validate the registry.
Common hooks for requesting and logging independent verifier checks (e.g., zkML verifier, TEE oracle, trust assessment).
Reputation reflects the past, but in high-risk scenarios (such as large fund transfers), history alone is insufficient. Verification registries allow agents to submit results for verification by third parties or automated systems, which can use mechanisms such as staking-secure inference re-execution, zkML validators, or TEE oracles to verify or reject requests.
The first model is cryptoeconomic verification, based on a game theory-based security design. Agents must stake a certain amount of native tokens or stablecoins in a registry. If an agent fails to fulfill its obligations or provides incorrect results, the validator network can submit proof of fraud, triggering a smart contract to automatically forfeit its staked funds. This model is suitable for tasks where the results are easily verifiable but the computational process is opaque, such as data scraping or simple API services.
The second model is cryptographic verification, a security design based on mathematical principles. TEE (Trusted Execution Environment) authentication allows the agent to run in a secure, hardened hardware environment, such as Intel SGX or AWS Nitro. The verification registry can store and verify remote authentication reports from the hardware, proving that the code the agent is running is indeed an authentic, unaltered version of the specific code.
zkML (Zero-Knowledge Machine Learning) is another cryptographic verification method. The agent submits a zero-knowledge proof along with the inference result. This proof can be verified by an on-chain verification contract at extremely low cost, mathematically guaranteeing that the output was indeed generated by a specific model (such as Llama-3-70B) under specific inputs. This prevents "model substitution" attacks, where service providers claim to use high-end models but actually use low-order models to save costs.
Audit Points
If it is cryptoeconomic verification, the following needs to be checked:
● Check the submission window for fraud proof: Does the verifier have enough time to detect and submit proof? A window that is too short may miss malicious behavior, while a window that is too long will result in funds being locked for an extended period.
● The adjudication logic for verifying fraud proofs: Does it rely on a multi-signature validator set? If so, the degree of decentralization and threshold settings of the selected validators need to be examined; if the adjudication is entirely on-chain, it needs to be ensured that the basis for the adjudication (such as verifiable results on-chain) exists and is unambiguous.
● Ensure that the amount of collateral matches the risk to prevent low-cost malicious behavior (such as insufficient collateral, where the gains from wrongdoing far outweigh the losses).
If it is TEE certification, the following needs to be checked:
● Check whether the contract verifies the validity of the TEE proof (e.g., includes a timestamp or block height) to prevent expired proofs from being accepted.
● Verify whether the proof content includes the proxy's code hash and input/output digest to ensure that the proof is bound to a specific task and avoids cross-task reuse.
● Evaluate whether the verification logic of the TEE proof relies on an external oracle (such as Intel IAS). If so, audit the security and decentralization of the oracle.
If it is zkML validation, the following needs to be checked:
● Verify that the contract integrates an audited zk verification library (such as SnarkVerifier) and correctly configures the verification key for the specific proof system (such as Groth16, PLONK).
● Check whether the verification contract restricts the applicable model and input range of the proof to prevent model substitution attacks (e.g., the proof is generated for a small model, but claims to be the output of a large model).
● Assess the degree of decentralization in proof generation: Does it rely on a single prover? If multiple provers exist, a consensus mechanism needs to be designed to prevent malicious provers.
Conclusion
ERC-8004 provides a standard for establishing trust in AI agents, and its security is crucial to the entire on-chain agent ecosystem. Security audits require a deep understanding of the design intent and potential risks of the three registries. Furthermore, the complexity of cross-contract interactions and common vulnerabilities cannot be ignored. A comprehensive and rigorous audit is necessary to ensure that ERC-8004 truly delivers on its promise of "trustlessness," laying a secure foundation for the future of autonomous agents.
