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, zero-knowledge machine learning (zkML) proofs, or trusted execution environment (TEE) oracles.
Model context protocol (MCP) allows servers to list and offer their capabilities (prompts, resources, tools, and completions), while Agent2Agent (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 with URIStorage extension 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
The Identity Registry uses ERC-721 with the URIStorage extension for agent registration, making all agents immediately browsable and transferable with NFTs-compliant apps. Each agent is uniquely identified globally by:
{namespace}:{chainId}:{identityRegistry} (e.g., eip155:1:0x742...) where:
eip155 for EVM chains)Throughout this document, tokenId in ERC-721 is referred to as agentId and tokenURI in ERC-721 is referred to as agentURI. The owner of the ERC-721 token is the owner of the agent and can transfer ownership or delegate management (e.g., updating the registration file) to operators, as supported by ERC721URIStorage.
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:
The type, name, description, and image fields at the top SHOULD ensure compatibility with ERC-721 apps. The number and type of endpoints are fully customizable, allowing developers to add as many as they wish. The version field in endpoints is a SHOULD, not a MUST.
Agents MAY advertise their endpoints, which point to an A2A agent card, an MCP endpoint, an ENS agent name, DIDs, or the agent's wallets on any chain (even chains where the agent is not registered).
Since endpoints can point to domains not controlled by the agent owner, an agent MAY optionally prove control of an HTTPS endpoint-domain by publishing https://{endpoint-domain}/.well-known/agent-registration.json containing at least a registrations list (or the full agent registration file). Verifiers MAY treat the endpoint-domain as verified if the file is reachable over HTTPS and includes a registrations entry whose agentRegistry and agentId match the on-chain agent; if the endpoint-domain is the same domain that serves the agent’s primary registration file referenced by agentURI, this additional check is not needed because domain control is already demonstrated there.
Agents SHOULD have at least one registration (multiple are possible), and all fields in the registration are mandatory. The supportedTrust field is OPTIONAL. If absent or empty, this ERC is used only for discovery, not for trust.
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:
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 signature for EOAs or ERC-1271 for smart contract wallets—by calling:
When the agent is transferred, agentWallet is automatically reset to the zero address and must be re-verified by the new owner.
New agents can be minted by calling one of these functions:
This emits one Transfer event, one MetadataSet event for each metadata entry, if any, and
The agentURI can be updated by calling the following function, which emits a URIUpdated event:
If the owner wants to store the entire registration file on-chain, the agentURI SHOULD use a base64-encoded data URI rather than a serialized JSON string:
When the Reputation Registry is deployed, the identityRegistry address is passed to the constructor and publicly visible by calling:
The feedback given by a clientAddress to an agent consists of a score (0-100), tag1 and tag2 (left to developers' discretion to provide maximum on-chain composability and filtering), a endpoint uri, a file uri pointing to an off-chain JSON containing additional information, and its KECCAK-256 file hash to guarantee integrity. We suggest using IPFS or equivalent services to make feedback easily indexed by subgraphs or similar technologies. For IPFS uris, the hash is not required. All fields except the score are OPTIONAL, so the off-chain file is not required and can be omitted.
New feedback can be added by any clientAddress calling:
The agentId must be a validly registered agent. The score MUST be between 0 and 100. tag1, tag2, endpoint, feedbackURI, and feedbackHash are OPTIONAL.
If the procedure succeeds, an event is emitted:
The feedback fields, except feedbackURI and feedbackHash, are stored in the contract storage along with the feedbackIndex (the number of feedback submissions that clientAddress has given to agentId). This exposes reputation signals to any smart contract, enabling on-chain composability.
When the feedback is given by an agent (i.e., the client is an agent), the agent SHOULD use the address set in the on-chain optional walletAddress metadata as the clientAddress, to facilitate reputation aggregation.
clientAddress can revoke feedback by calling:
This emits:
Anyone (e.g., the agentId showing a refund, any off-chain data intelligence aggregator tagging feedback as spam) can call:
Where responseHash is the KECCAK-256 file hash of the responseURI file content to guarantee integrity. This field is not required for IPFS URIs.
This emits:
We expect reputation systems around reviewers/clientAddresses to emerge. While simple filtering by reviewer (useful to mitigate spam) and by tag are enabled on-chain, more complex reputation aggregation will happen off-chain.
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.
Agents request validation by calling:
This function MUST be called by the owner or operator of agentId. The requestURI points to off-chain data containing all information needed for the validator to validate, including inputs and outputs needed for the verification. The requestHash is a commitment to this data (keccak256 of the request payload) and identifies the request. All other fields are mandatory.
A ValidationRequest event is emitted:
Validators respond by calling:
Only requestHash and response are mandatory; responseURI, responseHash and tag are optional. This function MUST be called by the validatorAddress specified in the original request. The response is a value between 0 and 100, which can be used as binary (0 for failed, 100 for passed) or with intermediate values for validations with a spectrum of outcomes. The optional responseURI points to off-chain evidence or audit of the validation, responseHash is its commitment (in case the resource is not on IPFS), while tag allows for custom categorization or additional data.
validationResponse() can be called multiple times for the same requestHash, enabling use cases like progressive validation states (e.g., “soft finality” and “hard finality” using tag) or updates to validation status.
Upon successful execution, a ValidationResponse event is emitted with all function parameters:
The contract stores requestHash, validatorAddress, agentId, response, lastUpdate, and tag for on-chain querying and composability.
Incentives and slashing related to validation are managed by the specific validation protocol and are outside the scope of this registry.
Copyright and related rights waived via CC0.