AI agents are being deployed across Ethereum, Base, Optimism, and a growing number of agent-to-agent platforms. ERC-8004 defines onchain agent registration, but it is scoped to a single chain. There is no way to represent one agent across multiple chains under a single identity. There is also no platform-independent standard for agents to find, understand, and connect to each other. Agents are locked to the platform they are registered on, and interoperability depends on that platform’s continued existence.
Consider agent.uniswap.eth on an agent-to-agent platform. A portfolio rebalancer needs to execute a swap. It wants a Uniswap swap agent. How does it find one? How does it know which chains it supports, which tokens are verified, and which protocol to use? Right now, every platform builds its own discovery layer.
That is the problem ENSIP-26 solves.
One Name, One Identity
ENSIP-26 standardizes two ENS text records: agent-context and agent-endpoint.
agent-context is the entry point. It is a text record, in any format, that describes the agent, what it does, which chains and tokens it supports, and how to reach it. It can reference onchain registries or include inline metadata, such as embedded JSON. The format is open, because agents vary and the ecosystem is still developing.
agent-endpoint[<protocol>] is the connection record. Each protocol gets its own record: MCP, A2A, OASF, or web. A client resolves the name, reads the context, selects a protocol, and connects to the endpoint.
To make this concrete, imagine a hypothetical swap agent at agent.uniswap.eth. Uniswap is used here as a familiar example. Such an agent would publish records like these:
| Record | Value |
|---|---|
agent-context |
Plain-text description with verified token list across Ethereum, Base, and Optimism |
agent-endpoint[mcp] |
https://mcp.swap.uniswap.org |
agent-endpoint[a2a] |
https://a2a.swap.uniswap.org |
The rebalancer resolves agent.uniswap.eth. It reads the context, sees the supported chains and tokens, selects A2A, and connects. No platform-specific discovery layer. No complex formats to learn.
The Full Stack
An onchain agent is five things:
- Identifier — an ENS name
- Endpoint — MCP, A2A, OASF, or web
- Owner — an Ethereum account
- Metadata — ENS address, text, and data records
- Registries and Credentials — ERC-8004, ERC-8121
ENS already provides the identifier and owner. ENSIP-26 standardizes agent context and endpoint discovery, composable and resolvable across chains.
ENSIP-26 also works alongside ENSIP-25. An agent can use agent-context to indicate that it has been registered in an ERC-8004 agent registry. This gives clients a path from the ENS name to any onchain registrations associated with the agent.
Why agent-context and agent-endpoint
For ENS to work as an identity layer for AI agents, there needs to be a standard set of records that clients can rely on. ENSIP-25 established the agent-<key> namespace pattern, starting with agent-registration for ERC-8004 onchain registrations. ENSIP-26 extends that pattern. It adds agent-context for top level context and discovery (i.e. index.html for agents), and agent-endpoint[<protocol>] for connections. These are the minimum records needed to support multichain agents. More records can follow as the stack matures.
ENSIP-26 favors individual text records over JSON blobs. Individual records are easier and cheaper to update onchain. They are also much easier to prove. When an ENS name is hosted on an L2, each record value needs to be verified independently, using tools like Unruggable Gateways. Proving a single text record is straightforward. Proving a field inside a JSON string is not. Keeping records flat keeps the stack simple.
ENSIP-26 vs ERC-8004
ERC-8004 registers agents onchain but it has three limitations for multichain agents.
- No unified identity. Each registration is chain-scoped and independent. There is no way to say the same agent exists across Ethereum, Base, and Optimism.
- No way to identify agent transactions. ENS primary names let an agent claim a human-readable identity for transactions it signs. ERC-8004 has no equivalent.
- High cost. A token must be minted on every chain separately. One ENS name with text records covers all chains at once.
ENSIP-26 is not a replacement for ERC-8004. A single ENS name covers all chains, and via ENSIP-25, it can point to any ERC-8004 registrations the agent has made.