Enter your search text in the box above

Select a result to preview

202603041033-eip-8004-trustless-agents

#tech #system

🎯 Core Idea

EIP-8004 (also published as ERC-8004) is a draft Ethereum standard for discovering agents and establishing trust between them (and their users) across organizational boundaries, without assuming any pre-existing relationship. The core idea is to put a minimal, portable on-chain “handle” for an agent on-chain, and then standardize how third parties can attach trust signals to that handle.

Instead of trying to define a single universal notion of “trust”, EIP-8004 defines a small set of interoperable registries and interfaces that let multiple trust models coexist. The standard frames trust as tiered and proportional to the value-at-risk: low-stakes tasks can rely on reputation signals, while higher-stakes tasks can demand stronger validation mechanisms (e.g., stake-secured re-execution, TEEs, or cryptographic proofs such as zkML). The protocol is intentionally orthogonal to payments: you can combine it with whatever payment mechanism you want, but identity + trust signals are the focus.

Concretely, EIP-8004 specifies three registries:

  1. Identity Registry: a minimal on-chain identity based on ERC-721 (agent = NFT) whose tokenURI points to an “agent registration file” describing how to reach the agent (A2A agent card, MCP endpoint, web endpoint, ENS name, email, etc.).
  2. Reputation Registry: a standard interface to publish and query feedback signals about an agent. The registry stores raw signals; scoring/aggregation can be done on-chain (for composability) and/or off-chain (for richer algorithms).
  3. Validation Registry: generic hooks to request and record independent validation checks about an agent’s work or claims, with different validator mechanisms possible.

🌲 Branching Questions

➡ What is EIP-8004 trying to solve, and what does it deliberately not solve?

EIP-8004 is trying to solve two problems that show up immediately when “agents” become a market:

First, discovery: in an open ecosystem, how do you find an agent and know you are talking to the right one, in a way that is portable across apps and organizations? EIP-8004 addresses this with an on-chain identity primitive (ERC-721) whose metadata (agentURI) resolves to a registration file.

Second, trust bootstrapping: even if you can find an agent, why should you trust it (or trust that it executed a job correctly)? EIP-8004 addresses this by standardizing where trust signals live (reputation + validation registries) so that multiple parties can produce, consume, and compose trust data.

It deliberately does not define:

The framing is: make identity and trust signals interoperable primitives; leave business logic and market structure to the ecosystem.

➡ How does the Identity Registry work (agent = ERC-721), and what is the “agent registration file”?

The Identity Registry is an ERC-721 contract (with URI storage) where each minted token represents one agent. The tokenId is called agentId, and the tokenURI is called agentURI. Ownership of the NFT corresponds to ownership/control of the agent identity; transfers and operator approvals follow normal ERC-721 semantics, so identities are portable and can integrate with existing tooling.

The agentURI must resolve to an agent registration file (JSON) which is the key off-chain document describing how to reach and understand the agent. It contains metadata such as name, description, image, and a list of services/endpoints. These endpoints are intentionally flexible: the agent can advertise an A2A agent card endpoint, an MCP endpoint, an ENS name, a DID, an email, a web endpoint, etc.

Pseudo-code for the agent registration file (simplified from the spec):

Pseudo-code: agent registration file (registration-v1)

{
  type: ".../eip-8004#registration-v1",
  name: "MyAgent",
  description: "What it does, pricing, how to interact",
  image: "https://...",

  services: [
    { name: "web", endpoint: "https://agent.example" },
    { name: "A2A", endpoint: "https://agent.example/.well-known/agent-card.json", version: "..." },
    { name: "MCP", endpoint: "https://mcp.agent.example", version: "..." },
    { name: "ENS", endpoint: "myagent.eth" },
    { name: "email", endpoint: "support@agent.example" }
  ],

  active: true,

  registrations: [
    {
      agentId: 22,
      agentRegistry: "eip155:<chainId>:<identityRegistryAddress>"
    }
  ],

  supportedTrust: ["reputation", "crypto-economic", "tee-attestation"]
}

A subtle but important point: the spec allows (optionally) “endpoint domain verification” via a well-known file on the endpoint’s domain. This is meant to reduce the risk that an agent advertises endpoints it does not actually control.

➡ How does the Reputation Registry work (what is recorded on-chain vs computed off-chain)?

The Reputation Registry standardizes the shape of raw feedback signals so multiple consumers can read them and multiple producers can emit them. The EIP emphasizes that the registry stores signals and metadata that are composable, while scoring/aggregation can be done in different ways.

From the spec, feedback is essentially a signed value plus optional metadata for filtering and richer context. Some context may be stored off-chain (e.g., detailed JSON) with a hash recorded on-chain for integrity.

A simplified mental model:

Pseudo-code of a reputation signal (simplified):

Pseudo-code: post feedback about an agent

function postFeedback(
  agentRegistry,
  agentId,
  clientAddress,
  value,          // e.g., fixed-point int
  valueDecimals,  // e.g., 0..18
  tags[],         // optional
  endpointURI,    // optional
  fileURI,        // optional pointer to JSON details
  fileHash,       // optional keccak256(file)
  signature       // binds (clientAddress, agent, value, metadata) via EIP-712
):
  verify client signature
  record feedback event / store feedback

The spec’s direction is that reputation should be a public good: if signals are public, then different “reputation services” can emerge (auditors, insurance pools, scoring providers), each weighting and filtering signals differently.

➡ How does the Validation Registry work, and when would you use it instead of reputation?

Reputation answers: “Historically, how did this agent perform according to past clients?” That is useful, but it is not a direct correctness proof for a particular task.

Validation addresses a different question: “For this particular output/claim, can an independent party check it and produce a verifiable signal?” The EIP intentionally keeps validation generic: validators can be stakers re-running a job (crypto-economic validation), TEEs attesting to execution, or cryptographic proofs (e.g., zkML).

Pseudo-code mental model:

Pseudo-code: request validation for a task result

function requestValidation(
  agentRegistry,
  agentId,
  taskRef,        // pointer to what is being validated (hash/URI)
  validationType, // e.g., "re-execution" | "tee" | "zkml" | ...
  rulesRef,       // how to judge pass/fail (hash/URI)
  deadline,
  paymentOrBond   // optional, depends on validator mechanism
):
  emit ValidationRequested(...)

function submitValidation(
  requestId,
  validator,
  score,          // e.g., 0..100
  evidenceRef,    // pointer to evidence (hash/URI)
  signature
):
  verify validator eligibility (depends on mechanism)
  record validation result

In practice, you would use validation when the value-at-risk is high, when correctness is objectively checkable, or when you want defense-in-depth beyond social reputation.

📚 References