6 posts tagged with "ens"

Over the past year, we have spent a lot of time working on onchain naming. We ran ENS Contract Naming Season, worked with teams such as Nouns DAO, Liquity, Cork, and Giveth, built a Safe integration, shipped a Foundry plugin, and watched thousands of contracts move from anonymous hexadecimal addresses to human-readable names.

That work changed how we think about both Enscribe and ENS.

Most discussions around ENS tend to focus on .eth names as a new primitive — a way for individuals or projects to establish a native onchain identity. That framing is broadly correct, but it misses a second path that is arguably more relevant for organisations: ENS also supports DNS names, and that support changes the nature of the conversation quite significantly.

Instead of asking an organisation to adopt a completely new identity system, ENS allows them to extend the identity they already have. A company can take a domain like example.com, prove ownership, and bring that identity onchain, gaining access to ENS functionality without introducing a new naming surface.

The DNS name base.org lives on ENS, along with base.eth which manages the record

This creates a form of flexibility that is easy to overlook. An organisation can choose to operate entirely with a native ENS name, such as protocol.eth. Or it can bridge its existing DNS identity into ENS and retain continuity with how users already recognise it. Both approaches are valid, and both lead to the same destination: a named, identifiable presence onchain. The difference is how much change is required to get there.

When we published our first Contract Naming Season update in January, the focus was on momentum and what had been achieved. Teams were beginning to name contracts, tooling had improved, and the first public protocol announcements had started to appear.

At that stage, the awards themselves were still ahead of us.

We have now reached a more concrete milestone. The first batch of ENS Contract Naming Season awards has been distributed, and with two months still to go before the program closes at the end of April, we now have a clearer picture of how participation is taking shape.

This is the era of AI dominance and almost every app on the internet has some or the other use case fulfilled by AI. A common intention nowadays is to integrate AI with documentation to enable users learn about the app and its features. But what about integrating AI to help users execute actions on the app?

This is what we are excited to announce with Enscribe Ask AI chat agent. Let's dive into what it looks like and how it works.

The agentic AI chat​

You will see the Ask AI as the first menu item in the left sidebar.

Clicking on it will open the AI chat page.

You can ask practical ENS questions, such as:

• what a primary name is
• how reverse resolution works
• how to name contracts from a CSV.

You can also ask the agent to name your contract on a particular chain or give it a csv containing multiple contracts to name and it will do the rest.

Here's what it looks like when you ask the agent to name a contract on a particular chain:

Clicking on the "Yes, Sign Transactions" button will open the connect wallet to approve the transactions.

And here's what it looks like when you ask the agent to name multiple contracts from a CSV:

You can either drag and drop the CSV file in the chat box or click on the "+" button to upload it.

We'll now see how the AI agent is designed to help you execute ENS workflows.

Technical architecture overview​

At a high level, Enscribe AI chat has three layers:

1. AI chat page: This is where users ask ENS questions, upload a CSV for batch naming, and review next steps.
2. Decision layer (OpenAI intent API): The model decides whether to answer directly or route the request into an execution flow.
3. Execution layer (MCP server): For action requests, MCP runs the ENS workflow: checks prerequisites, prepares transactions, tracks progress, and verifies outcomes.

That structure keeps the experience simple for users. You can ask, “What is a primary name?” and get a clear answer. You can also ask, “Name all contracts in this CSV on Sepolia,” and move into a guided transaction flow.

For naming flows, we keep safety steps in the loop: deterministic CSV validation, explicit approval before signing, status tracking, and operator access revocation after execution, including cleanup paths when something fails.

We also have extended the MCP server with Namespace's ens-mcp server to support more ENS workflows, such as:

• Who owns vitalik.eth?
• What ENS names are owned by 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045?

Getting agentic​

Users are becoming more familiar with AI and interact with it using languages that we speak. We are building Enscribe AI chat to help users execute ENS workflows with prompts.

We are constantly working on improving the agent to support more ENS workflows and make it even more easier for users to name their contracts on ENS.

You can try it out on the Enscribe App.

Happy naming! 🚀

Smart contracts are the backbone of onchain applications, but discovering information about them has always been fragmented. Contract metadata lives across multiple platforms — documentation on one site, audits on another like github, social links scattered everywhere. Basic information like "what does this contract actually do?" is often nowhere to be found.

Enscribe brings contract metadata onchain through ENS text records.

ENS names form a hierarchical namespace, where names can have parents and children, each with their own metadata and ownership. But exploring this structure and the metadata attached to names has always been really hard and un-intuitive.

Thats why we added Name Explorer to Enscribe — a dedicated interface for navigating ENS name hierarchies, viewing metadata, and managing text records all in one place.