ERC-8004 (AI Agent Identity, Discovery, and Reputation)

ERC-8004 is a new standard that gives an onchain AI agent a portable identity (an NFT in an Identity Registry) plus an agent card describing what the agent does and how to reach it. On the ENS side, ENSIP-25 and ENSIP-26 are ENS standards that let an ENS name publish agent discovery records and attest which ERC-8004 agent(s) it controls.

The ENS Omnigraph API makes it easy to bring both sides together: start from an ENS name or from an ERC-8004 agent, and get the agent card, reputation, and the attested name-to-agent relationship in one query, with no need for RPC calls to contracts or IPFS fetching on your side.

A complementary protocol for ENS

AI agent discovery is a new area where ENS names can act as the human-readable, portable identity layer for autonomous agents. ERC-8004 is one possible complementary standard for this — it is still early and conceptual.

ENS is already exploring this space: ENSIP-25 and ENSIP-26 define how ENS names relate to onchain agent identities and discovery records.

The ENS Omnigraph enables the convenient harmonization of ENS with protocols that are complementary to ENS, such as ERC-8004. Optional ENSNode plugins enable this harmonization to be achieved at an API-layer, through the ENS Omnigraph API, even if the complementary protocol may not directly speak to ENS onchain.

Key benefits of this approach for ENS include:

Give ENS “fast-follower speed-to-market” that positions ENS to gain network effects and market distribution power from complementary protocols when they emerge.
Provide ENS with non-committal adaptability. No one knows which protocol(s) will ultimately win the market for AI agent identity, discovery, and coordination. Maybe it will be ERC-8004. Maybe it will be something else. The harmonization offered by the ENS Omnigraph API is achieved through optional ENSNode plugins. If ERC-8004 happens to lose popularity to some other emerging standard, the optional plugin can simply be disabled. No need to permanently commit ENS to one specific implementation of a complementary protocol such as ERC-8004. Each operator of an ENSNode instance can decide for themselves which optional ENSNode plugins they wish to activate.

Plugin

Technically, ERC-8004 is distinct from the ENS protocol. The fields on this page come from the optional erc8004 ENSNode plugin:

Each ENSNode operator chooses which plugins to activate on their instance.
The ERC-8004 fields described here always resolve to null values on any ENSNode instance that has not activated the optional erc8004 plugin.

ENSNode Plugins How operators customize which onchain data an ENSNode instance indexes and exposes.

Who this feature is for

AI agent developers — you publish an agent under ERC-8004 and want a human-readable ENS name to be shown in ENS related services.
AI Apps and services — you want to discover agents and show trustworthy identity, reputation, endpoints and connection to ENS.
Apps that want to extend their display of onchain AI agent related identities with complementary data from ENS.
Apps that want to extend their display of ENS identities to include AI agent related attributes of that identity where relevant.

Example Queries

Find ERC-8004 agents associated with an ENS name

Start from an ENS name. The agent data lives under domain.resolve.profile.erc8004 — this is interpreted ENS Resolution (see ENS Resolution): the ENS Omnigraph API reads the underlying ENSIP-25/26 records and returns clean, structured fields instead of raw text records. If you want the raw records instead, the ENS Omnigraph API exposes them too via domain.resolve.records.

Each entry in attestations is one ENSIP-25 attestation, with its verification status and the indexed ERC-8004 agent nested inline. By default attestations returns only VERIFIED attestations; pass where to include the partial ones.

query AgentsForName {
  domain(by: { name: "myagent.eth" }) {
    canonical {
      name { beautified }
    }
    resolve {
      profile {
        erc8004 {
          context
          attestations(where: { verification: [VERIFIED, ONLY_ENS, ONLY_AGENT] }) {
            verification # ONLY_ENS | ONLY_AGENT | VERIFIED
            identityRegistry { chainId address }
            agentId
            agent {
              agentId
              chain { name }
              card {
                name
                description
                x402Support
                supportedTrust
              }
              reputation {
                feedbackCount
                averageScore
              }
            }
          }
        }
      }
    }
  }
}

Gate on verification — since ENSIP-25 is a bidirectional relationship, an ENS name can attest to an agent, and an agent can reference an ENS name. This enum covers three cases:
- VERIFIED — both sides agree: the ENS name attests the agent, and the agent references the name.
- ONLY_ENS — the ENS name attests the agent, but the agent does not reference the name back.
- ONLY_AGENT — the agent references the name, but the ENS name does not attest the agent.
A name may have several attestations — in theory, a name can have several agents, so attestations is a list. Iterate and pick what you need.
Everything in one round trip — the agent card and reputation come back nested under each attestation; no second request.

Look up the ENS names associated with an ERC-8004 agent

When you already have an agent (from a registry, a wallet, or search), query it directly. The reverse view domains.attestations returns the ENS names that attest to this agent.

query AgentById {
  erc8004agent(by: {
      chainName: ETHEREUM,
      agentId: "34820"
  }) {
    agentId
    owner { address }
    card {
      name
      description
      supportedTrust
    }
    reputation {
      feedbackCount
      averageScore
    }
    domains {
      attestations(where: { verification: [VERIFIED, ONLY_ENS, ONLY_AGENT] }) {
        verification
        context
        name { beautified }
      }
    }
  }
}

Search for ERC-8004 agents by indexed metadata

Find agents by chain, card name, or ENS name.

query FindErc8004Agents {
  erc8004agents(
    first: 20
    where: {
      chainName: { eq: ETHEREUM }
      cardName: { contains: "trading" }
      ensName: { contains: "eth" }
    }
  ) {
    totalCount
    edges {
      node {
        agentId
        card { name description }
        domains {
          attestations { verification name { beautified } }
        }
      }
    }
  }
}

Read an ERC-8004 agent service profile

Read the endpoint you want to talk to from the agent card. attestations returns only VERIFIED attestations by default, so no where filter is needed here. protocol is an AgentServiceProtocol enum (MCP, A2A, X402, WEB, …), and you can pass protocols to fetch only the services you care about.

query AgentServices {
  domain(by: { name: "myagent.eth" }) {
    resolve {
      profile {
        erc8004 {
          attestations {
            verification
            agent {
              card {
                services(protocols: [MCP, A2A]) {
                  protocol
                  endpoint
                }
              }
            }
          }
        }
      }
    }
  }
}

Since only VERIFIED attestations are returned by default, pass the protocols you need (for example [MCP]) and use the returned endpoint.