Quick note* You’re receiving this email because you were subscribed to my “thecaphimself” Substack. Since then, I’ve moved away from Substack and started running my own independent blog instead. This is the first email you’re receiving from the new home.
AI agents are about to flood the internet with autonomous economic activity. They will trade, research, negotiate, buy, sell, vote, execute transactions, manage assets, and coordinate with other agents.
But almost none of them have real identity.
They have API keys. They have temporary sessions. They have platform accounts, UUIDs, wallet addresses, and maybe a URL somewhere in a registry.
That is not enough.
Because once agents start doing economically meaningful work, and increasingly gain autonomy, the basic question changes from "what can this agent do?" to something much more important:
Who is this agent?
Who owns it? Who controls it? What can it do? Which wallet does it use? Which endpoint should I connect to? Which chains does it support? Has anyone worked with it before? Can it build a reputation over time? Can another agent discover it without depending on a centralized marketplace?
This is the missing layer in most AI-agent infrastructure.
Without portable identity, agents are just siloed scripts.
With identity, they become participants.
And that is why ENSIP-25 (combined with ERC-8004) and ENSIP-26 matter. They are not just some new ENS IP or a standard. They are early signs of a bigger shift - ENS is becoming part of the identity infrastructure for autonomous AI systems.
Next Billion Internet Users Won't Be Human
For the first three decades of the consumer internet, identity was designed around people.
Humans got usernames, email addresses, domains, profile pages, passwords, OAuth, social graphs. The operating assumption was simple: the internet user was a person.
That assumption is rapidly changing.
The next wave of internet users will include software entities that act without waiting for a human to click every button - personal AI assistants, trading agents, DAO operators, research agents, support bots, market makers, compliance agents, procurement agents, entire swarms coordinating across protocols.
These agents need persistent identity: names that other systems can resolve, metadata they can read, endpoints they can discover, reputation that compounds, permissions that can be granted, revoked, and audited, fully transparent.
A wallet alone does not solve this. Wallets are accounts - they can sign, hold assets, execute transactions. But a wallet address does not tell you what an agent does, who controls it, which protocols it speaks, which chains it supports, where its endpoint lives, or whether it is the same agent you interacted with last week.
The Actual Problem
Today, most agents are trapped inside platforms.
An agent might exist inside one app, one marketplace, one cloud provider, one framework. It may have an internal ID, but that ID usually means nothing outside the system that created it. If an agent moves platforms, it loses continuity. Anyone can claim to be the "official" version of a service unless there is a neutral way to confirm the relationship.
If every platform has its own directory, discovery becomes fragmented before the market even matures. Reputation cannot accumulate if it has nowhere to attach.
The autonomous economy needs something closer to DNS, profiles, wallets, and reputation rolled into one open identity layer.
That is where ENS becomes interesting.
ENS Already Solved the First Version of This Problem
ENS did not start with AI agents. It started with a simpler but deeply related problem: Ethereum addresses are not human-readable.
0x8ba1f109551bD432803012645Ac136ddd64DBA72 can receive assets and sign messages, but it is not a name. It is not a profile. It is not easy to recognize, remember, share, or trust.
ENS added a naming layer on top of Ethereum accounts.
An ENS name can resolve to wallet addresses, store text records, point to avatars, websites, content hashes, social handles, and arbitrary metadata. It can be owned, transferred, delegated, extended, and composed across applications.
ENSIP-25 and ENSIP-26 extend that same logic to agents - not by creating a giant new agent platform or inventing an entirely new identity system, but by using something ENS already has: names, ownership, resolvers, and text records.
The Simple Mental Model
Think of the emerging agent identity stack like this:
ENS name
-> stable identity
-> owner and controller
-> wallet/address records
-> profile and metadata records
-> agent registry verification
-> agent context
-> agent endpointsThe agent may have an onchain registry entry. It may have an MCP endpoint. It may have an A2A endpoint. It may operate across Ethereum, Base, Optimism, and other networks. It may have credentials, reputation, validation results, and permissions.
The ENS name becomes the place where all of that can be anchored.
Not all of it has to live inside ENS.
That is the point.
ENS does not need to be the entire agent stack. It only needs to be the neutral naming and resolution layer that lets the rest of the stack become discoverable.
ENSIP-25: Verifying That an Agent Belongs to a Name
ENSIP-25 solves a narrow but important problem.
Suppose an AI agent is registered in an onchain registry such as ERC-8004. The registry entry says:
Agent 167 claims to be associated with researchbot.ethHow does a wallet, explorer, marketplace, or another agent know whether that claim is real?
The registry can make a claim about the ENS name. But the ENS name also needs to confirm the relationship.
ENSIP-25 creates that confirmation mechanism.
It defines a text record format:
agent-registration[<registry>][<agentId>]The registry is encoded as an ERC-7930 interoperable address, which means the record identifies not only the registry contract but also the chain it lives on. The agent ID is the identifier assigned by that registry.
The ENS name owner sets that text record to a non-empty value, usually "1".
That is it.
The value does not carry complex meaning. The presence of the record is the attestation.
The verification flow looks like this:
1. Read the agent registry entry
2. Get the claimed ENS name, registry address, and agent ID
3. Build the ENS text record key
4. Resolve that key on the claimed ENS name
5. If the value is non-empty, the association is verifiedThis turns a one-sided claim into a two-sided relationship.
The registry says: "This agent claims this ENS name."
The ENS name says: "Yes, I recognize this specific registry entry."
This means frontends can show verified agent names. Wallets can warn users when an agent's claimed name is not confirmed. Marketplaces can distinguish between a registry claim and a verified relationship. Agents can evaluate other agents before interacting with them.
Most importantly, it gives the ecosystem a common verification pattern without requiring new resolver contracts or registry-specific integrations.
ENSIP-26: Making Agents Discoverable Through ENS
ENSIP-25 starts from a registry and verifies the ENS name.
ENSIP-26 starts from the ENS name and asks a different question:
How do I discover what this agent is and how to connect to it?
ENSIP-26 standardizes two kinds of ENS text records:
agent-context
agent-endpoint[<protocol>]agent-context is the top-level description of the agent. It can describe what the agent does, what chains it supports, what assets or tools it works with, what registries it uses, and how clients should understand it.
Think of it as index.html for an agent.
It is the first place another system looks when it resolves the name.
agent-endpoint[<protocol>] tells clients how to connect using a specific protocol.
Examples:
agent-endpoint[mcp]
agent-endpoint[a2a]
agent-endpoint[oasf]This matters because the agent communication landscape is already fragmenting. MCP lets AI systems connect to tools and context. A2A is focused on agent-to-agent communication and task coordination. Other protocols will emerge.
ENSIP-26 does not try to pick one winner.
It gives each protocol its own endpoint record.
A trading agent could publish:
agent-context = "Autonomous rebalancing agent for ETH, USDC, and LST portfolios across Ethereum, Base, and Optimism."
agent-endpoint[mcp] = "https://mcp.rebalance.example"
agent-endpoint[a2a] = "https://a2a.rebalance.example"Another agent can resolve the ENS name, read the context, choose the protocol it supports, and connect.
The name becomes the discovery surface.
ERC-8004 agents can already publish services such as MCP, A2A, web, ENS, DID, OASF, email, and wallet endpoints through their agentURI registration file.
ENSIP-26 is useful when discovery starts from an ENS name instead of from a known ERC-8004 registry entry.
ERC-8004 path:
registry + agentId
-> agentURI
-> registration file
-> services / endpoints
ENSIP-26 path:
ENS name
-> agent-context
-> agent-endpoint[protocol]
-> endpoints, registries, or other agent metadataIn other words, ERC-8004 is registry-first discovery. ENSIP-26 is name-first discovery. ERC-8004 starts with an agent ID and resolves outward to its registration file. ENSIP-26 starts with an ENS name and resolves outward to the agent's context, endpoints, and related registries.
ENSIP-25 and ENSIP-26 Together
The two standards become much more powerful together.
ENSIP-25 gives an agent a way to prove that an onchain registry entry is associated with an ENS name.
ENSIP-26 gives the ENS name a way to tell the world what the agent does and where to reach it.
Together they produce a full agent identity loop:
ERC-8004 registry
-> onchain agent registration
-> agent ID
-> reputation and validation primitives
ENSIP-25
-> verifies that the registry entry belongs to the ENS name
ENSIP-26
-> publishes agent context and protocol endpoints
ENS
-> stable name, ownership, resolution, decentralized protocolThat is how open infrastructure starts to form.
A Concrete Example: The Research Agent
Imagine a DAO uses an AI research agent called:
research.dao.ethThis agent monitors governance forums, summarizes proposals, compares treasury risks, and drafts voting recommendations.
Without ENS-based identity, the agent might just be a bot account inside a forum, an API endpoint in a dashboard, and a wallet address used for transactions.
Those pieces do not naturally add up to a coherent identity.
With ENSIP-25 and ENSIP-26, the DAO can publish:
agent-context = "Governance research agent operated by DAO delegates. Summarizes proposals, tracks treasury risk, and prepares voting briefs."
agent-endpoint[mcp] = "https://mcp.research.dao.example"
agent-endpoint[a2a] = "https://a2a.research.dao.example"
agent-registration[<registry>][167] = "1"Now another agent can discover it. A wallet can display it. A DAO dashboard can verify it. A marketplace can index it. A reputation system can attach history to it. And if you need to actually permission it - decide what it can do, on which chains, which contracts and apps, and for how long - that execution layer can live under the same ENS identity via Namera.
To learn more, read "Agent needs permissions, not Private Keys".
The agent becomes a named, public, verifiable participant in the network.
Why ENS Is Strategically Positioned
ENS has several advantages that are difficult to recreate from scratch.
First, ENS already has network effects. Wallets, apps, explorers, and developers already understand and support the ENS resolution.
Second, ENS is composable. Names can resolve to addresses, text records, content, avatars, and arbitrary metadata. Agent records fit naturally into that model. And other can build on top of the protocol easily.
Third, ENS is ownership-based. An ENS name is not just a label in a company's database. It is controlled by an account, contract, or organization.
Fourth, ENS is human-readable. This matters even for agents. Humans will still supervise, select, fund, permission, and evaluate agents. A name like risk.agent.dao.eth is easier to reason about than a registry address plus token ID.
Fifth, ENS is neutral. It does not require every agent to live inside one marketplace, one model provider, one cloud platform, or one chain.
That neutrality is the strategic point.
The autonomous economy will not have one platform. It will have many agents, many chains, many wallets, many protocols, many registries, and many trust systems.
In that world, identity infrastructure wins by being boring, open, and everywhere.
That is ENS's opportunity.
The Hard Parts Are Still Ahead
This is early infrastructure, not a finished agent identity utopia.
There are real open questions.
How should clients handle stale records if an ENS name changes ownership?
How should endpoints prove they are controlled by the same operator as the ENS name?
Should agent-context remain free-form forever, or should the ecosystem converge around schemas?
How should agent reputation transfer across chains and registries?
How should users grant limited permissions to agents without giving them too much control?
How should wallets distinguish between a verified agent, a suspicious agent, and an agent with no history?
These are not reasons to dismiss the standards. They are signs that the category is becoming mature.
Every major identity system starts simple. Then reputation, permissions, discovery, verification, and governance accumulate around it.
ENSIP-25 and ENSIP-26 are early primitives in that process.
What Happens Next
If this direction continues, several things become possible.
Wallets, apps, and others can display verified agent names before users sign transactions.
DAOs can assign named agents to specific operational roles, that will be fully transparent onchain.
Agents can discover other agents through ENS records instead of centralized directories.
Reputation systems can attach history to persistent agent identities.
AI-native wallets can separate owner, controller, endpoint, permissions, and reputation.
The most important shift is conceptual:
Agents become first-class internet actors.
They do not just call APIs. They have names.
They do not just hold wallets. They have identity.
They do not just execute tasks. They build history.
The Bigger Thesis
Most AI-agent infrastructure is focused on capabilities. What tools can the agent use? What models power it? What workflows can it execute? What tasks can it complete? Those questions matter. But the more agents act in the world, the more identity becomes the foundation underneath everything else.
Capability without identity is dangerous.
Autonomy without reputation is not trusted.
Wallets without names are hard to trust.
Endpoints without verification are easy to spoof.
Registries without portable identity become isolated islands.
The autonomous economy needs a naming layer and ENS may quietly become one of its foundations.
ENSIP-25 and ENSIP-26 are not the whole story. They are early signals. But early signals matter, especially when they point toward a larger architecture.
We are watching the emergence of identity infrastructure for autonomous AI systems.
And ENS is already standing in the right place.