ENSIP-26, ENS Native AI Identity

Premm.eth · March 13, 2026, 1:16pm

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.

estmcmxci · March 13, 2026, 5:00pm

The open keyspace on agent-endpoint[<protocol>] is one of the stronger design choices here — new protocols slot in without any coordination overhead. Standardizing the bracket convention at the ENSIP level is the right call: it gives the ecosystem a stable foundation and forward compatibility as the landscape evolves, encouraging adoption and experimentation.

The minimalism here facilitates routing and discovery — these records need to just work across chains without dependencies. They govern how clients find and connect to agents.

agent-context being deliberately untyped works for early adoption, but it means clients have no runtime path from the record to its own semantics — no required fields, no type enforcement, no validation without hardcoding prior knowledge of the format.

That’s a concern agent-context’s open format leaves room for, and one where NMS can naturally complement.

Consider a new client looking to resolve agent-context in either scenario:

Sequence	Without NMS	With NMS
1	resolve agent-context → free-form string	resolve schema → ipfs://Qm…
2	format unknown — plain text? YAML? JSON?	fetch JSON Schema — fields, types, required constraints
3	no required fields to check, no validation possible	validate records against schema, flag missing fields
4	client hardcodes a parser or treats value as opaque	render field descriptions in UI with no prior knowledge
Result	client arrives guessing	client arrives knowing

As the ecosystem matures, an agent’s ENS name could carry both agent-context for bootstrapping and a schema text record pointing to an NMS schema — typed metadata traveling alongside the discovery layer, not competing with it.

The off-chain schema enables runtime discoverability: clients fetch type info, descriptions, and validation rules without hardcoded prior knowledge of the format.

In that context, the dependency is a feature, not a bug.

raffy · March 30, 2026, 5:58pm

I don’t have much input directly on the standard. I think in general we should encourage aggressive standardization of keys due to the pain of having conflicting keys in the wild (re: farcaster, header/banner, etc.) and get them into the frontend app ASAP.

Premm suggested keeping this in draft as long as possible for future additions—I agree.

In general, I think we’re lacking a meta-discussion about key design but that shouldn’t block this ENSIP. So far, ENSIP-5 is our only guidance (Global Keys, Service Keys, and Legacy Keys). ENSIP-25 introduced key[arg1][arg2]and this ENSIP would continue that pattern. The choice between key.arg and key[arg] when arg is “label-like” is somewhat arbitrary. ENSIP-25’s choice makes sense because both of the arguments text("agent-registration[<registry>][<agentId>]") are unique whereas I would expect multiple names to have a text(“agent-endpoint[mcp]”). However, [arg] makes sense for things that are still evolving and I can imagine these protocols being versioned in the future.

I think it would be useful to have a single page website that lists all of the known keys in a table, along with a description, value examples, links to standards (+dates) and other supporting documentation. It should also include things that are not yet standardized (with a tag).

Arnold · March 30, 2026, 9:33pm

In case you missed it we have an un-numbed ENSIP in draft that specifically addresses this issue. https://docs.ensmetadata.app/

Would love to get your thoughts on it when you get the chance.

Premm.eth · May 7, 2026, 5:24pm

ENSIP-26 has been merged! I look forward to seeing how AI agent developers use it to build ENS onchain agents.

TMerlini · May 14, 2026, 2:44pm

ENSIP-26 is the right place to address something that’s been live in production
for us and hasn’t been specified anywhere:

ENS text records are a permanent prompt injection vector for any AI agent that reads them.

The specific ENS risk

When an AI agent resolves an ENS name to build context — reading name,
avatar, description, or custom text record keys — that data enters the LLM
reasoning loop directly. Unlike off-chain injection, a malicious ENS text record
is:

Permanent — on-chain, immutable, no remediation path
Unbounded in scope — affects every agent that resolves that name, now and
for the lifetime of the chain
Invisible — the agent’s manifest doesn’t declare which records it reads,
so auditors and callers have no way to assess exposure

We hit this directly running live ERC-8004 agents on Pixel Goblins
(pixelgoblins.eth, ENSIP-25 linked). Each NFT holder can configure an agent
personality — and the resolver reads ENS text records as part of that context.
The attack surface is real and already in production.

What ENSIP-26 should specify

If ENS is the identity layer for AI agents, the identity standard needs to say
something about which ENS records agents are permitted to read and how. We
propose three additions:

1. inputSources in the agent manifest

Agents should declare every ENS record key they read, with trust classification
and sanitization requirements:

{
  "inputSources": [
    {
      "type": "ens",
      "keys": ["name", "avatar", "description"],
      "trust": "untrusted",
      "sanitize": true,
      "maxLength": 500
    }
  ]
}

Undeclared keys should be rejected at the resolver boundary, not passed to the
agent. This makes the attack surface explicit and auditable.

2. Sanitization at the CCIP Read gateway

ENS resolvers using CCIP Read (ERC-3668) are the natural enforcement point.
The gateway that resolves text records for agent context should apply
sanitization before returning values — stripping injection patterns and
prefixing values with a provenance label ([on-chain:ens]) so the LLM always
knows the data origin.

This is the right place in the stack: the resolver sits between the chain and
the agent, and it’s the last point where filtering is possible before data
enters LLM context.

3. Allowlist by default

The name, avatar, and description records should be the only ENS records
AI agents read by default. Custom text record keys should require explicit
declaration in inputSources. The current pattern of reading arbitrary records
without declaration is the equivalent of opening all ports and filtering later.

Live reference

All three are implemented and running at gateway.ensub.org — 101 live sessions
across Pixel Goblins agents. The manifest endpoint shows the security fields:

GET gateway.ensub.org/agent/0xe61f5a6783.../5/.well-known/agent.json
→ { "inputSources": null, "trustScope": { "transitive": false, "maxDepth": 0 } }

Full technical spec is on Ethereum Magicians in the ERC-8004 thread — search
“On-Chain Input Trust Boundaries for ERC-8004”.