ENS Metadata

ENS names are already how people and organizations identify themselves on-chain. ENS metadata takes this a step further: it lets any ENS name or subname carry structured, on-chain data that describes what it represents and what it does. Because the data lives in ENS text records, any client can read it with a standard lookup.

By adding metadata to each node, a flat list of subnames becomes a hierarchical tree where every branch has a defined role and machine-readable attributes.

What can you do with it?

Represent an entire organization. A DAO or company can use a single ENS name as the root of a tree. Subnames underneath represent the organization's treasuries, smart contracts, legal entities, officers, working groups, and operational wallets. Each subname resolves to the address it represents and carries metadata describing its role. The result is a live, verifiable map of everything the organization controls, anchored in one name. Read the guide →

Publish your delegate profile. If you participate in DAO governance, you can attach your delegate statement, conflict-of-interest declarations, and forum handles directly to the ENS name that holds your voting power. Governance tools can discover this information automatically, and you can publish different statements for different DAOs using parameterized keys. Read the guide →

Give your AI agent an identity. An AI agent that owns an ENS name can publish its capabilities, service endpoints, trust models, and cross-registry references as metadata. Any consumer can resolve the agent's name to find everything they need, without a centralized agent registry. Read the guide →

Where to start

To understand the building blocks behind all of this, read how schemas work.

To look up which attributes are available for each node type, see the schema reference.

If you're building a tool that reads ENS metadata, the SDK documentation covers querying metadata programmatically.