ERC-8004: a practical guide for AI-agent developers

Research checked: 4 October 2026. ERC-8004, “Trustless Agents,” is a Draft Ethereum application standard. It gives agents portable on-chain identifiers and interoperable trust signals so applications can discover and select providers across organizational boundaries. It does not certify that an agent is honest, competent, or even operational. This guide labels specification behavior, implementation choices, and application recommendations separately. Official specification; specification source snapshot.

1. What problem does it solve?

Agent communication and tool protocols such as A2A and MCP provide ways to advertise capabilities and invoke services. ERC-8004 supplies a shared blockchain layer for identifying providers and publishing evidence about their work, reducing dependence on a single platform's directory or private ratings database. Its specification defines three registries:

Registry	Defined purpose	What the application still decides
Identity	ERC-721 agent identity pointing to a registration document	Whether the advertised provider meets its requirements
Reputation	Public feedback submission and retrieval	Which reviewers, metrics, and scoring policy to trust
Validation	Requests and responses for independent checks of work	Which validator and verification method provide sufficient assurance

Payments, execution, and validation incentives/slashing are outside this standard. x402, TEE attestations, and zkML can complement it; registering an agent does not supply any of them automatically. Specification: motivation and validation.

2. Register, discover, and resolve an identity

Specification. An identity is the pair agentRegistry and agentId. The registry identifier has the form eip155:{chainId}:{identityRegistryAddress}; agentId is that registry's ERC-721 token ID. A bare token ID, name, or wallet is not globally unique. The token owner controls the agent identity, with approved operators able to manage it. Ownership is transferable. Identity specification; ERC-721 ownership and approvals.

A practical registration sequence is:

1. Select a chain and a known registry deployment. Call register() or register(string agentURI); obtain the assigned ID from the Registered transaction event.
2. Publish the registration JSON with type set to https://eips.ethereum.org/EIPS/eip-8004#registration-v1, presentation fields such as name, description, and image, a services list, and a registrations entry containing the full registry identifier and assigned ID. Include active, x402Support, and optional supportedTrust as appropriate. Advertising a trust model is a claim, not proof.
3. If necessary, call setAgentURI(agentId, uri) after publishing. HTTP(S), IPFS, and base64 JSON data URIs are supported. Starting with register() avoids guessing the ID before constructing the document.
4. Discover candidates by indexing Registered, URIUpdated, and ERC-721 Transfer events, then fetching their documents. Resolve a candidate with ownerOf(agentId) and tokenURI(agentId) on the specified chain/registry. The specification calls the latter URI agentURI; use the deployed ABI's actual function names.

The service list can point to an A2A agent card, MCP endpoint, ENS name, or other services. Rich search is an indexer feature, not a standardized registry search API. For optional HTTPS endpoint control checks, fetch https://{endpoint-domain}/.well-known/agent-registration.json and match its registration pair. The specification permits skipping this additional check when the primary registration document is served by the same domain. Registration and domain verification.

Wallet binding. getAgentWallet(agentId) returns a payment address, initially the owner's address. Changing it with setAgentWallet requires proof of control of the new wallet: EIP-712 signing for EOAs or ERC-1271 validation for contract wallets. The wallet is cleared on token transfer and must be rebound. This binds a wallet to the identity; it does not prove the provider's legal identity or authenticate every API response. Wallet rules; EIP-712; ERC-1271.

3. Reputation and feedback

Specification. Any client address can call:

function giveFeedback(
    uint256 agentId, int128 value, uint8 valueDecimals,
    string calldata tag1, string calldata tag2, string calldata endpoint,
    string calldata feedbackURI, bytes32 feedbackHash
) external;

The agent must exist; the sender cannot be its owner or approved operator. Clients need no agent registration or agent-issued feedback authorization. Here “signed value” means a numeric value that may be negative, not a separately signed review payload. Transactions identify the submitting address. Interpret the number as value / 10**valueDecimals, with decimals restricted to 0–18. For example, 9977, 2 represents 99.77. Tags define application-specific meaning: quality scores, uptime, latency, and financial returns must not be mixed into one average. Feedback specification.

Optional strings can be empty and the optional hash zero. An off-chain feedback file can carry task context and payment evidence. For a non-content-addressed file, a supplied feedbackHash commits to its exact bytes using Keccak-256, not NIST SHA3-256. The registry stores the value, decimals, tags, and revocation flag. The endpoint, file URI, and hash are in NewFeedback logs rather than contract storage, so retrieve logs to verify the full evidence. Content addressing/hashing proves integrity, not truth or availability. Feedback storage and files.

A client can revokeFeedback(agentId, feedbackIndex) for its own review; this marks revocation without erasing history. Anyone can appendResponse(...), for example to publish refund evidence or dispute a review. A response is an attributed statement, not automatic adjudication. Feedback is identified by agent ID, client address, and a per-client, per-agent 1-based index. Read with readFeedback, readAllFeedback, getClients, and getLastIndex. Reputation interface.

getSummary(agentId, clientAddresses, tag1, tag2) requires a non-empty reviewer list. Implementation-specific: the team's current Solidity implementation averages matching, non-revoked submissions after decimal normalization, returning the most frequent input decimal precision with truncation. It is not one vote per reviewer; repeated submissions contribute repeatedly. Deduplicate the supplied reviewer addresses and inspect raw feedback if frequency matters. The specification supplies the interface, not a universal reputation algorithm. Implementation of aggregation.

4. How to verify before using an agent

Recommended application policy, derived from the interfaces and threat model:

1. Use a configured registry deployment and confirm RPC chain ID, deployed code, and that reputation.getIdentityRegistry() equals the intended identity registry. Check current state at a sufficiently confirmed block; a search result is only a candidate.
2. Resolve token ownership and URI, validate the document, match its registration pair, and perform the endpoint-domain check where relevant. Inspect the current wallet before paying. Use a separate authenticated session or signed challenge if live endpoint authentication is required; ERC-8004 does not define such a challenge protocol.
3. Select trusted reviewer addresses independently. Query feedback with consistent tags and units, exclude revoked entries, and inspect count, recency, repeated submissions, and evidence. Display the policy and sample size alongside any score. No feedback is “unknown,” not evidence of safety.
4. Fetch evidence from event logs and verify hashes/CIDs. Check claimed payment transactions separately if your policy requires paid interactions. The feedback call itself does not establish that a task or payment happened.
5. For valuable tasks, require an appropriate validator or independent checks. The validation interface accepts validationRequest(...) from the owner/operator and validationResponse(...) from the requested validator, with a 0–100 result. Verify the validator and evidence rather than treating “100” as a universal guarantee.

These steps follow the specification's interfaces and security considerations. They are application policy, not an ERC-mandated trust threshold.

5. Practical example: selecting an invoice-extraction agent

Illustrative design, not an existing deployment. A provider registers an agent on Sepolia, publishes its MCP invoice-extraction endpoint, and binds its payment wallet. A purchasing application discovers candidates through an indexer, resolves each on-chain identity, and checks endpoint control.

The application evaluates feedback from its own customers or approved auditors under tag1="invoice_accuracy", tag2="schema_v1", using a documented 0–100 scale. It applies its own minimum sample and freshness rules, runs a small test job, then invokes the selected MCP tool. After checking the extracted fields, the customer's address submits:

giveFeedback(agentId, 95, 0, "invoice_accuracy", "schema_v1",
             endpoint, feedbackURI, feedbackHash)
getSummary(agentId, trustedReviewerAddresses,
           "invoice_accuracy", "schema_v1")

These are contract-call sketches, not executable SDK code. Keep customer invoices private; publish only consented, redacted evidence. Payment and any escrow remain separate application integrations. If ownership or the endpoint changes, re-evaluate the provider before sending the next job.

6. Contracts and integration tools

Team implementation, not standard-mandated addresses. The contracts README lists:

Ethereum network	Identity Registry	Reputation Registry
Mainnet, chain 1	0x8004A169FB4a3325136EB29fA0ceB6D2e539a432	0x8004BAa17C55a88189AE136b182e5fdA19dE9b63
Sepolia, chain 11155111	0x8004A818BFB912233c491871b3d84c89A494BD9e	0x8004B663056A597Dffe9eCcC1965A193B7388713

Use the repository's ABIs with an EVM library such as ethers or viem. Addresses above are repository-reported; this research did not independently inspect live bytecode or deployment governance.

Agent0 TypeScript SDK provides registration, IPFS publishing, search, and feedback helpers. Consult its quick-start and feedback example. SDK shortcuts such as chainId:agentId rely on configured registry addresses; preserve the full standard identity when exchanging data externally. Agent0's subgraph offers GraphQL discovery. SDK search, storage providers, and indexing are implementation conveniences, with their own availability and freshness assumptions.

7. Limitations, trade-offs, and open questions

• Sybil resistance remains external. Blocking owner/operator feedback does not block alternate wallets, collusion, or purchased reviews. Reviewer filtering helps only if reviewer selection is sound. No common scoring scale or universal trustworthy-reviewer list is defined. Specification security considerations.
• Ownership and behavior can change. A transferable ID can retain historical feedback while a new operator changes the model or service. Treat transfer and metadata updates as reasons to refresh confidence. Multiple chain registrations do not automatically merge reputation or prove they share an operator. These are application-level implications of the identity model. Identity and deployment rules.
• Storage has costs and failure modes. HTTPS is mutable; IPFS needs continued hosting/pinning; data URIs cost gas. Public transactions and hashes persist after revocation. Recommendation: minimize sensitive data, sandbox metadata/evidence fetching against SSRF and oversized payloads, and treat fetched content as untrusted input. Indexers may lag; large feedback histories also make unbounded reads/aggregation expensive, as the implementation loops over submissions. URI and persistence rules; read implementation.
• Upgrade governance is an additional trust assumption. The team implementation uses owner-authorized UUPS upgrades. Proxy administration is separate from ownership of an individual agent NFT. Inspect the actual deployment's implementation and administrator; a stable address need not imply stable code. Upgradeable implementation documentation.
• Validation is particularly unsettled. The specification defines validation hooks, but the team README says that section is under active revision with the TEE community; Agent0 lists validation support as forthcoming. Do not assume a usable validation deployment or SDK flow merely because the interface exists. Validator economics, meaningful task-specific correctness, reviewer weighting, and safe cross-chain reputation aggregation remain integration questions. Team implementation caveat; SDK roadmap.

Evidence and scope

Primary sources are linked beside the claims they support; repository links are pinned to the revisions retrieved during research. The official EIP page supplies current publication status, while the pinned ERC source records the technical specification used here. No agent was deployed, no transaction or SDK example was executed, and no independent contract audit or live-network verification was performed. The example and verification policy are explicitly proposed designs. Draft status and implementation roadmaps can change; recheck the specification, ABI, and deployment before integration.