ENSIP-25 introduces a simple, standardized way to verify that an AI agent registered in an on-chain registry, such as ERC-8004, is genuinely associated with an ENS name. It does this by defining a specific ENS text record format that links a registry entry to a name, enabling deterministic verification without requiring new contracts or resolver upgrades. In practice, the ENS name owner sets a straightforward text record to confirm the connection between their on-chain AI agent and their ENS name. As AI agents become more prevalent on-chain, ENSIP-25 positions ENS as a neutral identity layer that can reliably represent both humans and autonomous software.
As on-chain AI agents become more common, a basic question emerges: how do you verify that an agent really controls the identity it claims?
ENSIP-25 defines a minimal solution. It introduces a standardized ENS text record that links an ENS name to an AI agent registry entry. If the record is set to "1" or any other non-empty value the association is considered verified.
The format looks like this:
agent-registration[<registry>][<agentId>]Verification is straightforward:
- Start from a registry entry for an agent that claims an association with an ENS name.
- Construct the text record key using the ERC-7930 interoperable address of the on-chain agent registry and the agent's unique identifier within that registry.
- Resolve it on the claimed ENS name. For example, for the agent with id 42 in the ERC-8004 IdentityRegistry (
0x8004A169FB4a3325136EB29fA0ceB6D2e539a432) on Ethereum mainnet, you would resolve the text record:
agent-registration[0x000100000101148004a169fb4a3325136eb29fa0ceb6d2e539a432][42]- If the record is set to
"1"or any other non-empty value, the association is confirmed.
Websites or frontends listing on-chain AI agents can use this procedure to verify the association between an agent identity and a claimed ENS name, and introduce badges for verified agents to add an additional layer of trust. Conversely, agents associated with a given ENS name can be discovered by scanning for the existence of relevant text records.
This approach uses only existing ENS primitives. No new contracts or resolver upgrades.
The animation below illustrates how ENSIP-25 verification behaves in three common scenarios.
First, a fully verified association. The AI agent's registry entry lists an ENS name, and the ENS name owner has set the corresponding agent-registration[...][...] text record. Because both sides of the link exist, clients can deterministically confirm that the agent and the ENS name belong together.
Second, a one-sided claim from the registry. The agent's registration entry lists an ENS name, but the ENS name does not contain the corresponding text record. In this case the association cannot be verified, since the ENS name owner has not confirmed the relationship.
Third, a one-sided claim from the ENS side. The ENS name contains the agent-registration[...][...] text record, but the specified registry entry does not reference that ENS name. This may indicate a stale or incorrect configuration, and the association again cannot be verified.
Agent Registry Attestation
Verify bidirectional attestations between ENS names and agent identities registered in ERC-8004 agent registries.
For ENS users, ENSIP-25 brings clarity to a new kind of identity that is starting to appear on-chain: autonomous agents.
ENS names already function as portable, human-readable identities across wallets, apps, and protocols. But as AI agents begin signing transactions, holding assets, interacting with contracts autonomously, and participating in governance, a new question emerges: how do you know which identity an actual agent controls?
ENSIP-25 answers that with a simple, deterministic mechanism. If an AI agent is registered in a system like ERC-8004 and claims an ENS name, the name owner can explicitly confirm that association by setting a standardized text record. From there, wallets, explorers, and frontends can independently verify the link using a single resolver lookup.
In practice, this means:
- Wallets can display verified ENS names for AI agents rather than raw addresses.
- Users can confirm that an agent claiming to be
researchbot.ethis actually authorized by that ENS name. - Applications can attach a consistent, human-readable identity to autonomous on-chain behavior.
- Frontends can introduce verified badges for agents that complete this verification flow.
Importantly, this works using existing ENS primitives, which means no new resolver upgrades or custom integrations per registry. Instead, we now have a standardized pattern that clients can implement once and reuse.
As more agents begin to transact, coordinate, and operate independently, ENSIP-25 ensures that their identities remain legible, portable, and verifiable across the ecosystem.
ENSIP-25 is deliberately minimal. But its implications are larger than the mechanism itself.
We are entering a phase where software agents are not just passive tools but active participants in on-chain systems. They register identities. They execute transactions. They manage treasuries. They interact with protocols without direct human initiation.
When that happens, identity continuity becomes critical.
If an agent participates in governance, interacts with a lending protocol, or signs messages across multiple applications, users need to know whether they are interacting with the same entity each time. They need a stable reference point. ENS already provides that continuity for individuals and organizations. ENSIP-25 extends that continuity to autonomous software.
The key design choice here is neutrality. ENS does not become the AI registry. It does not define what an agent is. It does not dictate registry structure. Instead, it provides a verification bridge: a standardized way for names to attest to registry entries.
This reinforces ENS as a neutral identity layer for Ethereum and beyond. Humans, DAOs, organizations, and now AI agents can all anchor themselves to names that are portable across applications.
ENSIP-25 does not attempt to solve agent identity in full. It solves one focused problem: verifiable linkage between an on-chain agent and an ENS name. But in doing so, it strengthens ENS's role as infrastructure for readable, persistent identity in an increasingly autonomous on-chain world.