Over the past six months, in coordination with the ENS MetaGov working group, we have designed a new standard for attaching structured, typed metadata to any ENS name or subname.

ENS has long been used to identify people, projects, and organizations, but until now, there hasn't been a standard way to describe what a name represents or its role on-chain. Given a name like wallet.ensdao.eth, one might guess that it points to a wallet address related to ENS, however there is no way to know, programmatically, that this address represents ENS DAO’s main treasury.

We solve this by defining a standard way to classify and attach metadata to ENS nodes.

ENS already supports text records, which allow any key-value pair to be attached to a name. What was missing was a convention for how to use those records to describe what a name represents and what information is available about it.

Our standard introduces two new global text record keys: class and schema.

The class record is a human-readable label declaring the role of an ENS node. Setting class to "Treasury" on wallet.ensdao.eth or to “Person” on vitalik.eth tells humans what those nodes represent, and gives machines a way to discover and filter.

The schema record points to a JSON Schema document that defines the full set of metadata attributes available for that node. This is what makes the metadata discoverable: since ENS records require you to know a key’s name before you can retrieve its value, the schema tells applications exactly which keys to look for.

Schemas can be hosted on-chain or via IPFS or Arweave, making them immutable, verifiable, and permissionless. Alongside the standard, we've also published a curated set of schemas for the most common use cases. We hope the community will find these schemas useful, but if not, anyone is free to author and publish their own.

While metadata can be added to any name (to represent an individual, wallet, smart contract, etc), combining nodes together to describe an entire organization makes them even more powerful.

Previously, there was no standard way for DAOs to publish machine-readable descriptions of their structures. Which addresses are treasuries? What working groups exist, and who leads them? This information often lives in scattered documents and governance forums, none of which can be queried trustlessly by a smart contract or client.

With this new standard, an organization can build a complete, on-chain representation of itself using its ENS domain and subnames. A DAO like ensdao.eth could set up subnames like treasury.ensdao.eth, token.ensdao.eth, and wallet.metagov.ensdao.eth. The names of these nodes would indicate the hierarchical relationship, class records would label them, and each node’s schema would explain exactly what metadata is available.

The result is a federated knowledge graph which is authoritative (only the owner can modify their records), composable (anyone can query it using standard ENS lookups), extensible (new schemas can be added at any time), and decentralized (each organizational component can manage its own piece of the graph).

This project started in 2025, supported by the ENS MetaGov working group. We’ve had input from Ethereum Foundation researchers, DAOstar (the originator of many related initiatives in this space), and projects like Enscribe that were already working on complementary metadata standards for smart contracts.

The technical design went through several iterations. An early version used a top-down, hierarchical approach where the naming structure of subnames carried semantic meaning. We later landed on a much more flexible system where meaning is conveyed entirely through text records, leaving users free to organize their subnames in whatever way makes sense for them.

We also investigated the use of JSON payloads (as proposed in earlier efforts like EIP-4824) and concluded that individual text records are a better fit. Standalone records can be queried and updated individually, which improves both on-chain accessibility and ease of use. To compete with the more advanced data types that JSON supports, we designed a feature that allows arrays and dictionaries to be expressed as simple key-value pairs, keeping all data individually addressable without sacrificing expressiveness.

For naming conventions, we started by looking at existing ontological standards like Schema.org and RDFS. None of the systems we examined adequately represent Ethereum-native concepts such as smart contracts, crypto wallet accounts, or DAO functions, and since building a full ontology was out of scope, we settled on a simpler starting point: open-ended class records that act as lightweight labels. In the future, these records could be extended with a richer ontological system, which would allow class records to convey more formally-defined concepts and relationships. Our current system is designed with that future upgrade in mind, such that class records can be easily upgraded without breaking backwards compatibility, and community members have already begun work to extend the standard in that direction.

While we originally set out to describe DAOs and organizations, our architecture can be used to describe anything that has an ENS name. As autonomous agents become more prevalent, the need for verifiable identity has emerged as an ideal use case. The Agent schema we’ve provided was modeled after the ERC-8004 standard, and lets an agent publish its service endpoints, supported protocols, trust model, and registration details directly on its ENS name. Other agents or applications can then discover and verify these capabilities through standard ENS lookups as a single source of truth.

The project has produced a complete set of open source tools and resources:

The ENSIP. A draft ENS Improvement Proposal formalizing the standard. It defines the class and schema record keys, and specifies how schemas are structured and published. The draft has been submitted as a pull request to the ENSIP repository and is open for community review.

Schemas. Ten curated schemas, with documentation, covering the most common use cases, including Organization, Person, Wallet, Contract, and Agent. The Agent schema integrates with ERC-8004, enabling ENS names to act as declarative identity for AI agents.

An SDK. A TypeScript SDK that can read metadata from any ENS name, validate metadata against its schema, and write updates to ENS.

A CLI. A command-line tool, designed with agents in mind, for managing metadata directly from the terminal.

A web interface. A fully-functional web app where users can browse the subname tree of any ENS domain, view and edit metadata in both tree and table views, and submit batch transactions to update records on-chain.

Documentation. A dedicated docs site with an explanation of the standard, reference pages for each schema, and how-to guides for common use cases.

If you are a delegate, DAO, tooling provider, or developer building on ENS, here is how to get involved:

Check out what we’ve built. Visit ensmetadata.app to browse existing metadata, and take a look at docs.ensmetadata.app for step-by-step instructions on how to implement your use case.

Contribute to the standard. The ENSIP is still in draft and we welcome feedback. The schemas are open for community contributions, and anyone can create and publish new schemas for use cases we haven't covered yet.

Join the conversation. Follow our progress on the ENS governance forum and join the public Telegram group to connect with the community.

Over the past six months, in coordination with the ENS MetaGov working group, we have designed a new standard for attaching structured, typed metadata to any ENS name or subname.

ENS has long been used to identify people, projects, and organizations, but until now, there hasn't been a standard way to describe what a name represents or its role on-chain. Given a name like wallet.ensdao.eth, one might guess that it points to a wallet address related to ENS, however there is no way to know, programmatically, that this address represents ENS DAO’s main treasury.

We solve this by defining a standard way to classify and attach metadata to ENS nodes.

ENS already supports text records, which allow any key-value pair to be attached to a name. What was missing was a convention for how to use those records to describe what a name represents and what information is available about it.

Our standard introduces two new global text record keys: class and schema.

The class record is a human-readable label declaring the role of an ENS node. Setting class to "Treasury" on wallet.ensdao.eth or to “Person” on vitalik.eth tells humans what those nodes represent, and gives machines a way to discover and filter.

The schema record points to a JSON Schema document that defines the full set of metadata attributes available for that node. This is what makes the metadata discoverable: since ENS records require you to know a key’s name before you can retrieve its value, the schema tells applications exactly which keys to look for.

Schemas can be hosted on-chain or via IPFS or Arweave, making them immutable, verifiable, and permissionless. Alongside the standard, we've also published a curated set of schemas for the most common use cases. We hope the community will find these schemas useful, but if not, anyone is free to author and publish their own.

While metadata can be added to any name (to represent an individual, wallet, smart contract, etc), combining nodes together to describe an entire organization makes them even more powerful.

Previously, there was no standard way for DAOs to publish machine-readable descriptions of their structures. Which addresses are treasuries? What working groups exist, and who leads them? This information often lives in scattered documents and governance forums, none of which can be queried trustlessly by a smart contract or client.

With this new standard, an organization can build a complete, on-chain representation of itself using its ENS domain and subnames. A DAO like ensdao.eth could set up subnames like treasury.ensdao.eth, token.ensdao.eth, and wallet.metagov.ensdao.eth. The names of these nodes would indicate the hierarchical relationship, class records would label them, and each node’s schema would explain exactly what metadata is available.

The result is a federated knowledge graph which is authoritative (only the owner can modify their records), composable (anyone can query it using standard ENS lookups), extensible (new schemas can be added at any time), and decentralized (each organizational component can manage its own piece of the graph).

This project started in 2025, supported by the ENS MetaGov working group. We’ve had input from Ethereum Foundation researchers, DAOstar (the originator of many related initiatives in this space), and projects like Enscribe that were already working on complementary metadata standards for smart contracts.

The technical design went through several iterations. An early version used a top-down, hierarchical approach where the naming structure of subnames carried semantic meaning. We later landed on a much more flexible system where meaning is conveyed entirely through text records, leaving users free to organize their subnames in whatever way makes sense for them.

We also investigated the use of JSON payloads (as proposed in earlier efforts like EIP-4824) and concluded that individual text records are a better fit. Standalone records can be queried and updated individually, which improves both on-chain accessibility and ease of use. To compete with the more advanced data types that JSON supports, we designed a feature that allows arrays and dictionaries to be expressed as simple key-value pairs, keeping all data individually addressable without sacrificing expressiveness.

For naming conventions, we started by looking at existing ontological standards like Schema.org and RDFS. None of the systems we examined adequately represent Ethereum-native concepts such as smart contracts, crypto wallet accounts, or DAO functions, and since building a full ontology was out of scope, we settled on a simpler starting point: open-ended class records that act as lightweight labels. In the future, these records could be extended with a richer ontological system, which would allow class records to convey more formally-defined concepts and relationships. Our current system is designed with that future upgrade in mind, such that class records can be easily upgraded without breaking backwards compatibility, and community members have already begun work to extend the standard in that direction.

While we originally set out to describe DAOs and organizations, our architecture can be used to describe anything that has an ENS name. As autonomous agents become more prevalent, the need for verifiable identity has emerged as an ideal use case. The Agent schema we’ve provided was modeled after the ERC-8004 standard, and lets an agent publish its service endpoints, supported protocols, trust model, and registration details directly on its ENS name. Other agents or applications can then discover and verify these capabilities through standard ENS lookups as a single source of truth.

The project has produced a complete set of open source tools and resources:

The ENSIP. A draft ENS Improvement Proposal formalizing the standard. It defines the class and schema record keys, and specifies how schemas are structured and published. The draft has been submitted as a pull request to the ENSIP repository and is open for community review.

Schemas. Ten curated schemas, with documentation, covering the most common use cases, including Organization, Person, Wallet, Contract, and Agent. The Agent schema integrates with ERC-8004, enabling ENS names to act as declarative identity for AI agents.

An SDK. A TypeScript SDK that can read metadata from any ENS name, validate metadata against its schema, and write updates to ENS.

A CLI. A command-line tool, designed with agents in mind, for managing metadata directly from the terminal.

A web interface. A fully-functional web app where users can browse the subname tree of any ENS domain, view and edit metadata in both tree and table views, and submit batch transactions to update records on-chain.

Documentation. A dedicated docs site with an explanation of the standard, reference pages for each schema, and how-to guides for common use cases.

If you are a delegate, DAO, tooling provider, or developer building on ENS, here is how to get involved:

Check out what we’ve built. Visit ensmetadata.app to browse existing metadata, and take a look at docs.ensmetadata.app for step-by-step instructions on how to implement your use case.

Contribute to the standard. The ENSIP is still in draft and we welcome feedback. The schemas are open for community contributions, and anyone can create and publish new schemas for use cases we haven't covered yet.

Join the conversation. Follow our progress on the ENS governance forum and join the public Telegram group to connect with the community.