Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

ENSIP-25: AI Agent Registry ENS Name Verification

Authors: premm.eth, raffy.eth, workemon.eth, ses.eth

Created: October 2, 2025

Status: draft

Abstract

This ENSIP defines a standardized method for directly verifying, using text records, the association between an ENS name and an AI agent identity registered in a specific on-chain AI agent registry.

Motivation

With the introduction of on-chain AI agent identity registries, such as ERC-8004, in which agents may declare an associated ENS name, there is a need for a standardized verification method. This verification process is essential for establishing trust between an AI agent identity and the ENS name it claims to control. This ENSIP defines a direct lookup method using a parameterized text record key that includes a unique agent identifier.

Specification

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.

Parameterized Verification Text Record Key

To enable verification of an ENS name from a specific AI agent registry entry, this ENSIP defines a global parameterized ENS text record key:

agent-registration[<registry>][<agentId>]

Where:

  • <registry> is the ERC-7930 interoperable address of the registry contract (hexadecimal string with 0x prefix),
  • <agentId> is the registry-defined agent identifier (string) and MUST NOT contain the characters [ or ].

The combination of <registry> and <agentId> MUST uniquely identify an agent within the context of the referenced registry.

The value of this text record MUST be a non-empty string. Implementations SHOULD set the value to "1". The specific value has no semantic meaning; the presence of a non-empty value is interpreted as an attestation by the ENS name owner that the ENS name is associated with the referenced AI agent registry entry. Verification clients MUST NOT depend on the specific value beyond it being non-empty.

Verification Flow (Registry-to-ENS)

Clients performing verification starting from an AI agent registry entry MUST follow the steps below:

  1. Obtain the claimed ENS name, agent identifier, and registry address from the AI agent registry entry.
  2. Construct the text record key agent-registration[<registry>][<agentId>].
  3. Resolve the text record with this key on the claimed ENS name.
  4. If the resolved value is non-empty, the ENS name is considered verified for that specific agent registry entry.

If the text record does not exist or resolves to an empty value, verification MUST fail.

Ethereum Example

For EVM-based registries, the registry address MUST be encoded as an ERC-7930 interoperable address with a 20-byte address length.

Example registry (ERC-8004 on Ethereum mainnet):

0x8004A169FB4a3325136EB29fA0ceB6D2e539a432

ERC-7930 encoding (EIP-155 chain ID 1):

0x000100000101148004a169fb4a3325136eb29fa0ceb6d2e539a432

Corresponding verification text record key for agent 167:

agent-registration[0x000100000101148004a169fb4a3325136eb29fa0ceb6d2e539a432][167]

Any non-empty value set under this key indicates a positive verification.

Registry Compatibility

This ENSIP is intended for AI agent registries that:

  • assign stable identifiers to agent registrations, and
  • allow an ENS name to be declared as part of the agent’s metadata (on-chain or off-chain).

Registries using this ENSIP MUST document how agent identifiers and claimed ENS names are obtained to allow clients to perform correct verification.

Rationale

This ENSIP provides a minimal verification mechanism that leverages existing ENS text records without requiring resolver upgrades or registry-specific integrations. By embedding a registry entry identifier directly into the text record key, clients can perform deterministic verification from known registry inputs using a single resolver lookup.

The registry component is encoded as an ERC-7930 interoperable address, which combines chain identification and the registry contract address into a canonical representation, enabling unambiguous registry identification across chains.

Backwards Compatibility

Not applicable.

Security Considerations

If an ENS name is transferred to a new owner, any existing verification text records may become stale. Clients SHOULD consider ENS name ownership changes when evaluating the validity of prior attestations and MAY apply additional freshness or revocation checks as appropriate.

Copyright

Copyright and related rights waived via CC0.