From 1548c12e1f515fad6385e4ee15c743c9d4658321 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Thu, 22 May 2025 13:23:01 -0400 Subject: [PATCH 01/21] Add ENSIP-TBD-11 from the main branch of ENSIP-ideas repository (https://github.com/nxt3d/ENSIP-ideas) --- ensips/ensip-TBD-11.md | 72 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 ensips/ensip-TBD-11.md diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md new file mode 100644 index 0000000..b18ecaa --- /dev/null +++ b/ensips/ensip-TBD-11.md @@ -0,0 +1,72 @@ +--- +title: Root‑Context Text Record +author: Prem Makeig (premm.eth) +discussions-to: +status: Idea +created: 2025-05-17 +--- + +## Abstract + +This ENSIP extends **ENSIP‑5: Text Records** by standardizing a single global text record key, **`root-context`**. The key acts as the “home page” for an ENS name when viewed by large language model (LLM) systems: it points to a manifest that tells an AI client *what* the name represents (data source, chatbot, autonomous agent, etc.) and *how* to interact with it. By keeping that manifest onchain, ENS gives any app (chat front‑ends, wallet UIs, MCP middleware, crawlers) one reliable place to look it up. + +## Motivation + +ENS is a globally recognized, tokenized naming system whose ownership is verifiable on-chain. This makes it a natural anchor for agents and AI-focused datasets. A single `root-context` text record lets any client, whether a chat app, wallet, crawler or MCP middleware, load the initial instructions it needs before deciding how to behave. This newly introduced text record supplies the context an LLM requires, signals which interface to present (chat, agent or data), and keeps the pointer verifiable and reproducible because it is stored on-chain. + +## Specification + +### Text Record Key + +* **Key**: `root-context` +* **Value**: Text in UTF-8 format for a manifest that outlines one or more interfaces (for example, `chat`, `agent`, `data`) plus any supporting metadata. +* **Expected Format**: Plain text, YAML, JSON, or other standard formats designed for LLM context. + +The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. Implementers MAY embed multiple interfaces in a single manifest; each interface can be described in natural language or structured metadata. + +### Semantic Role *(informative)* + +Think of `root-context` as the landing page of a web application, except that it is optimized for AI, especially LLMs: + +* **Chat interface.** A manifest might instruct: “You are the official support bot for my blog. Greet users and answer FAQ from the dataset at `ipfs://…`.” Chat clients that recognize this cue can preload the context before opening a conversation. +* **Agent interface.** The same manifest could include a second section: “When invoked as an *agent*, the ENS name can be loaded by MCP middleware, which exposes tools to the LLM. The tools themselves may be defined using dynamic text record keys or smart contract addresses and interfaces. Additional resources such as an API endpoint for an LLM or a memory service may be supplied to the MCP middleware to support the agent's behavior. This provides all the necessary components to "enliven" the ENS name as a fully functional AI agent.” +* **Data-only mode.** In read-only scenarios, a manifest could simply declare: “This ENS name hosts the latest quarterly report PDFs.” These files could be stored as the contenthash record of the name, referenced using [ENSIP-TBD-9](https://github.com/nxt3d/ENSIP-ideas/blob/main/ENSIPS/ensip-TBD-9.md), or linked using `ipfs://`, `ar://`, or standard URLs. Indexers would treat it as a static data source. + +Each interface is *discoverable* through the manifest, so no additional ENS text records are required. + +### Client Resolution Flow *(informative)* + +1. Resolve `root-context` for the target ENS name. +2. Retrieve the manifest. +3. Parse the manifest to select an interface that matches the client’s capabilities (for example, chat or agent). +4. Proceed according to the manifest’s instructions: initializing an LLM, loading tools, displaying UI hints, or fetching datasets. + +### Backwards Compatibility + +Unaware clients will simply ignore the new key; existing behavior is unaffected. + +### Example + +A simple example using Ethers.js: + +```js +const resolver = await provider.getResolver("example.eth"); +const rootContext = await resolver.getText("root-context"); +console.log(rootContext); +``` + +This command returns the raw content that defines the ENS name’s machine-readable context. + +### Security Considerations + +There are no security considerations specific to this ENSIP. + +## Rationale *(informative)* + +The purpose of this ENSIP is to introduce a standardized way for clients to locate and interpret AI-relevant context for any ENS name. By associating a plain text pointer with the name itself, developers and applications can uniformly initialize context-aware behavior in a uniform way. + +## Copyright + +CC0‑1.0 + + From 45dde5f5ae265790764a8758ae45b193fce75636 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Fri, 30 May 2025 19:11:17 +0200 Subject: [PATCH 02/21] Update ENSIP-TBD-11 to standardize the `llms-txt` text record key for 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. --- ensips/ensip-TBD-11.md | 111 +++++++++++++++++++++++++++++++---------- 1 file changed, 85 insertions(+), 26 deletions(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index b18ecaa..0278242 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -1,5 +1,5 @@ --- -title: Root‑Context Text Record +title: LLMs.txt Text Record author: Prem Makeig (premm.eth) discussions-to: status: Idea @@ -8,38 +8,97 @@ created: 2025-05-17 ## Abstract -This ENSIP extends **ENSIP‑5: Text Records** by standardizing a single global text record key, **`root-context`**. The key acts as the “home page” for an ENS name when viewed by large language model (LLM) systems: it points to a manifest that tells an AI client *what* the name represents (data source, chatbot, autonomous agent, etc.) and *how* to interact with it. By keeping that manifest onchain, ENS gives any app (chat front‑ends, wallet UIs, MCP middleware, crawlers) one reliable place to look it up. +This ENSIP extends **ENSIP‑5: Text Records** by standardizing a single global text record key, **`llms-txt`**. The key conforms to the llms.txt standard introduced by Jeremy Howard in September 2024, acting as an AI-friendly manifest for an ENS name. It tells agent based systems *what* the name represents (data source, chatbot, autonomous agent, etc.) and *how* to interact with it. By storing this llms.txt-compliant manifest onchain via ENS, any app (chat front‑ends, wallet UIs, MCP middleware, crawlers) has one reliable, verifiable place to discover AI-relevant context and interaction methods. ## Motivation -ENS is a globally recognized, tokenized naming system whose ownership is verifiable on-chain. This makes it a natural anchor for agents and AI-focused datasets. A single `root-context` text record lets any client, whether a chat app, wallet, crawler or MCP middleware, load the initial instructions it needs before deciding how to behave. This newly introduced text record supplies the context an LLM requires, signals which interface to present (chat, agent or data), and keeps the pointer verifiable and reproducible because it is stored on-chain. +ENS is a globally recognized, tokenized naming system whose ownership is verifiable on-chain. This makes it a natural anchor for agents and AI-focused datasets. The llms.txt standard provides a proven format for making web content LLM-friendly, and adapting it to ENS text records creates a standardized way for AI systems to discover and interact with ENS names. A single `llms-txt` text record lets any client load the initial instructions it needs before deciding how to behave, while conforming to an emerging web standard that's already adopted by thousands of documentation sites and developer tools. ## Specification ### Text Record Key -* **Key**: `root-context` -* **Value**: Text in UTF-8 format for a manifest that outlines one or more interfaces (for example, `chat`, `agent`, `data`) plus any supporting metadata. -* **Expected Format**: Plain text, YAML, JSON, or other standard formats designed for LLM context. +* **Key**: `llms-txt` +* **Value**: Text in UTF-8 format conforming to the llms.txt standard with ENS-specific adaptations for interface definitions. +* **Expected Format**: Markdown following llms.txt specification with suggested interface format for multiple interaction modes. -The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. Implementers MAY embed multiple interfaces in a single manifest; each interface can be described in natural language or structured metadata. +The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. Implementers MAY embed multiple interfaces in a single manifest using the suggested format below. -### Semantic Role *(informative)* +### ENS-Adapted llms.txt Format + +The manifest follows the llms.txt standard structure with ENS-specific adaptations: + +1. **H1 Title**: A level-1 heading naming the project or site (this title is the only required element) +2. **Brief Summary**: Blockquote describing what the ENS name represents +3. **Details**: Interface definitions using `--- Interface Name ---` format (no H2 headers allowed in this section) +4. **Optional H2 Sections**: Zero or more markdown sections with file lists of URLs for additional context + +#### Suggested Interface Format + +Interfaces should be defined using the `--- Interface Name ---` delimiter: + +```markdown +# example.eth + +> Example.eth is an AI agent that provides customer support and documentation for the ExampleProject ecosystem. + +--- Chat --- + +You are the official support bot for ExampleProject. Greet users warmly and answer questions about our API, pricing, and getting started. Use the documentation linked below for accurate information. + +--- Agent --- + +When invoked as an agent via MCP middleware, this ENS name provides tools for querying the ExampleProject API, managing user accounts, and generating reports. The agent has access to real-time data and can perform actions on behalf of authenticated users. + +--- Tools --- + +-- status -- + +Queries the ExampleProject API with the given parameters and returns structured data. + +Parameters: none -Think of `root-context` as the landing page of a web application, except that it is optimized for AI, especially LLMs: +-- generate-report -- -* **Chat interface.** A manifest might instruct: “You are the official support bot for my blog. Greet users and answer FAQ from the dataset at `ipfs://…`.” Chat clients that recognize this cue can preload the context before opening a conversation. -* **Agent interface.** The same manifest could include a second section: “When invoked as an *agent*, the ENS name can be loaded by MCP middleware, which exposes tools to the LLM. The tools themselves may be defined using dynamic text record keys or smart contract addresses and interfaces. Additional resources such as an API endpoint for an LLM or a memory service may be supplied to the MCP middleware to support the agent's behavior. This provides all the necessary components to "enliven" the ENS name as a fully functional AI agent.” -* **Data-only mode.** In read-only scenarios, a manifest could simply declare: “This ENS name hosts the latest quarterly report PDFs.” These files could be stored as the contenthash record of the name, referenced using [ENSIP-TBD-9](https://github.com/nxt3d/ENSIP-ideas/blob/main/ENSIPS/ensip-TBD-9.md), or linked using `ipfs://`, `ar://`, or standard URLs. Indexers would treat it as a static data source. +Generates a usage report for a given time period. -Each interface is *discoverable* through the manifest, so no additional ENS text records are required. +Parameters: +- start: Start time as Unix timestamp +- end: End time as Unix timestamp + +--- Contact --- + +For support inquiries, contact support@example.com or visit our Discord at discord.gg/example. + +## Chat + +- [FAQ Database](https://docs.example.com/faq.md): Common questions and answers +- [Knowledge Base](https://docs.example.com/kb.md): Detailed product information +- [User Guide](https://docs.example.com/guide.md): Step-by-step tutorials + +## Contact + +- [Support Portal](https://support.example.com/): Submit tickets and track issues +- [Community Forum](https://forum.example.com/): Connect with other users +- [Status Page](https://status.example.com/): Service availability and updates +``` + +### Semantic Role *(informative)* + +The `llms-txt` text record serves as the "home page" for an ENS name when viewed by agent based systems: + +* **Chat interface.** Defines personality, knowledge sources, and conversation guidelines for chat applications. +* **Agent interface.** Specifies tools, capabilities, and integration methods for MCP middleware and autonomous agents. +* **Tools interface.** Documents available functions, their parameters, and usage examples. +* **Contact interface.** Provides fallback communication methods and support channels. ### Client Resolution Flow *(informative)* -1. Resolve `root-context` for the target ENS name. -2. Retrieve the manifest. -3. Parse the manifest to select an interface that matches the client’s capabilities (for example, chat or agent). -4. Proceed according to the manifest’s instructions: initializing an LLM, loading tools, displaying UI hints, or fetching datasets. +1. Resolve `llms-txt` for the target ENS name. +2. Parse the manifest to identify available interfaces. +3. Select an interface that matches the client's capabilities. +4. Initialize the LLM context with the interface-specific instructions. +5. Optionally fetch additional resources from the H2 sections for enhanced context. ### Backwards Compatibility @@ -51,22 +110,22 @@ A simple example using Ethers.js: ```js const resolver = await provider.getResolver("example.eth"); -const rootContext = await resolver.getText("root-context"); -console.log(rootContext); +const llmsTxt = await resolver.getText("llms-txt"); +console.log(llmsTxt); ``` -This command returns the raw content that defines the ENS name’s machine-readable context. +This command returns the llms.txt-compliant manifest that defines the ENS name's AI interfaces and context. ### Security Considerations -There are no security considerations specific to this ENSIP. +There are no security considerations specific to this ENSIP. Standard considerations for text records apply, including the verification of ENS name ownership and the trustworthiness of referenced external resources. -## Rationale *(informative)* +## Rationale -The purpose of this ENSIP is to introduce a standardized way for clients to locate and interpret AI-relevant context for any ENS name. By associating a plain text pointer with the name itself, developers and applications can uniformly initialize context-aware behavior in a uniform way. +This ENSIP adopts the proven llms.txt standard to provide a familiar, standardized format for AI systems. By leveraging an existing specification that's already adopted by thousands of sites, we ensure compatibility with existing tools and reduce the learning curve for developers. The interface-based approach allows a single ENS name to serve multiple AI use cases while maintaining clean separation of concerns. -## Copyright - -CC0‑1.0 +The choice to use `llms-txt` as the key name creates a clear connection to the broader llms.txt ecosystem while the ENS-specific adaptations (interface definitions) extend the standard in a backwards-compatible way. +## Copyright +CC0‑1.0 \ No newline at end of file From 88ee00f3ca0c2f0d4fbb9936135098b1c4dff6c5 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Fri, 30 May 2025 19:13:07 +0200 Subject: [PATCH 03/21] Update title in ENSIP-TBD-11 to standardize naming convention for the LLMs.txt text record. --- ensips/ensip-TBD-11.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index 0278242..195b1c1 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -1,5 +1,5 @@ --- -title: LLMs.txt Text Record +title: Llms-txt Text Record author: Prem Makeig (premm.eth) discussions-to: status: Idea From db7abb0dedafe080314395f85b007f35262eb7d3 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Fri, 30 May 2025 19:23:13 +0200 Subject: [PATCH 04/21] Refine llms.txt format in ENSIP-TBD-11 by removing ENS-specific adaptations and clarifying interface definitions. Introduce example usage for better understanding of the text record's application in AI interactions. --- ensips/ensip-TBD-11.md | 54 +++++++++++++++++++++++------------------- 1 file changed, 29 insertions(+), 25 deletions(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index 195b1c1..7cd94ed 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -19,23 +19,39 @@ ENS is a globally recognized, tokenized naming system whose ownership is verifia ### Text Record Key * **Key**: `llms-txt` -* **Value**: Text in UTF-8 format conforming to the llms.txt standard with ENS-specific adaptations for interface definitions. -* **Expected Format**: Markdown following llms.txt specification with suggested interface format for multiple interaction modes. +* **Value**: Text in UTF-8 format conforming to the llms.txt standard. +* **Expected Format**: Markdown following llms.txt specification. -The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. Implementers MAY embed multiple interfaces in a single manifest using the suggested format below. +The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. -### ENS-Adapted llms.txt Format +### llms.txt Format -The manifest follows the llms.txt standard structure with ENS-specific adaptations: +The manifest follows the standard llms.txt structure: 1. **H1 Title**: A level-1 heading naming the project or site (this title is the only required element) 2. **Brief Summary**: Blockquote describing what the ENS name represents -3. **Details**: Interface definitions using `--- Interface Name ---` format (no H2 headers allowed in this section) +3. **Details**: Additional paragraphs or lists providing important notes or guidance (no H2 headers allowed in this section) 4. **Optional H2 Sections**: Zero or more markdown sections with file lists of URLs for additional context -#### Suggested Interface Format +### Example + +A simple example using Ethers.js: + +```js +const resolver = await provider.getResolver("example.eth"); +const llmsTxt = await resolver.getText("llms-txt"); +console.log(llmsTxt); +``` + +This command returns the llms.txt-compliant manifest that defines the ENS name's context. + +## Agententic System Interfaces + +This section defines an optional extension to the llms.txt standard specifically for ENS names that want to define multiple AI interaction interfaces. -Interfaces should be defined using the `--- Interface Name ---` delimiter: +### Interface Format + +ENS implementers MAY embed multiple interfaces in their llms.txt manifest using the `--- Interface Name ---` delimiter format in the Details section: ```markdown # example.eth @@ -83,39 +99,27 @@ For support inquiries, contact support@example.com or visit our Discord at disco - [Status Page](https://status.example.com/): Service availability and updates ``` -### Semantic Role *(informative)* +### Interface Types -The `llms-txt` text record serves as the "home page" for an ENS name when viewed by agent based systems: +This extension defines several interface types that ENS names can implement: * **Chat interface.** Defines personality, knowledge sources, and conversation guidelines for chat applications. * **Agent interface.** Specifies tools, capabilities, and integration methods for MCP middleware and autonomous agents. * **Tools interface.** Documents available functions, their parameters, and usage examples. * **Contact interface.** Provides fallback communication methods and support channels. -### Client Resolution Flow *(informative)* +### Client Resolution Flow for Interfaces 1. Resolve `llms-txt` for the target ENS name. -2. Parse the manifest to identify available interfaces. +2. Parse the manifest to identify available interfaces using the `--- Interface Name ---` delimiters. 3. Select an interface that matches the client's capabilities. -4. Initialize the LLM context with the interface-specific instructions. +4. Initialize the context with the interface-specific instructions. 5. Optionally fetch additional resources from the H2 sections for enhanced context. ### Backwards Compatibility Unaware clients will simply ignore the new key; existing behavior is unaffected. -### Example - -A simple example using Ethers.js: - -```js -const resolver = await provider.getResolver("example.eth"); -const llmsTxt = await resolver.getText("llms-txt"); -console.log(llmsTxt); -``` - -This command returns the llms.txt-compliant manifest that defines the ENS name's AI interfaces and context. - ### Security Considerations There are no security considerations specific to this ENSIP. Standard considerations for text records apply, including the verification of ENS name ownership and the trustworthiness of referenced external resources. From 98c194066699a93ce8e5d99ed9e5fe340a2a5cc3 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Fri, 30 May 2025 19:36:05 +0200 Subject: [PATCH 05/21] Clarify section headings in ENSIP-TBD-11 by renaming "Optional H2 Sections" to "File Lists of URLs" to better reflect content structure and enhance understanding of additional context provided. --- ensips/ensip-TBD-11.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index 7cd94ed..d0b6e7f 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -31,7 +31,7 @@ The manifest follows the standard llms.txt structure: 1. **H1 Title**: A level-1 heading naming the project or site (this title is the only required element) 2. **Brief Summary**: Blockquote describing what the ENS name represents 3. **Details**: Additional paragraphs or lists providing important notes or guidance (no H2 headers allowed in this section) -4. **Optional H2 Sections**: Zero or more markdown sections with file lists of URLs for additional context +4. **File Lists of URLs**: Markdown sub-headers for additional context, each containing a list of URLs ### Example From fa95aa7a011c66d3300513a1430defc8ffc2b2f2 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Fri, 30 May 2025 19:40:07 +0200 Subject: [PATCH 06/21] Remove redundant security considerations in ENSIP-TBD-11, clarifying that there are no specific security concerns related to this ENSIP. --- ensips/ensip-TBD-11.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index d0b6e7f..3e97d57 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -122,7 +122,7 @@ Unaware clients will simply ignore the new key; existing behavior is unaffected. ### Security Considerations -There are no security considerations specific to this ENSIP. Standard considerations for text records apply, including the verification of ENS name ownership and the trustworthiness of referenced external resources. +There are no security considerations specific to this ENSIP. ## Rationale From 69b8e4904cc3fcee47cda54f5c8bec3f89859470 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Fri, 30 May 2025 19:43:53 +0200 Subject: [PATCH 07/21] Add RFC 2119 terminology clarification and reintroduce rationale in ENSIP-TBD-11 to enhance understanding of the llms.txt standard's application and its compatibility with existing tools. --- ensips/ensip-TBD-11.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index 3e97d57..8706e72 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -16,6 +16,8 @@ ENS is a globally recognized, tokenized naming system whose ownership is verifia ## Specification +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. + ### Text Record Key * **Key**: `llms-txt` @@ -116,6 +118,12 @@ This extension defines several interface types that ENS names can implement: 4. Initialize the context with the interface-specific instructions. 5. Optionally fetch additional resources from the H2 sections for enhanced context. +## Rationale + +This ENSIP adopts the proven llms.txt standard to provide a familiar, standardized format for AI systems. By leveraging an existing specification that's already adopted by thousands of sites, we ensure compatibility with existing tools and reduce the learning curve for developers. The interface-based approach allows a single ENS name to serve multiple AI use cases while maintaining clean separation of concerns. + +The choice to use `llms-txt` as the key name creates a clear connection to the broader llms.txt ecosystem while the ENS-specific adaptations (interface definitions) extend the standard in a backwards-compatible way. + ### Backwards Compatibility Unaware clients will simply ignore the new key; existing behavior is unaffected. @@ -124,12 +132,6 @@ Unaware clients will simply ignore the new key; existing behavior is unaffected. There are no security considerations specific to this ENSIP. -## Rationale - -This ENSIP adopts the proven llms.txt standard to provide a familiar, standardized format for AI systems. By leveraging an existing specification that's already adopted by thousands of sites, we ensure compatibility with existing tools and reduce the learning curve for developers. The interface-based approach allows a single ENS name to serve multiple AI use cases while maintaining clean separation of concerns. - -The choice to use `llms-txt` as the key name creates a clear connection to the broader llms.txt ecosystem while the ENS-specific adaptations (interface definitions) extend the standard in a backwards-compatible way. - ## Copyright -CC0‑1.0 \ No newline at end of file +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file From 5f6220196907e93cefa5e630cb7c1ed84ed89da6 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Tue, 3 Jun 2025 05:41:54 -0400 Subject: [PATCH 08/21] Enhance ENSIP-TBD-11 by introducing the llms-agent text record alongside llms-txt. Update specifications to clarify interface definitions and their applications, ensuring compatibility with emerging AI standards. --- ensips/ensip-TBD-11.md | 58 ++++++++++++++++++++++++++---------------- 1 file changed, 36 insertions(+), 22 deletions(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index 8706e72..d303361 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -1,41 +1,55 @@ --- -title: Llms-txt Text Record -author: Prem Makeig (premm.eth) +title: Llms-agent and llms-txt Text Record +author: Prem Makeig (premm.eth) discussions-to: -status: Idea -created: 2025-05-17 +status: Idea +created: 2025-05-17 --- ## Abstract -This ENSIP extends **ENSIP‑5: Text Records** by standardizing a single global text record key, **`llms-txt`**. The key conforms to the llms.txt standard introduced by Jeremy Howard in September 2024, acting as an AI-friendly manifest for an ENS name. It tells agent based systems *what* the name represents (data source, chatbot, autonomous agent, etc.) and *how* to interact with it. By storing this llms.txt-compliant manifest onchain via ENS, any app (chat front‑ends, wallet UIs, MCP middleware, crawlers) has one reliable, verifiable place to discover AI-relevant context and interaction methods. +This ENSIP extends **ENSIP‑5: Text Records** by standardizing two new text records, **`llms-agent`** and **`llms-txt`**. The `llms-agent` text record key is designed as a universal, structured entry point for agentic systems. `llms-txt` conforms to the llms.txt standard introduced by Jeremy Howard in September 2024, acting as an AI-friendly manifest for an ENS name. `llms-txt` is designed to complement the ENS `contenthash` text record by providing LLM-friendly context, in the same way the llms.txt standard complements traditional websites. + +The `llms-agent` ENS text record key is designed to be a standalone entry point for agentic systems. It tells agent-based systems *what* the name represents (data source, chatbot, autonomous agent, etc.) and *how* to interact with it. By storing context data onchain via ENS, any app (chat front ends, wallet UIs, MCP middleware, crawlers) has a reliable, verifiable place to discover AI-relevant context and interaction methods. ## Motivation -ENS is a globally recognized, tokenized naming system whose ownership is verifiable on-chain. This makes it a natural anchor for agents and AI-focused datasets. The llms.txt standard provides a proven format for making web content LLM-friendly, and adapting it to ENS text records creates a standardized way for AI systems to discover and interact with ENS names. A single `llms-txt` text record lets any client load the initial instructions it needs before deciding how to behave, while conforming to an emerging web standard that's already adopted by thousands of documentation sites and developer tools. +ENS is a globally recognized, tokenized naming system whose ownership is verifiable onchain. This makes it a natural anchor for agents and AI-focused datasets. The llms.txt standard provides a proven format for making web content LLM-friendly, and adapting it to ENS text records creates a standardized way for AI systems to discover and interact with ENS names. + +Agentic systems that require verifiable context data are emerging; however, it is not yet clear what the dominant applications will be. The pair of ENS text record keys introduced in this ENSIP, `llms-agent` and `llms-txt`, provide both an open-ended entry point for agentic systems and implement an emerging standard for existing web applications that's already adopted by thousands of documentation sites and developer tools. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. -### Text Record Key +### Text Record Keys + +#### `llms-agent` + +* **Key**: `llms-agent` +* **Value**: Text in UTF-8 format. +* **Expected Format**: None + +The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. + +#### `llms-txt` * **Key**: `llms-txt` * **Value**: Text in UTF-8 format conforming to the llms.txt standard. -* **Expected Format**: Markdown following llms.txt specification. +* **Expected Format**: Markdown following the llms.txt specification. The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. -### llms.txt Format +##### llms.txt Format The manifest follows the standard llms.txt structure: -1. **H1 Title**: A level-1 heading naming the project or site (this title is the only required element) -2. **Brief Summary**: Blockquote describing what the ENS name represents -3. **Details**: Additional paragraphs or lists providing important notes or guidance (no H2 headers allowed in this section) -4. **File Lists of URLs**: Markdown sub-headers for additional context, each containing a list of URLs +1. **H1 Title**: A level-1 heading naming the project or site (this title is the only required element). +2. **Brief Summary**: Blockquote describing what the ENS name represents. +3. **Details**: Additional paragraphs or lists providing important notes or guidance (no H2 headers allowed in this section). +4. **File Lists of URLs**: Markdown sub-headers for additional context, each containing a list of URLs. -### Example +##### Example A simple example using Ethers.js: @@ -47,7 +61,7 @@ console.log(llmsTxt); This command returns the llms.txt-compliant manifest that defines the ENS name's context. -## Agententic System Interfaces +## Agentic System Interfaces This section defines an optional extension to the llms.txt standard specifically for ENS names that want to define multiple AI interaction interfaces. @@ -105,10 +119,10 @@ For support inquiries, contact support@example.com or visit our Discord at disco This extension defines several interface types that ENS names can implement: -* **Chat interface.** Defines personality, knowledge sources, and conversation guidelines for chat applications. -* **Agent interface.** Specifies tools, capabilities, and integration methods for MCP middleware and autonomous agents. -* **Tools interface.** Documents available functions, their parameters, and usage examples. -* **Contact interface.** Provides fallback communication methods and support channels. +* **Chat interface**: Defines personality, knowledge sources, and conversation guidelines for chat applications. +* **Agent interface**: Specifies tools, capabilities, and integration methods for MCP middleware and autonomous agents. +* **Tools interface**: Documents available functions, their parameters, and usage examples. +* **Contact interface**: Provides fallback communication methods and support channels. ### Client Resolution Flow for Interfaces @@ -120,9 +134,9 @@ This extension defines several interface types that ENS names can implement: ## Rationale -This ENSIP adopts the proven llms.txt standard to provide a familiar, standardized format for AI systems. By leveraging an existing specification that's already adopted by thousands of sites, we ensure compatibility with existing tools and reduce the learning curve for developers. The interface-based approach allows a single ENS name to serve multiple AI use cases while maintaining clean separation of concerns. +This ENSIP adopts the proven llms.txt standard to provide a familiar, standardized format for AI systems. By leveraging an existing specification that's already adopted by thousands of sites, we ensure compatibility with existing tools and reduce the learning curve for developers. The interface-based approach allows a single ENS name to serve multiple AI use cases while maintaining a clean separation of concerns. -The choice to use `llms-txt` as the key name creates a clear connection to the broader llms.txt ecosystem while the ENS-specific adaptations (interface definitions) extend the standard in a backwards-compatible way. +The choice to use `llms-txt` as the key name creates a clear connection to the broader llms.txt ecosystem, while the ENS-specific adaptations (interface definitions) extend the standard in a backwards-compatible way. ### Backwards Compatibility @@ -134,4 +148,4 @@ There are no security considerations specific to this ENSIP. ## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 608cf5c5ee5067bde835c4db63a5862f4695a64c Mon Sep 17 00:00:00 2001 From: nxt3d Date: Tue, 10 Jun 2025 08:25:12 -0400 Subject: [PATCH 09/21] Return to the commit e616468b9adf76aaa9d88badaac4c8c770908f70, while keeping the changes history. --- ensips/ensip-TBD-11.md | 147 ++++++++++------------------------------- 1 file changed, 34 insertions(+), 113 deletions(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index d303361..b18ecaa 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -1,151 +1,72 @@ --- -title: Llms-agent and llms-txt Text Record -author: Prem Makeig (premm.eth) +title: Root‑Context Text Record +author: Prem Makeig (premm.eth) discussions-to: -status: Idea -created: 2025-05-17 +status: Idea +created: 2025-05-17 --- ## Abstract -This ENSIP extends **ENSIP‑5: Text Records** by standardizing two new text records, **`llms-agent`** and **`llms-txt`**. The `llms-agent` text record key is designed as a universal, structured entry point for agentic systems. `llms-txt` conforms to the llms.txt standard introduced by Jeremy Howard in September 2024, acting as an AI-friendly manifest for an ENS name. `llms-txt` is designed to complement the ENS `contenthash` text record by providing LLM-friendly context, in the same way the llms.txt standard complements traditional websites. - -The `llms-agent` ENS text record key is designed to be a standalone entry point for agentic systems. It tells agent-based systems *what* the name represents (data source, chatbot, autonomous agent, etc.) and *how* to interact with it. By storing context data onchain via ENS, any app (chat front ends, wallet UIs, MCP middleware, crawlers) has a reliable, verifiable place to discover AI-relevant context and interaction methods. +This ENSIP extends **ENSIP‑5: Text Records** by standardizing a single global text record key, **`root-context`**. The key acts as the “home page” for an ENS name when viewed by large language model (LLM) systems: it points to a manifest that tells an AI client *what* the name represents (data source, chatbot, autonomous agent, etc.) and *how* to interact with it. By keeping that manifest onchain, ENS gives any app (chat front‑ends, wallet UIs, MCP middleware, crawlers) one reliable place to look it up. ## Motivation -ENS is a globally recognized, tokenized naming system whose ownership is verifiable onchain. This makes it a natural anchor for agents and AI-focused datasets. The llms.txt standard provides a proven format for making web content LLM-friendly, and adapting it to ENS text records creates a standardized way for AI systems to discover and interact with ENS names. - -Agentic systems that require verifiable context data are emerging; however, it is not yet clear what the dominant applications will be. The pair of ENS text record keys introduced in this ENSIP, `llms-agent` and `llms-txt`, provide both an open-ended entry point for agentic systems and implement an emerging standard for existing web applications that's already adopted by thousands of documentation sites and developer tools. +ENS is a globally recognized, tokenized naming system whose ownership is verifiable on-chain. This makes it a natural anchor for agents and AI-focused datasets. A single `root-context` text record lets any client, whether a chat app, wallet, crawler or MCP middleware, load the initial instructions it needs before deciding how to behave. This newly introduced text record supplies the context an LLM requires, signals which interface to present (chat, agent or data), and keeps the pointer verifiable and reproducible because it is stored on-chain. ## Specification -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. +### Text Record Key -### Text Record Keys +* **Key**: `root-context` +* **Value**: Text in UTF-8 format for a manifest that outlines one or more interfaces (for example, `chat`, `agent`, `data`) plus any supporting metadata. +* **Expected Format**: Plain text, YAML, JSON, or other standard formats designed for LLM context. -#### `llms-agent` +The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. Implementers MAY embed multiple interfaces in a single manifest; each interface can be described in natural language or structured metadata. -* **Key**: `llms-agent` -* **Value**: Text in UTF-8 format. -* **Expected Format**: None +### Semantic Role *(informative)* -The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. +Think of `root-context` as the landing page of a web application, except that it is optimized for AI, especially LLMs: -#### `llms-txt` +* **Chat interface.** A manifest might instruct: “You are the official support bot for my blog. Greet users and answer FAQ from the dataset at `ipfs://…`.” Chat clients that recognize this cue can preload the context before opening a conversation. +* **Agent interface.** The same manifest could include a second section: “When invoked as an *agent*, the ENS name can be loaded by MCP middleware, which exposes tools to the LLM. The tools themselves may be defined using dynamic text record keys or smart contract addresses and interfaces. Additional resources such as an API endpoint for an LLM or a memory service may be supplied to the MCP middleware to support the agent's behavior. This provides all the necessary components to "enliven" the ENS name as a fully functional AI agent.” +* **Data-only mode.** In read-only scenarios, a manifest could simply declare: “This ENS name hosts the latest quarterly report PDFs.” These files could be stored as the contenthash record of the name, referenced using [ENSIP-TBD-9](https://github.com/nxt3d/ENSIP-ideas/blob/main/ENSIPS/ensip-TBD-9.md), or linked using `ipfs://`, `ar://`, or standard URLs. Indexers would treat it as a static data source. -* **Key**: `llms-txt` -* **Value**: Text in UTF-8 format conforming to the llms.txt standard. -* **Expected Format**: Markdown following the llms.txt specification. +Each interface is *discoverable* through the manifest, so no additional ENS text records are required. -The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. +### Client Resolution Flow *(informative)* -##### llms.txt Format +1. Resolve `root-context` for the target ENS name. +2. Retrieve the manifest. +3. Parse the manifest to select an interface that matches the client’s capabilities (for example, chat or agent). +4. Proceed according to the manifest’s instructions: initializing an LLM, loading tools, displaying UI hints, or fetching datasets. -The manifest follows the standard llms.txt structure: +### Backwards Compatibility -1. **H1 Title**: A level-1 heading naming the project or site (this title is the only required element). -2. **Brief Summary**: Blockquote describing what the ENS name represents. -3. **Details**: Additional paragraphs or lists providing important notes or guidance (no H2 headers allowed in this section). -4. **File Lists of URLs**: Markdown sub-headers for additional context, each containing a list of URLs. +Unaware clients will simply ignore the new key; existing behavior is unaffected. -##### Example +### Example A simple example using Ethers.js: ```js const resolver = await provider.getResolver("example.eth"); -const llmsTxt = await resolver.getText("llms-txt"); -console.log(llmsTxt); -``` - -This command returns the llms.txt-compliant manifest that defines the ENS name's context. - -## Agentic System Interfaces - -This section defines an optional extension to the llms.txt standard specifically for ENS names that want to define multiple AI interaction interfaces. - -### Interface Format - -ENS implementers MAY embed multiple interfaces in their llms.txt manifest using the `--- Interface Name ---` delimiter format in the Details section: - -```markdown -# example.eth - -> Example.eth is an AI agent that provides customer support and documentation for the ExampleProject ecosystem. - ---- Chat --- - -You are the official support bot for ExampleProject. Greet users warmly and answer questions about our API, pricing, and getting started. Use the documentation linked below for accurate information. - ---- Agent --- - -When invoked as an agent via MCP middleware, this ENS name provides tools for querying the ExampleProject API, managing user accounts, and generating reports. The agent has access to real-time data and can perform actions on behalf of authenticated users. - ---- Tools --- - --- status -- - -Queries the ExampleProject API with the given parameters and returns structured data. - -Parameters: none - --- generate-report -- - -Generates a usage report for a given time period. - -Parameters: -- start: Start time as Unix timestamp -- end: End time as Unix timestamp - ---- Contact --- - -For support inquiries, contact support@example.com or visit our Discord at discord.gg/example. - -## Chat - -- [FAQ Database](https://docs.example.com/faq.md): Common questions and answers -- [Knowledge Base](https://docs.example.com/kb.md): Detailed product information -- [User Guide](https://docs.example.com/guide.md): Step-by-step tutorials - -## Contact - -- [Support Portal](https://support.example.com/): Submit tickets and track issues -- [Community Forum](https://forum.example.com/): Connect with other users -- [Status Page](https://status.example.com/): Service availability and updates +const rootContext = await resolver.getText("root-context"); +console.log(rootContext); ``` -### Interface Types - -This extension defines several interface types that ENS names can implement: - -* **Chat interface**: Defines personality, knowledge sources, and conversation guidelines for chat applications. -* **Agent interface**: Specifies tools, capabilities, and integration methods for MCP middleware and autonomous agents. -* **Tools interface**: Documents available functions, their parameters, and usage examples. -* **Contact interface**: Provides fallback communication methods and support channels. - -### Client Resolution Flow for Interfaces +This command returns the raw content that defines the ENS name’s machine-readable context. -1. Resolve `llms-txt` for the target ENS name. -2. Parse the manifest to identify available interfaces using the `--- Interface Name ---` delimiters. -3. Select an interface that matches the client's capabilities. -4. Initialize the context with the interface-specific instructions. -5. Optionally fetch additional resources from the H2 sections for enhanced context. - -## Rationale - -This ENSIP adopts the proven llms.txt standard to provide a familiar, standardized format for AI systems. By leveraging an existing specification that's already adopted by thousands of sites, we ensure compatibility with existing tools and reduce the learning curve for developers. The interface-based approach allows a single ENS name to serve multiple AI use cases while maintaining a clean separation of concerns. +### Security Considerations -The choice to use `llms-txt` as the key name creates a clear connection to the broader llms.txt ecosystem, while the ENS-specific adaptations (interface definitions) extend the standard in a backwards-compatible way. +There are no security considerations specific to this ENSIP. -### Backwards Compatibility +## Rationale *(informative)* -Unaware clients will simply ignore the new key; existing behavior is unaffected. +The purpose of this ENSIP is to introduce a standardized way for clients to locate and interpret AI-relevant context for any ENS name. By associating a plain text pointer with the name itself, developers and applications can uniformly initialize context-aware behavior in a uniform way. -### Security Considerations +## Copyright -There are no security considerations specific to this ENSIP. +CC0‑1.0 -## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 1fc7b59378b4a2f92807bd3c968ab5ad71dc679e Mon Sep 17 00:00:00 2001 From: nxt3d Date: Tue, 10 Jun 2025 08:59:04 -0400 Subject: [PATCH 10/21] Enhance ENSIP-TBD-11 by expanding the `root-context` text record specification 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. --- ensips/ensip-TBD-11.md | 96 +++++++++++++++++++++++++++++++++--------- 1 file changed, 77 insertions(+), 19 deletions(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index b18ecaa..f8b3a9f 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -8,38 +8,93 @@ created: 2025-05-17 ## Abstract -This ENSIP extends **ENSIP‑5: Text Records** by standardizing a single global text record key, **`root-context`**. The key acts as the “home page” for an ENS name when viewed by large language model (LLM) systems: it points to a manifest that tells an AI client *what* the name represents (data source, chatbot, autonomous agent, etc.) and *how* to interact with it. By keeping that manifest onchain, ENS gives any app (chat front‑ends, wallet UIs, MCP middleware, crawlers) one reliable place to look it up. +This ENSIP extends **ENSIP‑5: Text Records** by standardizing a single global text record key, **`root-context`**. The key provides a universal entry point to ENS names for agentic systems, defining a standard way to specify interfaces using the `root-context` text record. It describes *what* the name represents (data source, chatbot, autonomous agent, etc.) and *how* to interact with it. By storing context data onchain via ENS, any app (chat front ends, wallet UIs, MCP middleware, crawlers) has a reliable, verifiable place to discover AI context and interaction methods. ## Motivation -ENS is a globally recognized, tokenized naming system whose ownership is verifiable on-chain. This makes it a natural anchor for agents and AI-focused datasets. A single `root-context` text record lets any client, whether a chat app, wallet, crawler or MCP middleware, load the initial instructions it needs before deciding how to behave. This newly introduced text record supplies the context an LLM requires, signals which interface to present (chat, agent or data), and keeps the pointer verifiable and reproducible because it is stored on-chain. +Agentic systems that require verifiable context data are emerging, including agents that can propose blockchain transactions with calldata, or that rely on critical context data requiring verifiability. ENS names are well positioned to register verifiable context data because they can be stored onchain and are supported by existing tooling. This ENSIP introduces a standard way to discover interfaces (which may include implementations) for storing verifiable AI context using the `root-context` text record. Using this standard, agentic systems can be developed using any type of interface, while allowing apps to ignore interfaces they do not require. ## Specification +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. + ### Text Record Key * **Key**: `root-context` -* **Value**: Text in UTF-8 format for a manifest that outlines one or more interfaces (for example, `chat`, `agent`, `data`) plus any supporting metadata. -* **Expected Format**: Plain text, YAML, JSON, or other standard formats designed for LLM context. +* **Value**: Text in UTF-8 format for a manifest that outlines one or more interfaces (for example, `chat`, `agent` or `tools`) plus any supporting metadata or implementation details. +* **Expected Format**: Plain text, Markdown, YAML, JSON, or other standard formats designed for LLM context. + +The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. Implementers MAY embed multiple interfaces in a single manifest. Each interface can be described in natural language or structured metadata. Implementers MAY include implementation details in the manifest, such as the address and interface of a smart contract or the URL of an API endpoint. + +## Agentic System Interfaces + +This section defines an interface standard for the `root-context` text record of ENS names, allowing for the definition of multiple interfaces for agentic systems. + +## Interface Format + +Implementers MAY embed multiple interfaces in their `root-context` manifest using the `----- Interface Name -----` (five dashes on each side of the interface name) delimiter format. An interface name MUST NOT appear more than once. + +``` +----- Chat ----- + +You are the official support bot for ExampleProject. Greet users warmly and answer questions about our API, pricing, and getting started. Use the documentation linked below for accurate information. +. . . + +----- Agent ----- + +When invoked as an agent via MCP middleware, this ENS name provides tools for querying the ExampleProject API, managing user accounts, and generating reports. The agent has access to real-time data and can perform actions on behalf of authenticated users. +. . . + +----- Tools ----- + +-- status -- -The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. Implementers MAY embed multiple interfaces in a single manifest; each interface can be described in natural language or structured metadata. +Queries the ExampleProject API with the given parameters and returns structured data. -### Semantic Role *(informative)* +Parameters: none -Think of `root-context` as the landing page of a web application, except that it is optimized for AI, especially LLMs: +-- generate-report -- -* **Chat interface.** A manifest might instruct: “You are the official support bot for my blog. Greet users and answer FAQ from the dataset at `ipfs://…`.” Chat clients that recognize this cue can preload the context before opening a conversation. -* **Agent interface.** The same manifest could include a second section: “When invoked as an *agent*, the ENS name can be loaded by MCP middleware, which exposes tools to the LLM. The tools themselves may be defined using dynamic text record keys or smart contract addresses and interfaces. Additional resources such as an API endpoint for an LLM or a memory service may be supplied to the MCP middleware to support the agent's behavior. This provides all the necessary components to "enliven" the ENS name as a fully functional AI agent.” -* **Data-only mode.** In read-only scenarios, a manifest could simply declare: “This ENS name hosts the latest quarterly report PDFs.” These files could be stored as the contenthash record of the name, referenced using [ENSIP-TBD-9](https://github.com/nxt3d/ENSIP-ideas/blob/main/ENSIPS/ensip-TBD-9.md), or linked using `ipfs://`, `ar://`, or standard URLs. Indexers would treat it as a static data source. +Generates a usage report for a given time period. -Each interface is *discoverable* through the manifest, so no additional ENS text records are required. +Parameters: +- start: Start time as Unix timestamp +- end: End time as Unix timestamp +``` + +## Interface Types + +This extension defines several interface types that ENS names MAY implement: + +* **Chat** – Defines personality, knowledge sources, and conversation guidelines for AI chat applications or other user-facing AI applications. +* **Agent** – Specifies tools, capabilities, and integration methods for autonomous or semi-autonomous agents. +* **Tools** – Documents available functions, their parameters, and usage examples. +* **Resources** – Resources used for agentic systems. +* **Prompts** – Prompts that can be used within AI workflows or chat applications. -### Client Resolution Flow *(informative)* +## Client Resolution Flow for Interfaces 1. Resolve `root-context` for the target ENS name. -2. Retrieve the manifest. -3. Parse the manifest to select an interface that matches the client’s capabilities (for example, chat or agent). -4. Proceed according to the manifest’s instructions: initializing an LLM, loading tools, displaying UI hints, or fetching datasets. +2. Parse the manifest to identify available interfaces using the `----- Interface Name -----` delimiters. +3. Select one or more interfaces that match the client's capabilities. +4. Compose a context from the selected interfaces. + +## Links + +Decentralized storage protocols use content identifiers (CIDs) instead of URLs, such that the link is also a hash of the content. Interfaces MAY include embedded links and content in the form of CIDs, DataURLs, or other types of links. DataURLs MUST be included in the context received by the client. DataURLs allow for images to be encoded and included in a raw text document. Other types of links, such as IPFS CIDs, MAY be queried and included in the context received by clients. It is also possible to include URLs, which cannot be verified and SHOULD NOT be queried or included in the context. However, a URL MAY be included in the context as a reference (e.g., as a literal URL string). + +## Markdown + +Markdown provides useful formatting features that can be used within an interface specification. For example, it can be useful to embed JSON or code examples within an interface using a fenced code block: + +```json +{ + "name": "Swap Agent", + "date": "05-30-2025" +} +``` + +Headers and text styling such as bold, italics, etc., can also be used. ### Backwards Compatibility @@ -55,18 +110,21 @@ const rootContext = await resolver.getText("root-context"); console.log(rootContext); ``` -This command returns the raw content that defines the ENS name’s machine-readable context. +This command returns the raw content that defines the ENS name's machine-readable context. ### Security Considerations There are no security considerations specific to this ENSIP. -## Rationale *(informative)* +## Rationale + +This ENSIP creates a standardized context resource for ENS names and with a standardized interface format. The interface-based approach allows a single ENS name to support multiple AI use cases while maintaining a clean separation of concerns. + +By specifying a structured format for `root-context`, this ENSIP enables developers to create more predictable and interoperable agentic systems, reducing the need for ad hoc parsing or proprietary formats. It builds a foundation for ecosystem-wide conventions that can benefit wallet developers, front-end builders, middleware, and even cross-platform agent orchestration, allowing ENS names to act not just as identity anchors, but as context-rich agents. -The purpose of this ENSIP is to introduce a standardized way for clients to locate and interpret AI-relevant context for any ENS name. By associating a plain text pointer with the name itself, developers and applications can uniformly initialize context-aware behavior in a uniform way. ## Copyright -CC0‑1.0 +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From f30ee33cc4089d683c5df00505f4431353b3d8d0 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Tue, 10 Jun 2025 09:10:06 -0400 Subject: [PATCH 11/21] Enhance Markdown usage in ENSIP-TBD-11 by adding fenced code blocks for JSON examples, improving clarity and formatting for interface specifications. --- ensips/ensip-TBD-11.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index f8b3a9f..2a2e97b 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -86,13 +86,14 @@ Decentralized storage protocols use content identifiers (CIDs) instead of URLs, ## Markdown Markdown provides useful formatting features that can be used within an interface specification. For example, it can be useful to embed JSON or code examples within an interface using a fenced code block: - +```` ```json { "name": "Swap Agent", "date": "05-30-2025" } ``` +```` Headers and text styling such as bold, italics, etc., can also be used. From 356a114a6ab9e9f40abbf33d53f8b10b41871fe3 Mon Sep 17 00:00:00 2001 From: Ghadi Mhawej Date: Wed, 11 Jun 2025 17:17:48 +0300 Subject: [PATCH 12/21] feat: Head section in root-context interfaces --- ensips/ensip-TBD-11.md | 52 +++++++++++++++++++++++++++--------------- 1 file changed, 33 insertions(+), 19 deletions(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index 2a2e97b..e7be181 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -1,14 +1,14 @@ --- -title: Root‑Context Text Record -author: Prem Makeig (premm.eth) +title: Root‑Context Text Record +author: Prem Makeig (premm.eth) , Ghadi Mhawej (justghadi.eth) discussions-to: -status: Idea -created: 2025-05-17 +status: Idea +created: 2025-05-17 --- ## Abstract -This ENSIP extends **ENSIP‑5: Text Records** by standardizing a single global text record key, **`root-context`**. The key provides a universal entry point to ENS names for agentic systems, defining a standard way to specify interfaces using the `root-context` text record. It describes *what* the name represents (data source, chatbot, autonomous agent, etc.) and *how* to interact with it. By storing context data onchain via ENS, any app (chat front ends, wallet UIs, MCP middleware, crawlers) has a reliable, verifiable place to discover AI context and interaction methods. +This ENSIP extends **ENSIP‑5: Text Records** by standardizing a single global text record key, **`root-context`**. The key provides a universal entry point to ENS names for agentic systems, defining a standard way to specify interfaces using the `root-context` text record. It describes _what_ the name represents (data source, chatbot, autonomous agent, etc.) and _how_ to interact with it. By storing context data onchain via ENS, any app (chat front ends, wallet UIs, MCP middleware, crawlers) has a reliable, verifiable place to discover AI context and interaction methods. ## Motivation @@ -20,9 +20,9 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S ### Text Record Key -* **Key**: `root-context` -* **Value**: Text in UTF-8 format for a manifest that outlines one or more interfaces (for example, `chat`, `agent` or `tools`) plus any supporting metadata or implementation details. -* **Expected Format**: Plain text, Markdown, YAML, JSON, or other standard formats designed for LLM context. +- **Key**: `root-context` +- **Value**: Text in UTF-8 format for a manifest that outlines one or more interfaces (for example, `chat`, `agent` or `tools`) plus any supporting metadata or implementation details. +- **Expected Format**: Plain text, Markdown, YAML, JSON, or other standard formats designed for LLM context. The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. Implementers MAY embed multiple interfaces in a single manifest. Each interface can be described in natural language or structured metadata. Implementers MAY include implementation details in the manifest, such as the address and interface of a smart contract or the URL of an API endpoint. @@ -34,16 +34,32 @@ This section defines an interface standard for the `root-context` text record of Implementers MAY embed multiple interfaces in their `root-context` manifest using the `----- Interface Name -----` (five dashes on each side of the interface name) delimiter format. An interface name MUST NOT appear more than once. +### Head Section + +The manifest MAY begin with a Head section that provides basic metadata about the available interfaces: + +```----- Head ----- +interfaces: [chat, agent, tools] +``` + +The Head section, if present, MUST be the first section in the manifest. The Head section MUST contain an `interfaces` field that lists all available interface names in the manifest. Additional fields MAY be included in the Head section for implementation-specific metadata. + +### Example Format + ``` +----- Head ----- +interfaces: [chat, agent, tools] +. . . + ----- Chat ----- You are the official support bot for ExampleProject. Greet users warmly and answer questions about our API, pricing, and getting started. Use the documentation linked below for accurate information. -. . . +. . . ----- Agent ----- When invoked as an agent via MCP middleware, this ENS name provides tools for querying the ExampleProject API, managing user accounts, and generating reports. The agent has access to real-time data and can perform actions on behalf of authenticated users. -. . . +. . . ----- Tools ----- @@ -66,16 +82,16 @@ Parameters: This extension defines several interface types that ENS names MAY implement: -* **Chat** – Defines personality, knowledge sources, and conversation guidelines for AI chat applications or other user-facing AI applications. -* **Agent** – Specifies tools, capabilities, and integration methods for autonomous or semi-autonomous agents. -* **Tools** – Documents available functions, their parameters, and usage examples. -* **Resources** – Resources used for agentic systems. -* **Prompts** – Prompts that can be used within AI workflows or chat applications. +- **Chat** – Defines personality, knowledge sources, and conversation guidelines for AI chat applications or other user-facing AI applications. +- **Agent** – Specifies tools, capabilities, and integration methods for autonomous or semi-autonomous agents. +- **Tools** – Documents available functions, their parameters, and usage examples. +- **Resources** – Resources used for agentic systems. +- **Prompts** – Prompts that can be used within AI workflows or chat applications. ## Client Resolution Flow for Interfaces 1. Resolve `root-context` for the target ENS name. -2. Parse the manifest to identify available interfaces using the `----- Interface Name -----` delimiters. +2. If a Head section is present, parse it to identify available interfaces. Otherwise, parse the entire manifest to identify interfaces using the `----- Interface Name -----` delimiters. 3. Select one or more interfaces that match the client's capabilities. 4. Compose a context from the selected interfaces. @@ -86,6 +102,7 @@ Decentralized storage protocols use content identifiers (CIDs) instead of URLs, ## Markdown Markdown provides useful formatting features that can be used within an interface specification. For example, it can be useful to embed JSON or code examples within an interface using a fenced code block: + ```` ```json { @@ -123,9 +140,6 @@ This ENSIP creates a standardized context resource for ENS names and with a stan By specifying a structured format for `root-context`, this ENSIP enables developers to create more predictable and interoperable agentic systems, reducing the need for ad hoc parsing or proprietary formats. It builds a foundation for ecosystem-wide conventions that can benefit wallet developers, front-end builders, middleware, and even cross-platform agent orchestration, allowing ENS names to act not just as identity anchors, but as context-rich agents. - ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). - - From 516fb08def9c301fc910dce61bdf5b471c853582 Mon Sep 17 00:00:00 2001 From: Ghadi Mhawej Date: Thu, 19 Jun 2025 10:48:32 +0300 Subject: [PATCH 13/21] feat: simplify ensip to define only root-context key --- ensips/ensip-TBD-11.md | 118 +++++++---------------------------------- 1 file changed, 18 insertions(+), 100 deletions(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index e7be181..af5f8c1 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -8,11 +8,11 @@ created: 2025-05-17 ## Abstract -This ENSIP extends **ENSIP‑5: Text Records** by standardizing a single global text record key, **`root-context`**. The key provides a universal entry point to ENS names for agentic systems, defining a standard way to specify interfaces using the `root-context` text record. It describes _what_ the name represents (data source, chatbot, autonomous agent, etc.) and _how_ to interact with it. By storing context data onchain via ENS, any app (chat front ends, wallet UIs, MCP middleware, crawlers) has a reliable, verifiable place to discover AI context and interaction methods. +This ENSIP extends ENSIP‑5: Text Records by standardizing a single global text record key, root-context. The key provides a universal entry point to ENS names for agentic systems, allowing them to discover context and interaction methods. By storing context data onchain via ENS, any app (chat front ends, wallet UIs, MCP middleware, crawlers) has a reliable, verifiable place to discover AI context associated with an ENS name. ## Motivation -Agentic systems that require verifiable context data are emerging, including agents that can propose blockchain transactions with calldata, or that rely on critical context data requiring verifiability. ENS names are well positioned to register verifiable context data because they can be stored onchain and are supported by existing tooling. This ENSIP introduces a standard way to discover interfaces (which may include implementations) for storing verifiable AI context using the `root-context` text record. Using this standard, agentic systems can be developed using any type of interface, while allowing apps to ignore interfaces they do not require. +Agentic systems that require verifiable context data are emerging, including agents that can propose blockchain transactions with calldata, or that rely on critical context data requiring verifiability. ENS names are well positioned to register verifiable context data because they can be stored onchain and are supported by existing tooling. This ENSIP introduces a standard way to store and discover verifiable AI context using the root-context text record. Using this standard, agentic systems can reliably discover context associated with ENS names without requiring ad hoc parsing or proprietary formats. ## Specification @@ -21,104 +21,16 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S ### Text Record Key - **Key**: `root-context` -- **Value**: Text in UTF-8 format for a manifest that outlines one or more interfaces (for example, `chat`, `agent` or `tools`) plus any supporting metadata or implementation details. -- **Expected Format**: Plain text, Markdown, YAML, JSON, or other standard formats designed for LLM context. +- **Value**: UTF-8 text containing context information for agentic systems +- **Format**: Any format suitable for consumption by agentic systems, including plain text, Markdown, YAML, JSON, or other standard formats designed for LLM context. -The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. Implementers MAY embed multiple interfaces in a single manifest. Each interface can be described in natural language or structured metadata. Implementers MAY include implementation details in the manifest, such as the address and interface of a smart contract or the URL of an API endpoint. - -## Agentic System Interfaces - -This section defines an interface standard for the `root-context` text record of ENS names, allowing for the definition of multiple interfaces for agentic systems. - -## Interface Format - -Implementers MAY embed multiple interfaces in their `root-context` manifest using the `----- Interface Name -----` (five dashes on each side of the interface name) delimiter format. An interface name MUST NOT appear more than once. - -### Head Section - -The manifest MAY begin with a Head section that provides basic metadata about the available interfaces: - -```----- Head ----- -interfaces: [chat, agent, tools] -``` - -The Head section, if present, MUST be the first section in the manifest. The Head section MUST contain an `interfaces` field that lists all available interface names in the manifest. Additional fields MAY be included in the Head section for implementation-specific metadata. - -### Example Format - -``` ------ Head ----- -interfaces: [chat, agent, tools] -. . . - ------ Chat ----- - -You are the official support bot for ExampleProject. Greet users warmly and answer questions about our API, pricing, and getting started. Use the documentation linked below for accurate information. -. . . - ------ Agent ----- - -When invoked as an agent via MCP middleware, this ENS name provides tools for querying the ExampleProject API, managing user accounts, and generating reports. The agent has access to real-time data and can perform actions on behalf of authenticated users. -. . . - ------ Tools ----- - --- status -- - -Queries the ExampleProject API with the given parameters and returns structured data. - -Parameters: none - --- generate-report -- - -Generates a usage report for a given time period. - -Parameters: -- start: Start time as Unix timestamp -- end: End time as Unix timestamp -``` - -## Interface Types - -This extension defines several interface types that ENS names MAY implement: - -- **Chat** – Defines personality, knowledge sources, and conversation guidelines for AI chat applications or other user-facing AI applications. -- **Agent** – Specifies tools, capabilities, and integration methods for autonomous or semi-autonomous agents. -- **Tools** – Documents available functions, their parameters, and usage examples. -- **Resources** – Resources used for agentic systems. -- **Prompts** – Prompts that can be used within AI workflows or chat applications. +The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. The content MAY describe what the ENS name represents (data source, chatbot, autonomous agent, etc.) and how to interact with it. Implementers MAY include implementation details such as smart contract addresses, API endpoints, or other relevant information. ## Client Resolution Flow for Interfaces -1. Resolve `root-context` for the target ENS name. -2. If a Head section is present, parse it to identify available interfaces. Otherwise, parse the entire manifest to identify interfaces using the `----- Interface Name -----` delimiters. -3. Select one or more interfaces that match the client's capabilities. -4. Compose a context from the selected interfaces. - -## Links - -Decentralized storage protocols use content identifiers (CIDs) instead of URLs, such that the link is also a hash of the content. Interfaces MAY include embedded links and content in the form of CIDs, DataURLs, or other types of links. DataURLs MUST be included in the context received by the client. DataURLs allow for images to be encoded and included in a raw text document. Other types of links, such as IPFS CIDs, MAY be queried and included in the context received by clients. It is also possible to include URLs, which cannot be verified and SHOULD NOT be queried or included in the context. However, a URL MAY be included in the context as a reference (e.g., as a literal URL string). - -## Markdown - -Markdown provides useful formatting features that can be used within an interface specification. For example, it can be useful to embed JSON or code examples within an interface using a fenced code block: +Clients resolve the root-context for an ENS name and interpret the content according to their capabilities and requirements. The content format is not prescribed, allowing flexibility for different use cases while maintaining the common entry point. -```` -```json -{ - "name": "Swap Agent", - "date": "05-30-2025" -} -``` -```` - -Headers and text styling such as bold, italics, etc., can also be used. - -### Backwards Compatibility - -Unaware clients will simply ignore the new key; existing behavior is unaffected. - -### Example +### Example Implementation A simple example using Ethers.js: @@ -128,17 +40,23 @@ const rootContext = await resolver.getText("root-context"); console.log(rootContext); ``` -This command returns the raw content that defines the ENS name's machine-readable context. +## Backwards Compatibility + +Unaware clients will simply ignore the new key; existing behavior is unaffected. -### Security Considerations +This command returns the raw content that defines the ENS name's context for agentic systems. -There are no security considerations specific to this ENSIP. +## Security Considerations + +There are no security considerations specific to this ENSIP. Standard ENS security considerations apply to the underlying text record functionality. ## Rationale -This ENSIP creates a standardized context resource for ENS names and with a standardized interface format. The interface-based approach allows a single ENS name to support multiple AI use cases while maintaining a clean separation of concerns. +This ENSIP creates a standardized entry point for agentic systems to discover context associated with ENS names. By defining only the key and leaving the value format flexible, this specification enables experimentation and evolution of context formats while ensuring interoperability at the discovery level. + +The `root-context` key serves as a well-known location where agentic systems can expect to find relevant context, reducing the need for ad hoc discovery mechanisms. This builds a foundation for ecosystem-wide conventions that can benefit wallet developers, front-end builders, middleware developers, and agent orchestration systems. -By specifying a structured format for `root-context`, this ENSIP enables developers to create more predictable and interoperable agentic systems, reducing the need for ad hoc parsing or proprietary formats. It builds a foundation for ecosystem-wide conventions that can benefit wallet developers, front-end builders, middleware, and even cross-platform agent orchestration, allowing ENS names to act not just as identity anchors, but as context-rich agents. +Future ENSIPs may define more specific formats or conventions for organizing content within the `root-context` field, but this specification intentionally remains minimal to encourage adoption and experimentation. ## Copyright From 4ed460b4413adea34136c1a616dfcd64f2fc630f Mon Sep 17 00:00:00 2001 From: nxt3d Date: Wed, 12 Nov 2025 09:25:16 -0500 Subject: [PATCH 14/21] Rename root-context to agent-context and add registry/protocol discovery - 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 --- ensips/ensip-TBD-11.md | 49 +++++++++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 17 deletions(-) diff --git a/ensips/ensip-TBD-11.md b/ensips/ensip-TBD-11.md index af5f8c1..cc07e79 100644 --- a/ensips/ensip-TBD-11.md +++ b/ensips/ensip-TBD-11.md @@ -1,5 +1,5 @@ --- -title: Root‑Context Text Record +title: Agent‑Context Text Record author: Prem Makeig (premm.eth) , Ghadi Mhawej (justghadi.eth) discussions-to: status: Idea @@ -8,11 +8,13 @@ created: 2025-05-17 ## Abstract -This ENSIP extends ENSIP‑5: Text Records by standardizing a single global text record key, root-context. The key provides a universal entry point to ENS names for agentic systems, allowing them to discover context and interaction methods. By storing context data onchain via ENS, any app (chat front ends, wallet UIs, MCP middleware, crawlers) has a reliable, verifiable place to discover AI context associated with an ENS name. +This ENSIP extends ENSIP‑5: Text Records by standardizing the `agent-context` text record key. The key provides a universal entry point for agentic systems to discover context, interaction methods, agent registries (e.g., ERC-8004), and supported protocols (e.g., x402, A2A). ## Motivation -Agentic systems that require verifiable context data are emerging, including agents that can propose blockchain transactions with calldata, or that rely on critical context data requiring verifiability. ENS names are well positioned to register verifiable context data because they can be stored onchain and are supported by existing tooling. This ENSIP introduces a standard way to store and discover verifiable AI context using the root-context text record. Using this standard, agentic systems can reliably discover context associated with ENS names without requiring ad hoc parsing or proprietary formats. +Agentic systems require verifiable context data. ENS names provide an onchain, verifiable location for this data. This ENSIP standardizes discovery via the `agent-context` text record, eliminating the need for ad hoc parsing. + +As agent registries (e.g., ERC-8004) and protocols (e.g., x402, A2A) emerge, clients need a standardized way to discover which registries an agent uses and what protocols it supports. The `agent-context` record provides this discovery mechanism. ## Specification @@ -20,31 +22,44 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S ### Text Record Key -- **Key**: `root-context` +- **Key**: `agent-context` - **Value**: UTF-8 text containing context information for agentic systems -- **Format**: Any format suitable for consumption by agentic systems, including plain text, Markdown, YAML, JSON, or other standard formats designed for LLM context. +- **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, including smart contract addresses, API endpoints, and other relevant information. + +### Agent Registry Discovery + +The `agent-context` record SHOULD include information about agent registries (e.g., ERC-8004) where the agent is registered. Clients MAY parse the record to identify registry addresses or identifiers for querying additional agent information. + +### Protocol Support Discovery -The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. The content MAY describe what the ENS name represents (data source, chatbot, autonomous agent, etc.) and how to interact with it. Implementers MAY include implementation details such as smart contract addresses, API endpoints, or other relevant information. +The `agent-context` record MAY include information about additional protocols the agent supports (e.g., x402 for payments, A2A for agent-to-agent communication). Clients SHOULD parse the record to identify supported protocols and their configuration requirements. + +### Multi-Protocol Support Preferences + +When an agent supports multiple protocols or registries, the `agent-context` record SHOULD include preference information. For example, an agent may support both MCP and A2A but prefer A2A, or be registered in multiple ERC-8004 registries but prefer one on Base. Preferences MAY be expressed through explicit ordering, priority indicators, or other format-specific mechanisms. ## Client Resolution Flow for Interfaces -Clients resolve the root-context for an ENS name and interpret the content according to their capabilities and requirements. The content format is not prescribed, allowing flexibility for different use cases while maintaining the common entry point. +Clients SHOULD: +1. Resolve the `agent-context` text record for the ENS name +2. Parse the content to extract context information +3. Identify agent registries (e.g., ERC-8004) and supported protocols (e.g., x402, A2A, MCP) +4. Determine preferences when multiple options are available +5. Query relevant registries and configure protocol support according to preferences ### Example Implementation -A simple example using Ethers.js: - ```js const resolver = await provider.getResolver("example.eth"); -const rootContext = await resolver.getText("root-context"); -console.log(rootContext); +const agentContext = await resolver.getText("agent-context"); +// Parse agentContext to discover registries and protocols ``` ## Backwards Compatibility -Unaware clients will simply ignore the new key; existing behavior is unaffected. - -This command returns the raw content that defines the ENS name's context for agentic systems. +Unaware clients will ignore the new key; existing behavior is unaffected. ## Security Considerations @@ -52,11 +67,11 @@ There are no security considerations specific to this ENSIP. Standard ENS securi ## Rationale -This ENSIP creates a standardized entry point for agentic systems to discover context associated with ENS names. By defining only the key and leaving the value format flexible, this specification enables experimentation and evolution of context formats while ensuring interoperability at the discovery level. +This ENSIP creates a standardized entry point for discovering agent context, registries, and protocols. By defining only the key and leaving the value format flexible, it enables experimentation while ensuring interoperability. -The `root-context` key serves as a well-known location where agentic systems can expect to find relevant context, reducing the need for ad hoc discovery mechanisms. This builds a foundation for ecosystem-wide conventions that can benefit wallet developers, front-end builders, middleware developers, and agent orchestration systems. +The `agent-context` key serves as a well-known location for agentic systems, reducing the need for ad hoc discovery mechanisms. As the ecosystem evolves with competing standards, the ability to express preferences becomes essential for optimizing interactions while maintaining client flexibility. -Future ENSIPs may define more specific formats or conventions for organizing content within the `root-context` field, but this specification intentionally remains minimal to encourage adoption and experimentation. +Future ENSIPs may define more specific formats, but this specification intentionally remains minimal to encourage adoption and experimentation. ## Copyright From be9b03124724b59ab97d50fd84cb388c8421d0a0 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Wed, 12 Nov 2025 09:27:38 -0500 Subject: [PATCH 15/21] Rename ensip-TBD-11.md to agent-context-record.md --- ensips/{ensip-TBD-11.md => agent-context-record.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename ensips/{ensip-TBD-11.md => agent-context-record.md} (100%) diff --git a/ensips/ensip-TBD-11.md b/ensips/agent-context-record.md similarity index 100% rename from ensips/ensip-TBD-11.md rename to ensips/agent-context-record.md From 5d2df392cc5671a95f65c30b47f5de24dc21787c Mon Sep 17 00:00:00 2001 From: nxt3d Date: Wed, 12 Nov 2025 09:29:15 -0500 Subject: [PATCH 16/21] Update header style to match ENSIP-24 format --- ensips/agent-context-record.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/ensips/agent-context-record.md b/ensips/agent-context-record.md index cc07e79..04ee1b3 100644 --- a/ensips/agent-context-record.md +++ b/ensips/agent-context-record.md @@ -1,11 +1,16 @@ --- title: Agent‑Context Text Record -author: Prem Makeig (premm.eth) , Ghadi Mhawej (justghadi.eth) -discussions-to: -status: Idea -created: 2025-05-17 +description: A standardized text record for agent context, registry discovery, and protocol support +contributors: + - premm.eth + - justghadi.eth +ensip: + created: "2025-05-17" + status: draft --- +# ENSIP-XX: Agent-Context Text Record + ## Abstract This ENSIP extends ENSIP‑5: Text Records by standardizing the `agent-context` text record key. The key provides a universal entry point for agentic systems to discover context, interaction methods, agent registries (e.g., ERC-8004), and supported protocols (e.g., x402, A2A). From d5840b4e4c305c9ea00dfef15105353992ab4781 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Mon, 16 Feb 2026 16:52:32 -0500 Subject: [PATCH 17/21] ENSIP-26: Agent-Context Text Record 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 --- ensips/26.md | 70 ++++++++++++++++++++++++++++ ensips/agent-context-record.md | 83 ---------------------------------- 2 files changed, 70 insertions(+), 83 deletions(-) create mode 100644 ensips/26.md delete mode 100644 ensips/agent-context-record.md diff --git a/ensips/26.md b/ensips/26.md new file mode 100644 index 0000000..5fd2171 --- /dev/null +++ b/ensips/26.md @@ -0,0 +1,70 @@ +--- +title: Agent‑Context Text Record +description: A standardized text record for agent context and verified agentic data. +contributors: + - premm.eth + - justghadi.eth +ensip: + created: "2025-05-17" + status: draft +--- + +# ENSIP-26: Agent-Context Text Record + +## Abstract + +This ENSIP extends ENSIP‑5: Text Records by standardizing the `agent-context` text record key. The key gives agentic systems a single place to discover context for an ENS name. An agent may be registered in many registries on many chains while still sharing one context: for instance, a swapping agent on multiple chains can publish a single, unified token list in its `agent-context` record. + +## Motivation + +Agentic systems require verifiable context data. ENS names provide an onchain, verifiable location for this data. This ENSIP standardizes discovery via the `agent-context` text record, eliminating the need for managing context data across multiple registries. + +## Specification + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. + +### Text Record Key + +- **Key**: `agent-context` +- **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. + +### Example: Swap Agent Token List + +A swap agent may use the `agent-context` record to publish a unified list of tokens it supports, each with a smart contract address and chain ID. Clients can resolve this record once and discover all supported tokens across chains. + +```markdown +# Swap Agent + +I am a swapping agent that can do swaps on multiple chains. My registered chains can be found using ENSIP-25 `agent-registration` records. My verified tokens that I can swap include: + +| Symbol | Chain ID | Address | +|--------|----------|---------| +| WETH | 1 | 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 | +| WETH | 8453 | 0x7c6b91D9Be1559ADb2fB92A2e0eEecf5e3f4B5c6 | +| USDC | 1 | 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 | +| USDC | 8453 | 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 | +| DAI | 1 | 0x6B175474E89094C44Da98b954EedeAC495271d0F | +| DAI | 8453 | 0x50c5725949A6F0c72E6C4a641F24049A917DB0Cb | +``` + +## Backwards Compatibility + +Unaware clients will ignore the new key; existing behavior is unaffected. + +## Security Considerations + +There are no security considerations specific to this ENSIP. Standard ENS security considerations apply to the underlying text record functionality. + +## Rationale + +This ENSIP creates a standardized entry point for discovering agent context. By defining only the key and leaving the value format flexible, it enables experimentation while ensuring interoperability. + +The `agent-context` key serves as a well-known location for agentic systems, reducing the need for ad hoc discovery mechanisms. As the ecosystem evolves with competing standards, the ability to express preferences becomes essential for optimizing interactions while maintaining client flexibility. + +Future ENSIPs may define more specific formats, but this specification intentionally remains minimal to encourage adoption and experimentation. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/ensips/agent-context-record.md b/ensips/agent-context-record.md deleted file mode 100644 index 04ee1b3..0000000 --- a/ensips/agent-context-record.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Agent‑Context Text Record -description: A standardized text record for agent context, registry discovery, and protocol support -contributors: - - premm.eth - - justghadi.eth -ensip: - created: "2025-05-17" - status: draft ---- - -# ENSIP-XX: Agent-Context Text Record - -## Abstract - -This ENSIP extends ENSIP‑5: Text Records by standardizing the `agent-context` text record key. The key provides a universal entry point for agentic systems to discover context, interaction methods, agent registries (e.g., ERC-8004), and supported protocols (e.g., x402, A2A). - -## Motivation - -Agentic systems require verifiable context data. ENS names provide an onchain, verifiable location for this data. This ENSIP standardizes discovery via the `agent-context` text record, eliminating the need for ad hoc parsing. - -As agent registries (e.g., ERC-8004) and protocols (e.g., x402, A2A) emerge, clients need a standardized way to discover which registries an agent uses and what protocols it supports. The `agent-context` record provides this discovery mechanism. - -## Specification - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. - -### Text Record Key - -- **Key**: `agent-context` -- **Value**: UTF-8 text containing context information for agentic systems -- **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, including smart contract addresses, API endpoints, and other relevant information. - -### Agent Registry Discovery - -The `agent-context` record SHOULD include information about agent registries (e.g., ERC-8004) where the agent is registered. Clients MAY parse the record to identify registry addresses or identifiers for querying additional agent information. - -### Protocol Support Discovery - -The `agent-context` record MAY include information about additional protocols the agent supports (e.g., x402 for payments, A2A for agent-to-agent communication). Clients SHOULD parse the record to identify supported protocols and their configuration requirements. - -### Multi-Protocol Support Preferences - -When an agent supports multiple protocols or registries, the `agent-context` record SHOULD include preference information. For example, an agent may support both MCP and A2A but prefer A2A, or be registered in multiple ERC-8004 registries but prefer one on Base. Preferences MAY be expressed through explicit ordering, priority indicators, or other format-specific mechanisms. - -## Client Resolution Flow for Interfaces - -Clients SHOULD: -1. Resolve the `agent-context` text record for the ENS name -2. Parse the content to extract context information -3. Identify agent registries (e.g., ERC-8004) and supported protocols (e.g., x402, A2A, MCP) -4. Determine preferences when multiple options are available -5. Query relevant registries and configure protocol support according to preferences - -### Example Implementation - -```js -const resolver = await provider.getResolver("example.eth"); -const agentContext = await resolver.getText("agent-context"); -// Parse agentContext to discover registries and protocols -``` - -## Backwards Compatibility - -Unaware clients will ignore the new key; existing behavior is unaffected. - -## Security Considerations - -There are no security considerations specific to this ENSIP. Standard ENS security considerations apply to the underlying text record functionality. - -## Rationale - -This ENSIP creates a standardized entry point for discovering agent context, registries, and protocols. By defining only the key and leaving the value format flexible, it enables experimentation while ensuring interoperability. - -The `agent-context` key serves as a well-known location for agentic systems, reducing the need for ad hoc discovery mechanisms. As the ecosystem evolves with competing standards, the ability to express preferences becomes essential for optimizing interactions while maintaining client flexibility. - -Future ENSIPs may define more specific formats, but this specification intentionally remains minimal to encourage adoption and experimentation. - -## Copyright - -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 232a173202b87db37c6d547966d90c5b3b94d96d Mon Sep 17 00:00:00 2001 From: nxt3d Date: Wed, 25 Feb 2026 13:27:56 -0500 Subject: [PATCH 18/21] Add index.html analogy: agent-context as starting point for AI agent Co-authored-by: Cursor --- ensips/26.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ensips/26.md b/ensips/26.md index 5fd2171..8ce1eac 100644 --- a/ensips/26.md +++ b/ensips/26.md @@ -59,7 +59,7 @@ There are no security considerations specific to this ENSIP. Standard ENS securi ## Rationale -This ENSIP creates a standardized entry point for discovering agent context. By defining only the key and leaving the value format flexible, it enables experimentation while ensuring interoperability. +This ENSIP creates a standardized entry point for discovering agent context. The `agent-context` record is analogous to `index.html` in a web application: it is the starting point for interactions with the AI agent. By defining only the key and leaving the value format flexible, it enables experimentation while ensuring interoperability. The `agent-context` key serves as a well-known location for agentic systems, reducing the need for ad hoc discovery mechanisms. As the ecosystem evolves with competing standards, the ability to express preferences becomes essential for optimizing interactions while maintaining client flexibility. From 88384f3871ab07ad25a49e50bbd9a3b77b30f509 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Wed, 25 Feb 2026 16:27:35 -0500 Subject: [PATCH 19/21] Add Agent Resolution section: load agent-context, read content Made-with: Cursor --- ensips/26.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/ensips/26.md b/ensips/26.md index 8ce1eac..d909eda 100644 --- a/ensips/26.md +++ b/ensips/26.md @@ -30,6 +30,15 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S 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. +### Agent Resolution + +To resolve an agent for an ENS name: + +1. Load the `agent-context` text record for the name using the resolver interface defined in ENSIP‑5. +2. Read the record content. The content describes the agent and how to interact with it. + +If the record is absent, no agent context is available for that name. + ### Example: Swap Agent Token List A swap agent may use the `agent-context` record to publish a unified list of tokens it supports, each with a smart contract address and chain ID. Clients can resolve this record once and discover all supported tokens across chains. From 79c8f2d6a68f81943d8582660905021ea39cf519 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Wed, 11 Mar 2026 11:48:04 -0400 Subject: [PATCH 20/21] Add agent-endpoint records and multichain agent identity model Introduce agent-endpoint[] 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 --- ensips/26.md | 69 ++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 51 insertions(+), 18 deletions(-) diff --git a/ensips/26.md b/ensips/26.md index d909eda..cf78b64 100644 --- a/ensips/26.md +++ b/ensips/26.md @@ -1,6 +1,6 @@ --- title: Agent‑Context Text Record -description: A standardized text record for agent context and verified agentic data. +description: A standardized text record for multichain ENS agent identity, context, and endpoint discovery. contributors: - premm.eth - justghadi.eth @@ -13,54 +13,89 @@ ensip: ## Abstract -This ENSIP extends ENSIP‑5: Text Records by standardizing the `agent-context` text record key. The key gives agentic systems a single place to discover context for an ENS name. An agent may be registered in many registries on many chains while still sharing one context: for instance, a swapping agent on multiple chains can publish a single, unified token list in its `agent-context` record. +This ENSIP extends ENSIP‑5: Text Records by standardizing the `agent-context` text record key and `agent-endpoint[]` for agent interface discovery. An ENS name provides a single, multichain identity for an AI agent. The `agent-context` is the entry point: it describes the agent and may reference agent registries (e.g. ENSIP-25) or endpoints set via `agent-endpoint` records. Clients discover one identity, one context, and connect via the indicated registries or endpoints. ## Motivation -Agentic systems require verifiable context data. ENS names provide an onchain, verifiable location for this data. This ENSIP standardizes discovery via the `agent-context` text record, eliminating the need for managing context data across multiple registries. +Agentic systems require a single, verifiable identity that works across chains. An ENS name provides that: one identity, one place for context and discovery. This ENSIP standardizes how agents declare themselves via `agent-context` and `agent-endpoint`. The context can point to whether the agent is registered in agent registries (e.g. ENSIP-25) or has protocol endpoints (MCP, A2A) set via `agent-endpoint` text records. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. -### Text Record Key +### Text Record Keys + +#### agent-context - **Key**: `agent-context` - **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. +The key **MUST** be published via `text(bytes32,string)` as defined in ENSIP‑5. The content describes the agent and how to interact with it. The content MAY reference whether the agent is registered in agent registries (e.g. ENSIP-25 `agent-registration` records) or has endpoints published via `agent-endpoint` text records. This gives clients a single entry point to understand the agent's identity and how to reach it. + +#### agent-endpoint + +- **Key**: `agent-endpoint[]` +- **Format**: A URL (e.g. `https://`, `http://`) identifying the endpoint for the specified agent protocol. + +Name owners MAY publish one or more `agent-endpoint` records for different agent interfaces. Supported protocol values align with [ERC-8004](https://eips.ethereum.org/EIPS/eip-8004) services: + +| Protocol | Description | +| -------- | ----------- | +| `mcp` | [Model Context Protocol](https://modelcontextprotocol.io/) – tools, resources, prompts | +| `a2a` | [Agent-to-Agent Protocol](https://google-a2a.github.io/A2A/) – agent authentication, skills, messaging | +| `oasf` | [OpenAPI Service Format](https://github.com/agntcy/oasf) – OpenAPI-based agent interface | +| `web` | Web interface or human-facing URL | + +Example records: + +| Key | Value | +| ----- | ----- | +| `agent-endpoint[mcp]` | `https://token-swap.mcp` | +| `agent-endpoint[a2a]` | `https://token-swap.a2a` | +| `agent-endpoint[oasf]` | `ipfs://{cid}` or `https://api.example.com/openapi.json` | +| `agent-endpoint[web]` | `https://agent.example.com/` | + +The value MUST be a valid URL, including IPFS URIs (e.g. `ipfs://{cid}`). Clients interpret the protocol and connect accordingly. Additional protocol values MAY be used as the ecosystem evolves. ### Agent Resolution -To resolve an agent for an ENS name: +To resolve an agent for an ENS name (the agent's single identity): 1. Load the `agent-context` text record for the name using the resolver interface defined in ENSIP‑5. -2. Read the record content. The content describes the agent and how to interact with it. +2. Read the record content. The content describes the agent, how to interact with it, and may reference registries (ENSIP-25) or `agent-endpoint` records. +3. Optionally, load `agent-endpoint[]` records to discover protocol-specific endpoints (MCP, A2A, etc.). -If the record is absent, no agent context is available for that name. +If `agent-context` is absent, no agent context is available for that name. -### Example: Swap Agent Token List +### Example: Multichain agent with single identity -A swap agent may use the `agent-context` record to publish a unified list of tokens it supports, each with a smart contract address and chain ID. Clients can resolve this record once and discover all supported tokens across chains. +A Swap Agent has one identity. The context describes the agent and points to how it can be reached: + +| Key | Value | +| ----- | ----- | +| `agent-context` | See below | +| `agent-endpoint[mcp]` | `https://token-swap.mcp` | +| `agent-endpoint[a2a]` | `https://token-swap.a2a` | ```markdown # Swap Agent -I am a swapping agent that can do swaps on multiple chains. My registered chains can be found using ENSIP-25 `agent-registration` records. My verified tokens that I can swap include: +I am a multichain swapping agent with a single ENS identity. Connect to me via the MCP or A2A endpoints set in my agent-endpoint text records. +My verified tokens for swapping include: | Symbol | Chain ID | Address | |--------|----------|---------| | WETH | 1 | 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 | -| WETH | 8453 | 0x7c6b91D9Be1559ADb2fB92A2e0eEecf5e3f4B5c6 | | USDC | 1 | 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 | +| WETH | 8453 | 0x4200000000000000000000000000000000000006 | | USDC | 8453 | 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 | -| DAI | 1 | 0x6B175474E89094C44Da98b954EedeAC495271d0F | -| DAI | 8453 | 0x50c5725949A6F0c72E6C4a641F24049A917DB0Cb | +| WETH | 10 | 0x4200000000000000000000000000000000000006 | +| USDC | 10 | 0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85 | ``` ## Backwards Compatibility -Unaware clients will ignore the new key; existing behavior is unaffected. +Unaware clients will ignore the new keys; existing behavior is unaffected. ## Security Considerations @@ -68,9 +103,7 @@ There are no security considerations specific to this ENSIP. Standard ENS securi ## Rationale -This ENSIP creates a standardized entry point for discovering agent context. The `agent-context` record is analogous to `index.html` in a web application: it is the starting point for interactions with the AI agent. By defining only the key and leaving the value format flexible, it enables experimentation while ensuring interoperability. - -The `agent-context` key serves as a well-known location for agentic systems, reducing the need for ad hoc discovery mechanisms. As the ecosystem evolves with competing standards, the ability to express preferences becomes essential for optimizing interactions while maintaining client flexibility. +This ENSIP creates a single identity model for multichain agents. An ENS name is the identity; `agent-context` is the entry point (analogous to `index.html`), and it can point to registries or endpoints. The `agent-endpoint` records enable direct connections to MCP, A2A, and other protocols. By unifying context and discovery under one ENS name, clients get one place to understand and reach an agent—whether it is registered on-chain, exposed via endpoints, or both. Future ENSIPs may define more specific formats, but this specification intentionally remains minimal to encourage adoption and experimentation. From e4dcecc282532b7f87461f637aabb66885ec89d8 Mon Sep 17 00:00:00 2001 From: nxt3d Date: Wed, 11 Mar 2026 11:51:13 -0400 Subject: [PATCH 21/21] Rename to Agent Text Records Made-with: Cursor --- ensips/26.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ensips/26.md b/ensips/26.md index cf78b64..79e0e87 100644 --- a/ensips/26.md +++ b/ensips/26.md @@ -1,6 +1,6 @@ --- -title: Agent‑Context Text Record -description: A standardized text record for multichain ENS agent identity, context, and endpoint discovery. +title: Agent Text Records +description: Standardized text records for multichain ENS agent identity, context, and endpoint discovery. contributors: - premm.eth - justghadi.eth @@ -9,7 +9,7 @@ ensip: status: draft --- -# ENSIP-26: Agent-Context Text Record +# ENSIP-26: Agent Text Records ## Abstract