Open
Conversation
… AI-friendly manifests, replacing the previous `root-context` key. This change aligns with the llms.txt standard, enhancing compatibility for AI systems and providing a structured format for interaction definitions.
… LLMs.txt text record.
…ations and clarifying interface definitions. Introduce example usage for better understanding of the text record's application in AI interactions.
…tions" to "File Lists of URLs" to better reflect content structure and enhance understanding of additional context provided.
…that there are no specific security concerns related to this ENSIP.
…NSIP-TBD-11 to enhance understanding of the llms.txt standard's application and its compatibility with existing tools.
…ide llms-txt. Update specifications to clarify interface definitions and their applications, ensuring compatibility with emerging AI standards.
…ification to support multiple agentic system interfaces. Introduce structured formats for defining interfaces, including chat, agent, and tools, while clarifying the expected manifest content and usage. This update aims to standardize AI context discovery and interaction methods across ENS names, improving interoperability and developer experience.
…or JSON examples, improving clarity and formatting for interface specifications.
- Rename Root-Context to Agent-Context throughout the document - Add Agent Registry Discovery section (e.g., ERC-8004) - Add Protocol Support Discovery section (e.g., x402, A2A) - Add Multi-Protocol Support Preferences section - Condense and tighten language throughout for clarity - Update client resolution flow to include preference handling
Rename agent-context-record.md to 26.md and assign ENSIP number 26. This ENSIP standardizes the agent-context text record key (ENSIP-5) as a single place for agentic systems to discover context for an ENS name. Agents can be registered on multiple chains while publishing one shared context (e.g. a swap agent's unified token list with chain ID and contract address per token). Specification includes: - Text record key and format (any format: plain text, Markdown, YAML, JSON) - Example: swap agent with Markdown intro and verified token table (WETH, USDC, DAI on chains 1 and 8453) - Client resolution flow - Backwards compatibility, security, rationale Co-authored-by: Cursor <[email protected]>
|
Does this work the same as ERC-8004's agentURI? Putting myself in the shoes of a developer looking at this document without much background, I don't think it has sufficient detail for me to understand what I can do with it. |
Contributor
Author
I had a versioning issue, take a look at this latest version. |
Co-authored-by: Cursor <[email protected]>
jmacwhyte
reviewed
Feb 25, 2026
| - **Format**: Any format suitable for agentic systems (plain text, Markdown, YAML, JSON, etc.) | ||
|
|
||
| The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. The content MAY describe what the ENS name represents and how to interact with it. | ||
|
|
There was a problem hiding this comment.
I don't understand what mechanism is being standardized here. This section basically boils down to "a specific key name may or may not exist, and if it does, it could contain any value".
Could you explain a bit more why this needs to be formalized as an ENSIP? Isn't "describe what the ENS name represents" already possible with the description key defined in ENSIP-5?
Made-with: Cursor
Introduce agent-endpoint[<protocol>] text records aligned with ERC-8004 services: mcp, a2a, oasf, web. Values may be https://, http://, or ipfs:// URIs. Reframe ENSIP-26 around a single multichain ENS identity: agent-context is the entry point pointing to registry or endpoint discovery. Update examples to use a generic Swap Agent with multichain token list across Ethereum, Base, and Optimism. Made-with: Cursor
nxt3d
changed the title
Made-with: Cursor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR adds ENSIP-26, which standardizes two ENS text record keys for AI agent identity:
agent-contextandagent-endpoint[<protocol>]. Together they give agentic systems a single, well-known place to discover and connect to an agent across chains.Key points
agent-context(ENSIP-5 text record) — any format (plain text, Markdown, YAML, JSON); the entry point describing the agent and how to interact with it. May reference agent registries (ENSIP-25) oragent-endpointrecords.agent-endpoint[<protocol>]— protocol-specific connection URLs. Supported protocols aligned with ERC-8004:mcp,a2a,oasf,web. Values may behttps://,http://, oripfs://URIs.agent-contextfor context and identity, then optionally loadagent-endpointrecords to connect.Rationale
An ENS name is the agent's single multichain identity. Defining only the keys and leaving value formats flexible allows experimentation while providing a stable discovery entry point. More structured formats can be specified in future ENSIPs.