Update erc-8004.md (ethereum#1470)

Author: SamWilsn

ERCS/erc-8004.md

@@ -4,31 +4,32 @@ title: Trustless Agents
 description: Discover agents and establish trust through reputation and validation
 author: Marco De Rossi (@MarcoMetaMask), Davide Crapis (@dcrapis) <davide@ethereum.org>, Jordan Ellis <jordanellis@google.com>, Erik Reppel <erik.reppel@coinbase.com>
 discussions-to: https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098
-status: Review
+status: Draft
 type: Standards Track
 category: ERC
 created: 2025-08-13
+requires: 155, 712, 721, 1271
 ---
 
 ## Abstract
 
 This protocol proposes to use blockchains to **discover, choose, and interact with agents across organizational boundaries** without pre-existing trust, thus **enabling open-ended agent economies**.
 
-Trust models are pluggable and tiered, with security proportional to value at risk, from low-stake tasks like ordering pizza to high-stake tasks like medical diagnosis. Developers can choose from different trust models: reputation systems using client feedback, validation via stake-secured re-execution, zkML proofs, or TEE oracles.
+Trust models are pluggable and tiered, with security proportional to value at risk, from low-stake tasks like ordering pizza to high-stake tasks like medical diagnosis. Developers can choose from different trust models: reputation systems using client feedback, validation via stake-secured re-execution, zero-knowledge machine learning (zkML) proofs, or trusted execution environment (TEE) oracles.
 
 ## Motivation
 
-MCP allows servers to list and offer their capabilities (prompts, resources, tools, and completions), while A2A handles agent authentication, skills advertisement via AgentCards, direct messaging, and complete task-lifecycle orchestration. However, these agent communication protocols don't inherently cover agent discovery and trust.
+Model context protocol <!-- TODO: double check that this is the correct abbreviation -->(MCP) allows servers to list and offer their capabilities (prompts, resources, tools, and completions), while Agent2Agent <!-- TODO: double check that this is the correct abbreviation -->(A2A) handles agent authentication, skills advertisement via AgentCards, direct messaging, and complete task-lifecycle orchestration. However, these agent communication protocols don't inherently cover agent discovery and trust.
 
 To foster an open, cross-organizational agent economy, we need mechanisms for discovering and trusting agents in untrusted settings. This ERC addresses this need through three lightweight registries, which can be deployed on any L2 or on Mainnet as per-chain singletons:
 
-**Identity Registry** \- A minimal on-chain handle based on [ERC-721](./eip-721) with URIStorage extension that resolves to an agent's registration file, providing every agent with a portable, censorship-resistant identifier.
+**Identity Registry** \- A minimal on-chain handle based on [ERC-721](./eip-721.md) with URIStorage extension <!-- Editor's Note: where is URIStorage defined? Is it an OZ thing? If so, you should include the interface here, or make a separate ERC standardizing it. -->that resolves to an agent's registration file, providing every agent with a portable, censorship-resistant identifier.
 
 **Reputation Registry** \- A standard interface for posting and fetching feedback signals. Scoring and aggregation occur both on-chain (for composability) and off-chain (for sophisticated algorithms), enabling an ecosystem of specialized services for agent scoring, auditor networks, and insurance pools.
 
 **Validation Registry** \- Generic hooks for requesting and recording independent validators checks (e.g. stakers re-running the job, zkML verifiers, TEE oracles, trusted judges).
 
-Payments are orthogonal to this protocol and not covered here. However, examples are provided showing how **x402 payments** can enrich feedback signals.
+Payments are orthogonal to this protocol and not covered here. However, examples are provided showing how **x402 payments** <!-- Editor's Note: This is a coinbase thing, right? If it isn't necessary to your standard, can you omit it? -->can enrich feedback signals.
 
 ## Specification
 
@@ -48,7 +49,7 @@ Throughout this document, *tokenId* in ERC-721 is referred to as *agentId* and *
 
 #### Agent URI and Agent Registration File
 
-The *agentURI* MUST resolve to the agent registration file. It MAY use any URI scheme such as `ipfs://` (e.g., `ipfs://cid`) or `https://` (e.g., `https://domain.com/agent3.json`). When the registration uri changes, it can be updated with *setAgentURI()*.
+The *agentURI* MUST resolve to the agent registration file. It MAY use any URI scheme such as `ipfs://` (e.g., `ipfs://cid`) or `https://` (e.g., `https://example.com/agent3.json`). When the registration uri changes, it can be updated with *setAgentURI()*.
 
 The registration file MUST have the following structure:
 
@@ -125,15 +126,15 @@ The *supportedTrust* field is OPTIONAL. If absent or empty, this ERC is used onl
 
 #### Onchain metadata
 
-The registry extends ERC-721 by adding *getMetadata(uint256 agentId, string metadataKey)* and *setMetadata(uint256 agentId, string metadataKey, string metadataValue)* functions for optional extra on-chain agent metadata.
+The registry extends ERC-721 by adding `getMetadata(uint256 agentId, string metadataKey)` and `setMetadata(uint256 agentId, string metadataKey, string metadataValue)` functions for optional extra on-chain agent metadata.
 
 When metadata is set, the following event is emitted:
 
 ```solidity
 event MetadataSet(uint256 indexed agentId, string indexed indexedMetadataKey, string metadataKey, bytes metadataValue)
 ```
 
-The key `agentWallet` is reserved and cannot be set via *setMetadata()* or during *register()*. It represents the address where the agent receives payments and is initially set to the owner's address. To change it, the agent owner must prove control of the new wallet by providing a valid [EIP-712](./eip-712) signature for EOAs or [ERC-1271](./eip-1271) for smart contract wallets—by calling:
+The key `agentWallet` is reserved and cannot be set via `setMetadata()` or during `register()`. It represents the address where the agent receives payments and is initially set to the owner's address. To change it, the agent owner must prove control of the new wallet by providing a valid [EIP-712](./eip-712.md) signature for EOAs or [ERC-1271](./eip-1271.md) for smart contract wallets—by calling:
 
 ```solidity
 function setAgentWallet(uint256 agentId, address newWallet, uint256 deadline, bytes calldata signature) external
@@ -305,7 +306,7 @@ The OPTIONAL file at the URI could look like:
 
 **This registry enables agents to request verification of their work and allows validator smart contracts to provide responses that can be tracked on-chain**. Validator smart contracts could use, for example, stake-secured inference re-execution, zkML verifiers or TEE oracles to validate or reject requests.
 
-When the Validation Registry is deployed, the *identityRegistry* address is passed to the constructor and is visible by calling getIdentityRegistry(), as described above.
+When the Validation Registry is deployed, the *identityRegistry* address is passed to the constructor and is visible by calling `getIdentityRegistry()`, as described above.
 
 #### Validation Request
 
@@ -366,6 +367,10 @@ Incentives and slashing related to validation are managed by the specific valida
 * **Indexing**: Since feedback data is saved on-chain and we suggest using IPFS for full data, it's easy to leverage subgraphs to create indexers and improve UX.
 * **Deployment**: We expect the registries to be deployed with singletons per chain. Note that an agent registered and receiving feedback on chain A can still operate and transact on other chains. Agents can also be registered on multiple chains if desired.
 
+<!-- Editor's Note: The test cases section should be a list of input/output/state changes or automated test functions. Simply listing "what to test" is insufficient. -->
+
+<!--
+
 ## Test Cases
 
 This protocol enables:
@@ -375,6 +380,8 @@ This protocol enables:
 * Building reputation systems with on-chain aggregation (average scores for smart contract composability) or sophisticated off-chain analysis. All reputation signals are public good.
 * Discovering which agents support stake-secured or zkML validation and how to request it through a standardized interface
 
+-->
+
 ## Security Considerations
 
 * Sybil attacks are possible, inflating the reputation of fake agents. The protocol's contribution is to make signals public and use the same schema. We expect many players to build reputation systems, for example, trusting or giving reputation to reviewers (and therefore filtering by reviewer, as the protocol already enables).