# ENS Organizational Registry

> ENS-based organizational identity and metadata registry protocol

## AI Agents

### The Problem

AI agents are proliferating rapidly, but they lack a universal identity layer. Standards like [ERC-8004](https://eips.ethereum.org/EIPS/eip-8004) have emerged to address this — giving agents an on-chain anchor and a standardised way to publish capability metadata. However, ERC-8004 requires agents to register with a smart contract, which pushes the discoverability issue from the agent onto the smart contract. Many different registries could exist, which results in continued fragmentation where users who want to discover an agent have no single source of truth.

### Proposed Solution

ENS node classifications and metadata provide a canonical identity layer for AI agents. An agent that owns an ENS name can publish its `agent-uri` directly as a text record, allowing any consumer to resolve it with a standard ENS lookup. ENS becomes the single source of truth for all agents.

```
myagent.eth
  └── class      = "Agent"
  └── agent-uri  = "https://..."   # ERC-8004 registration file
```

An agent's ENS name is now its universal on-chain identity. One update propagates everywhere.

### Relationship to ERC-8004

This is not a replacement for ERC-8004 — it is a complement to it. The `agent-uri` field points to the same JSON registration file that ERC-8004 specifies, so existing tooling built around that standard continues to work. What ENS adds is a permissionless discovery path that does not depend on a registry contract.

An agent registered with ENS can still register with ERC-8004 or any other on-chain registry. The `registrations` field in the agent schema is designed to hold exactly these cross-registry references, making the ENS name a single place to find all of an agent's registrations regardless of which chains or contracts they span.

### Discovering Agents

Because ENS records are public and indexed, agents that publish a `class = "Agent"` record are discoverable without any central directory:

1. Index `TextChanged` events on the ENS Public Resolver, filtering for records where the key is `class` and the value is `"Agent"`.
2. For each matching node, perform a forward resolution to retrieve the associated ENS name.
3. Read the `agent-uri` record to obtain the ERC-8004 registration file.
4. Optionally read additional records (`name`, `description`, `active`) for a lightweight summary without fetching the registration file at all.

This gives any consumer a live, permissionless view of all agents that have opted in to on-chain discoverability.

### 🚧 Open Questions 🚧

The `agent-uri` field points to an off-chain JSON file. This means the capabilities it describes are only as reliable as the server hosting it — the URI could go stale, the file could be altered, and the content is not directly indexable on-chain.

A natural extension would be publishing the registration file's contents directly as ENS text records. Fields like `services`, `x402-support`, `supported-trust`, and `active` have been added to the proposed agent schema as placeholders for the future. Done fully, an agent's ENS name would become a self-contained, on-chain source of truth for its identity and capabilities — with no external fetch required.

What the right structure for those fields looks like, and how to handle the multilevel data they imply, is an open question for the community. Contributions are welcome.

### Related

* [Agent schema](/schemas/agent)


## Delegate Statements

### The Problem

Delegates in a DAO governance system often publish a statement — a
summary of their philosophy and why others should delegate voting power
to them. Because many delegates participate in multiple DAOs, their
statement often varies from one community to the next.

Right now, every governance platform — Agora, Tally, Karma — stores
delegate statements independently. Delegates update their statement in
one place and it doesn't propagate anywhere else. There is no on-chain
source of truth.

### Proposed Solution

ENS metadata allows delegates to publish statements
directly on their ENS name, with a unique version scoped to each DAO
they are active in — using the DAO's ENS name as the parameter.

```
delegate.alice.eth
  └── statement[uniswap.eth] = "I prioritise..."   # Uniswap statement
  └── statement[ens.eth]    = "My focus is..."     # ENS statement
  └── statement             = "I am a delegate..."  # default fallback
```

Because ENS records are public and permissionlessly readable, any
governance tool can resolve the statement without a proprietary API or
platform-specific submission flow. One update propagates everywhere.

### Discovering delegates

For DAOs with permissionless delegation systems, delegates can be
discovered automatically:

1. Look at on-chain token balances to generate a list of accounts that
   have been delegated to.
2. For each account, perform a reverse ENS lookup to find their
   associated ENS name.
3. Check whether they have a `statement[your-dao.eth]` record set.
4. If found, surface their statement directly — no manual curation needed.

If no DAO-specific statement is found, consumers can fall back to the
default `statement` value.

### Real-World Context

This problem is visible in ENS's own governance. The official
[ENS delegation guide](https://discuss.ens.domains/t/managing-delegation-and-submitting-a-delegate-statement-guide/20197)
notes that statements entered via the Agora UI "are stored off-chain and
are NOT pulled from `eth.ens.delegate`" — meaning a delegate who
updates their ENS record sees no change in Agora or Tally. Platforms
have diverged from the on-chain record entirely.

The parametrized `statement` key solves this by making the ENS name the
single source of truth, with governance UIs as readers rather than stores.

### Related

* [Delegate schemas](/schemas/delegate)
* [Forum username linking](/use-cases/forum-username-linking)


## Forum Username Linking

### The Problem

Governance platforms need to connect on-chain wallets to the forum identities of the people behind them. Right now, every service that needs this mapping — Karma, Tally, Curia, Agora, Snapshot — solves it independently.

Each platform asks delegates to submit their forum username through a platform-specific flow. The result is a fragmented landscape where the same delegate may have linked their Discourse account to different wallets on different platforms, with no clear way for downstream consumers to know which one is authoritative.

### Proposed Solution

ENS metadata provides a canonical place to express this relationship. A delegate sets their forum username once, as a record on their ENS name. Every platform that needs the mapping reads from the same on-chain source.

No proprietary API. No platform-specific submission flow. One update propagates everywhere.

Consider the latest `Delegate` schema and the patternProperty `^forum-handle(\\[[^\\]]+\\])?$` which allows the user to specifiy multiple forum handles.

```sh
delegate.alice.eth
  └── forum-handle[uniswap.eth] = "alice"     # Uniswap forum username
  └── forum-handle[ens.eth] = "alice576"      # ENS forum username
```

Because ENS records are public and permissionlessly readable, any governance tool can resolve the relationship without further interactions.

#### Reverse lookup

To find all users who have registered their ENS forum username, we could index the `forum-handle[ens.eth]` text record.
Standard ENS `TextChanged` filtering will surface all relevant records.

### Verification

Text records set by ENS name owners are self-asserted by default.

For stronger guarantees a `forum-proof[ens.eth]` or `forum-attestation[ens.eth]` could also be introduced using `zkTLS` or `EAS`.

Regardless of the approach the ENS remains the canonical source.

### Why This Matters for DAOs

#### Governance tooling

Many governance platforms currently each maintain their own wallet-to-forum-username mapping. By reading from ENS, they can share a single source of truth. Delegates update once; every platform reflects it.

#### Conflict resolution

When platforms disagree on which wallet belongs to a forum username, the ENS record provides a tiebreaker. The ENS name owner — who controls the private key — is the authoritative source. Platforms can surface a warning when their cached mapping diverges from the ENS record.

### Real-World Context

This use case emerged from a [discussion on the Arbitrum governance forum](https://forum.arbitrum.foundation/t/public-forum-to-wallet-link-verification/28569/2), where community members observed that Karma and Curia were independently building forum-to-wallet verification, creating the exact fragmentation problem ENS text records are designed to solve:

> *"I think we should try to avoid getting into this kind of situation… delegates could also do something simpler, which is to add a record to their ENS names, specifying their Arbitrum Forum username."*
> — paulofonseca.eth, Arbitrum Forum

The ENS Organizational Registry formalises what paulofonseca.eth was already doing manually, turning an informal convention into a standardised, indexable, composable field.

### Related

* [Delegate schemas](/schemas/delegate) — the schema type where forum records appear


## Regulatory Compliance

### The Problem

As DAOs adopt legal wrappers — such as Wyoming's Decentralised Unincorporated Nonprofit Association (DUNA) — they take on regulatory obligations that exist in tension with how on-chain organisations typically operate. A DUNA, for example, may need to publish its registered agent, principal office address, officers, and registration numbers. Other jurisdictions impose similar disclosure requirements on foundations, cooperatives, and other DAO-adjacent legal structures.

Today these details live in off-chain registries, government databases, and legal documents that are difficult to discover and impossible to verify against the organisation's on-chain identity. There is no way to look at a DAO's ENS name and determine whether it has a legal entity, who its officers are, or where it is registered. Worse, there is no way to verify that a statement or transaction was authorised by someone who actually holds a named role in the organisation's legal structure.

### Proposed Solution

An organisation can represent its legal structure as subnodes under its ENS name. Officers, registration details, and office addresses are published as on-chain metadata — making the organisation's corporate structure discoverable from the same place as its treasury addresses and smart contracts.

```
supercooldao.eth
  ├── class              = "Org"
  ├── description        = "A Wyoming DUNA"
  │
  ├── ceo.supercooldao.eth
  │     └── class        = "Officer"
  │     └── full-name    = "Alice Johnson"
  │     └── title        = "Chief Executive Officer"
  │
  ├── secretary.supercooldao.eth
  │     └── class        = "Officer"
  │     └── full-name    = "Bob Chen"
  │     └── title        = "Secretary"
  │
  └── registered-agent.supercooldao.eth
        └── class        = "Officer"
        └── full-name    = "Wyoming Registered Agents LLC"
        └── title        = "Registered Agent"
```

Each officer subnode resolves to an Ethereum address controlled by that individual. The organisation's ENS name — controlled by the DAO's governance process — is the authority asserting who holds each role.

### On-Chain Verification of Authority

This structure has a powerful consequence: the address assigned to an officer subnode can sign messages, and those signatures can be traced back to a named role in the organisation's legal structure.

If the address behind `ceo.mydao.eth` signs an on-chain statement, anyone can verify that the signer is the person the organisation has designated as its CEO. This creates a chain of attribution — from signature, to address, to subnode, to the organisation's ENS name — that is entirely on-chain and permissionlessly verifiable.

This is relevant anywhere official authority matters: signing governance proposals, authorising treasury disbursements, issuing public statements, or executing legal agreements on-chain. The subnode structure turns an ENS name into something closer to a corporate seal — a verifiable assertion of who is authorised to act on behalf of the entity.

### Discoverability

Regulatory disclosures are only useful if people can find them. Because the officer and registration subnodes are standard ENS records, they are discoverable using the same pattern as any other subnode:

1. Resolve the organisation's ENS name to find its subnodes.
2. For each subnode, read the `class` record to identify officers, registered agents, or other roles.
3. Read `full-name` and `title` for a human-readable summary of the corporate structure.
4. Resolve the subnode's address to find the Ethereum address associated with each role.

Governance dashboards, compliance tools, and legal registries could index this information automatically — providing a live view of an organisation's disclosed structure without relying on off-chain filings.

### 🚧 Open Questions 🚧

The `Person` schema currently supports `class`, `full-name`, and `title`. For full regulatory compliance, organisations may also need to publish details like jurisdiction of incorporation, registration numbers, office addresses, and filing dates. Whether these belong as additional fields on the organisation's root node, as dedicated subnodes, or as a new schema is an open question for the community.

There is also the question of privacy. Not all officer details are appropriate to publish on-chain. Some jurisdictions require public disclosure of certain roles but not others. How to balance regulatory transparency with individual privacy — and whether mechanisms like selective disclosure or encrypted records have a role — remains to be explored.

### Related

* [Organization schema](/schemas/org)
* [Person schema](/schemas/person)
* [Treasury & contract discovery](/use-cases/treasury-and-contracts)


## Treasury & Contract Discovery

### The Problem

On-chain organisations and DAOs typically operate across multiple treasury addresses, governance contracts, token contracts, and protocol deployments. But there is no authoritative place where an organisation publishes the full list of addresses it controls. Tracking down this information usually involves searching through forums posts or github repositories.

This creates two problems.

The first is discoverability. If you want to understand an organisation's on-chain footprint — as a community member, auditor, integrator, or governance tool — you have to piece it together from documentation sites, GitHub READMEs, forum posts, and block explorer searches. These sources go stale, disagree with each other, and cannot be verified against the organisation's on-chain identity.

The second is security. When there is no canonical source, scam contract addresses can circulate unchallenged. Someone posts a contract address in a governance forum or group chat and claims it belongs to the organisation — and there is no on-chain record to check it against. Phishing attacks that impersonate protocol contracts succeed in part because users have no simple way to verify whether an address is genuinely claimed by the organisation it purports to belong to.

### Proposed Solution

An organisation that owns an ENS name can publish its entire on-chain footprint as subnodes — one subnode per treasury or contract — each carrying structured metadata. The organisation's ENS name becomes the authoritative, on-chain index of everything it controls.

```
supercooldao.eth
  ├── treasury.supercooldao.eth
  │     └── class        = "Treasury"
  │     └── description  = "Primary DAO treasury managed by governance"
  │
  ├── hotwallet.supercooldao.eth
  │     └── class        = "Wallet"
  │     └── description  = "Hot wallet for the DAO"
  │
  └── governance.supercooldao.eth
        └── class        = "Contract"
        └── alias        = "Governance Contract"
        └── description  = "Governance contract for the DAO"
```

Each subnode address resolves to the actual on-chain contract or wallet. The parent ENS name provides the attestation: the organisation that controls `supercooldao.eth` is the one asserting these subnodes belong to it.

### Discoverability

Because ENS records are public and indexed, an organisation's on-chain footprint is discoverable without querying any external API or documentation site:

1. Resolve the organisation's ENS name to find its subnodes.
2. For each subnode, read the `class` record to determine whether it is a `Treasury`, `Contract`, or another type.
3. Resolve the subnode's address to get the on-chain address it points to.
4. Optionally read `description` and other entries for a human-readable summary.

This gives any consumer a live, permissionless view of every address the organisation has explicitly claimed.

### Security and Accountability

Publishing contract and treasury addresses under an organisation's ENS name creates a verifiable source of truth that serves both accountability and security.

For accountability, it creates a public commitment. An organisation that lists its treasury subnodes is on record as owning those addresses. Community members can verify that funds are flowing to and from the declared addresses, and surface discrepancies if they find assets in unlisted addresses. Omission becomes visible — if an address is being used for organisational purposes but does not appear as a subnode, that is itself a signal worth investigating.

For security, it gives users something to check against. When someone shares a contract address claiming it belongs to a protocol, anyone can resolve the protocol's ENS name and verify whether that address appears as a subnode. Wallets, governance UIs, and block explorers could surface this check automatically — flagging interactions with addresses that claim to belong to an organisation but are not listed under its ENS name.

### Related

* [Organization schema](/schemas/org)
* [Treasury schema](/schemas/treasury)
* [Contract schema](/schemas/contract)


## getMetadata

Gets metadata for specified ENS name.

Calls `resolve(bytes, bytes)` on ENS Universal Resolver Contract.

### Usage

:::code-group
```ts [example.ts]
import { normalize } from 'viem/ens'
import { client } from './client'



const schema = await client.getSchema({
  name: normalize('hypernets.eth')
})
const metadata = await client.getMetadata({
  name: normalize('hypernets.eth')
  schema // Optional
})

// =>  {
//   "class": "Orgnisation",
//   "schema: "CID",
//   "properties": {
//     "avatar: "value"
//   }
// }

const isValid = validate(schema, metadata)
=> True
```

```ts [client.ts]
import { createPublicClient, http } from 'viem'

import { mainnet } from 'viem/chains'

export const publicClient = createPublicClient({
  chain: mainnet,
  transport: http()
})
```
:::


## Agent

AI agent identity metadata aligned with ERC-8004 registration format.

### Attributes

| Key             | Type    | Recommended | Description                                 | Values |
| --------------- | ------- | ----------- | ------------------------------------------- | ------ |
| class           | string  | Y           | High-level identifier of this node type     | -      |
| agent-uri       | string  | Y           | URI to the ERC-8004 registration file       | -      |
| type            | string  | -           | Registration file type discriminator        | -      |
| name            | string  | -           | Agent display name                          | -      |
| description     | string  | -           | Natural-language description of the agent   | -      |
| services        | string  | -           | Advertised service endpoints                | -      |
| x402-support    | boolean | -           | Whether x402 payment flow is supported      | -      |
| active          | string  | -           | Whether the agent is currently active       | -      |
| registrations   | string  | -           | Cross-chain identity registrations          | -      |
| supported-trust | string  | -           | Trust models supported by the agent         | -      |
| agent-wallet    | string  | -           | Verified payout wallet for agent operations | -      |

### Metadata

* Schema ID: `agent`
* Latest version: `1.0.0`
* Source: [https://eips.ethereum.org/EIPS/eip-8004](https://eips.ethereum.org/EIPS/eip-8004)
* CID: `QmS1ZHmucPJCo8KGaBG2e27c6jqpjFrFWoZWoVPyBPqVyJ`
* Checksum: `sha256:6778eeaf90b71eb75c2a174f50062e8a5dbfcb62152e0ab905339a6da5e01e3b`
* Published at (UTC): `2026-02-18T13:13:22.000Z`

### Version history

| Version          | CID                                              | IPFS                                                                        | Published at (UTC)         |
| ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------- | -------------------------- |
| `1.0.0 (latest)` | `QmS1ZHmucPJCo8KGaBG2e27c6jqpjFrFWoZWoVPyBPqVyJ` | [Open](https://ipfs.io/ipfs/QmS1ZHmucPJCo8KGaBG2e27c6jqpjFrFWoZWoVPyBPqVyJ) | `2026-02-18T13:13:22.000Z` |


## Application

An application, service, or dApp within the organization.

### Attributes

| Key         | Type   | Recommended | Description                                                | Values                                   |
| ----------- | ------ | ----------- | ---------------------------------------------------------- | ---------------------------------------- |
| class       | string | Y           | High-level identifier of this node type                    | e.g. `Application`, `Service`, `Website` |
| name        | string | Y           | The name of the application                                | -                                        |
| description | string | Y           | Description of the application's purpose and functionality | -                                        |
| url         | string | Y           | URL where the application is hosted or accessed            | -                                        |
| repository  | string | -           | Source code repository URL                                 | -                                        |
| version     | string | -           | Current version of the application                         | -                                        |
| status      | string | Y           | Application status                                         | `Active`, `Development`, `Deprecated`    |

### Metadata

* Schema ID: `application`
* Latest version: `1.0.0`
* Source: [https://github.com/0xLighthouse/ens-node-metadata](https://github.com/0xLighthouse/ens-node-metadata)
* CID: `QmSsjRkk2xZSU6yXxjgPmyKpyfQVGmUw5qLGaPkYcdPW9A`
* Checksum: `sha256:79de7f6f9d48810193959754c27315a7558529d713a532d5c2566f3de2197819`
* Published at (UTC): `2026-02-18T13:17:52.000Z`

### Version history

| Version          | CID                                              | IPFS                                                                        | Published at (UTC)         |
| ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------- | -------------------------- |
| `1.0.0 (latest)` | `QmSsjRkk2xZSU6yXxjgPmyKpyfQVGmUw5qLGaPkYcdPW9A` | [Open](https://ipfs.io/ipfs/QmSsjRkk2xZSU6yXxjgPmyKpyfQVGmUw5qLGaPkYcdPW9A) | `2026-02-18T13:17:52.000Z` |


## Contract

Smart contract metadata profile following Enscribe smart contract metadata format.

### Attributes

| Key               | Type   | Recommended | Description                                                                    | Values |
| ----------------- | ------ | ----------- | ------------------------------------------------------------------------------ | ------ |
| class             | string | Y           | High-level identifier of this node type                                        | -      |
| alias             | string | Y           | Human-readable contract alias (ENSIP-18 alias)                                 | -      |
| description       | string | Y           | Short description of the contract purpose (ENSIP-18 description)               | -      |
| avatar            | string | -           | Avatar URI for the contract profile (ENSIP-12 avatar)                          | -      |
| category          | string | -           | Contract category (e.g., defi, gaming, dao, utility, proxy, factory)           | -      |
| license           | string | -           | Official software license identifier for the source code                       | -      |
| docs              | string | -           | Primary documentation URL for developers and users                             | -      |
| compiled-metadata | string | -           | A URI to a contract metadata file as generated by a Solidity or Vyper compiler | -      |
| audits            | json   | -           | JSON array of third-party audit reports                                        | -      |

### Metadata

* Schema ID: `contract`
* Latest version: `1.1.1`
* Source: [https://github.com/0xLighthouse/ens-node-metadata](https://github.com/0xLighthouse/ens-node-metadata)
* CID: `QmPq5xpj5LoCnAswuLk8ofgvpFLFNsRhJDPjvPVssCyPw1`
* Checksum: `sha256:ff0ef9190bc2e00e90ce30a7328187fdbe7bec54bf7945b17c25533685e6c014`
* Published at (UTC): `2026-02-18T13:17:58.000Z`

### Version history

| Version          | CID                                              | IPFS                                                                        | Published at (UTC)         |
| ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------- | -------------------------- |
| `1.1.1 (latest)` | `QmPq5xpj5LoCnAswuLk8ofgvpFLFNsRhJDPjvPVssCyPw1` | [Open](https://ipfs.io/ipfs/QmPq5xpj5LoCnAswuLk8ofgvpFLFNsRhJDPjvPVssCyPw1) | `2026-02-18T13:17:58.000Z` |


## Delegate

A delegate.

### Attributes

| Key                  | Type   | Recommended | Description                                                        | Values |
| -------------------- | ------ | ----------- | ------------------------------------------------------------------ | ------ |
| class                | string | Y           | High-level identifier of this node type                            | -      |
| address              | string | Y           | The address of the delegate                                        | -      |
| legal-name           | string | -           | The full legal or preferred name of the delegate (e.g. "John Doe") | -      |
| display-name         | string | Y           | A canonical display name for the delegate                          | -      |
| statement            | string | Y           | Generic delegate statement                                         | -      |
| conflict-of-interest | string | Y           | Generic conflict of interest declaration                           | -      |
| forum-handle         | string | Y           | Default forum handle (e.g. "johndoe")                              | -      |

### Metadata

* Schema ID: `delegate`
* Latest version: `1.0.1`
* Source: [https://github.com/0xLighthouse/ens-node-metadata](https://github.com/0xLighthouse/ens-node-metadata)
* CID: `QmcHmNS3NhcrMgXmCm72bv77EKUx7inoeaS2QeWDuQGU1q`
* Checksum: `sha256:4208b2eec2ddf8d4ded2df34999070a21779af793d3b09b95f0a5cede999adf7`
* Published at (UTC): `2026-02-18T16:50:06.000Z`

### Version history

| Version          | CID                                              | IPFS                                                                        | Published at (UTC)         |
| ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------- | -------------------------- |
| `1.0.1 (latest)` | `QmcHmNS3NhcrMgXmCm72bv77EKUx7inoeaS2QeWDuQGU1q` | [Open](https://ipfs.io/ipfs/QmcHmNS3NhcrMgXmCm72bv77EKUx7inoeaS2QeWDuQGU1q) | `2026-02-18T16:50:06.000Z` |
| `1.0.0`          | `QmaDG9p9vJjsLBtbtCPTd6tmfJUh2wuXmYQfNwrpe2qQwe` | [Open](https://ipfs.io/ipfs/QmaDG9p9vJjsLBtbtCPTd6tmfJUh2wuXmYQfNwrpe2qQwe) | `2026-02-18T13:18:03.000Z` |


## Globals

A collection of globally applicable ENS record schemas.

### ENSIP-5

A group of entities that have been empowered by a larger organization to undertake some activity.

Source: [https://docs.ens.domains/ensip/5](https://docs.ens.domains/ensip/5)

#### Attributes

| Key         | Type   | Recommended | Description                                                                                                                                                                                             | Values |
| ----------- | ------ | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ |
| avatar      | string | -           | A URL to an image used as an avatar or logo                                                                                                                                                             | -      |
| description | string | -           | A description of the name                                                                                                                                                                               | -      |
| display     | string | -           | A canonical display name for the ENS name; this MUST match the ENS name when its case is folded, and clients should ignore this value if it does not (e.g. "ricmoo.eth" could set this to "RicMoo.eth") | -      |
| email       | string | -           | An e-mail address                                                                                                                                                                                       | -      |
| keywords    | string | -           | A list of comma-separated keywords, ordered by most significant first; clients that interpresent this field may choose a threshold beyond which to ignore                                               | -      |
| mail        | string | -           | A physical mailing address                                                                                                                                                                              | -      |
| notice      | string | -           | A notice regarding this name                                                                                                                                                                            | -      |
| location    | string | -           | A generic location (e.g. "Toronto, Canada")                                                                                                                                                             | -      |
| phone       | string | -           | A phone number as an E.164 string                                                                                                                                                                       | -      |
| url         | string | -           | A website URL                                                                                                                                                                                           | -      |

### Metadata

* Schema ID: `globals`
* Latest version: `1.0.0`
* CID: `QmVPf3nP4KC12An7v94ziWLE3ptFHXwUxFcvKEaPNXGRYd`
* Checksum: `sha256:128951c9c9c6e91ee0a07b36058180a2881dc0bf33e6216b9d89fb1288e7a27c`
* Published at (UTC): `2026-02-18T13:33:27.000Z`

### Version history

| Version          | CID                                              | IPFS                                                                        | Published at (UTC)         |
| ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------- | -------------------------- |
| `1.0.0 (latest)` | `QmVPf3nP4KC12An7v94ziWLE3ptFHXwUxFcvKEaPNXGRYd` | [Open](https://ipfs.io/ipfs/QmVPf3nP4KC12An7v94ziWLE3ptFHXwUxFcvKEaPNXGRYd) | `2026-02-18T13:33:27.000Z` |


## Grant

A grant issued by an organization.

### Attributes

| Key         | Type   | Recommended | Description                                                                              | Values                                                      |
| ----------- | ------ | ----------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| class       | string | Y           | High-level identifier of this node type                                                  | e.g. `Grant`, `GrantProgram`                                |
| name        | string | Y           | The name of the grant program                                                            | -                                                           |
| description | string | Y           | Description of the grant purpose and scope                                               | -                                                           |
| url         | string | Y           | URL of the grant program                                                                 | -                                                           |
| status      | string | Y           | Grant status                                                                             | `Active`, `Incomplete`, `Pending`, `Completed`, `Cancelled` |
| budget      | string | Y           | Total budget expressed as WEI eg. 100 USDC = 100 \* 10^6                                 | -                                                           |
| token       | string | Y           | Token expressed as ERC-20 token address eg. "0x0000000000000000000000000000000000000000" | -                                                           |

### Metadata

* Schema ID: `grant`
* Latest version: `1.0.0`
* Source: [https://github.com/0xLighthouse/ens-node-metadata](https://github.com/0xLighthouse/ens-node-metadata)
* CID: `QmdktToaxwvN31DGDEtWQ7uVKNURssW5k8oCtgceTFHemS`
* Checksum: `sha256:205ff736e4ce769bbc86332aedf56fe55275154ffcfda4d2c5003bc809ca4df4`
* Published at (UTC): `2026-02-18T13:18:08.000Z`

### Version history

| Version          | CID                                              | IPFS                                                                        | Published at (UTC)         |
| ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------- | -------------------------- |
| `1.0.0 (latest)` | `QmdktToaxwvN31DGDEtWQ7uVKNURssW5k8oCtgceTFHemS` | [Open](https://ipfs.io/ipfs/QmdktToaxwvN31DGDEtWQ7uVKNURssW5k8oCtgceTFHemS) | `2026-02-18T13:18:08.000Z` |


## Group

This node describes a group of individuals or entities with a shared purpose or responsibility.

### Attributes

| Key           | Type   | Recommended | Description                                 | Values                                                    |
| ------------- | ------ | ----------- | ------------------------------------------- | --------------------------------------------------------- |
| class         | string | Y           | High-level identifier of this node type     | e.g. `Group`, `Committee`, `Council`, `Workgroup`, `Team` |
| name          | string | Y           | The name of the group                       | -                                                         |
| avatar        | string | Y           | A URL to an image used as an avatar or logo | -                                                         |
| description   | string | Y           | A description of the name                   | -                                                         |
| url           | string | Y           | URL of the group                            | -                                                         |
| lead          | string | Y           | ENS name or address of the group leader     | -                                                         |
| lead-title    | string | -           | Title or role of the group leader           | e.g. `Lead Steward`, `Chair`, `Manager`, `Owner`          |
| members-title | string | -           | Title or role of the group members          | e.g. `Member`, `Steward`, `Contributor`, `Participant`    |

### Metadata

* Schema ID: `group`
* Latest version: `0.1.4`
* Source: [https://github.com/0xLighthouse/ens-node-metadata](https://github.com/0xLighthouse/ens-node-metadata)
* CID: `QmYJieM3KXTeDhrwcFr3cMSi1LVWofxjCVkMzv1HTuoYSw`
* Checksum: `sha256:ca4434bed698d565b4a5d24bf98c658dc3e6fa381c48f66cd49744fde1b47559`
* Published at (UTC): `2026-02-18T13:18:14.000Z`

### Version history

| Version          | CID                                              | IPFS                                                                        | Published at (UTC)         |
| ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------- | -------------------------- |
| `0.1.4 (latest)` | `QmYJieM3KXTeDhrwcFr3cMSi1LVWofxjCVkMzv1HTuoYSw` | [Open](https://ipfs.io/ipfs/QmYJieM3KXTeDhrwcFr3cMSi1LVWofxjCVkMzv1HTuoYSw) | `2026-02-18T13:18:14.000Z` |


## Organization

A legal or organizational entity.

### Attributes

| Key         | Type   | Recommended | Description                                 | Values                                    |
| ----------- | ------ | ----------- | ------------------------------------------- | ----------------------------------------- |
| class       | string | Y           | High-level identifier of this node type     | e.g. `Organization`, `Foundation`, `OPCo` |
| name        | string | Y           | The name of this business unit              | -                                         |
| avatar      | string | Y           | A URL to an image used as an avatar or logo | -                                         |
| description | string | Y           | A description of the name                   | -                                         |
| url         | string | Y           | URL of the organization                     | -                                         |

### Metadata

* Schema ID: `org`
* Latest version: `0.1.8`
* Source: [https://github.com/0xLighthouse/ens-node-metadata](https://github.com/0xLighthouse/ens-node-metadata)
* CID: `QmfPD2L38hREq356GxhMkyMJMECVwRAxm6dEJZh3bpPAdd`
* Checksum: `sha256:07522b2427846867ffd3a69c1955d08ec0d9a88a3da6d5a0efd5ec94ae103f2a`
* Published at (UTC): `2026-02-18T13:18:19.000Z`

### Version history

| Version          | CID                                              | IPFS                                                                        | Published at (UTC)         |
| ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------- | -------------------------- |
| `0.1.8 (latest)` | `QmfPD2L38hREq356GxhMkyMJMECVwRAxm6dEJZh3bpPAdd` | [Open](https://ipfs.io/ipfs/QmfPD2L38hREq356GxhMkyMJMECVwRAxm6dEJZh3bpPAdd) | `2026-02-18T13:18:19.000Z` |


## Person

A person.

### Attributes

| Key       | Type   | Recommended | Description                             | Values                                                               |
| --------- | ------ | ----------- | --------------------------------------- | -------------------------------------------------------------------- |
| class     | string | -           | High-level identifier of this node type | e.g. `Person`, `Human`, `Signer`, `Officer`, `Employee`, `Secretary` |
| full-name | string | -           | Full legal or preferred name            | -                                                                    |
| title     | string | -           | Title within the organization, if any   | -                                                                    |

### Metadata

* Schema ID: `person`
* Latest version: `1.0.0`
* Source: [https://github.com/0xLighthouse/ens-node-metadata](https://github.com/0xLighthouse/ens-node-metadata)
* CID: `QmYZNmUKP751Vfj2ZEVwXawvGto1zsmi4oiTsnunzx6dsp`
* Checksum: `sha256:c40c06eff4eae205f64a70eb8ab2bb639e6ec7a62aeceeab7d7ae5eaf9959760`
* Published at (UTC): `2026-02-18T13:18:24.000Z`

### Version history

| Version          | CID                                              | IPFS                                                                        | Published at (UTC)         |
| ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------- | -------------------------- |
| `1.0.0 (latest)` | `QmYZNmUKP751Vfj2ZEVwXawvGto1zsmi4oiTsnunzx6dsp` | [Open](https://ipfs.io/ipfs/QmYZNmUKP751Vfj2ZEVwXawvGto1zsmi4oiTsnunzx6dsp) | `2026-02-18T13:18:24.000Z` |


## Treasury

Funds and assets managed by a collective of individuals or entities.

### Attributes

| Key         | Type   | Recommended | Description                             | Values                   |
| ----------- | ------ | ----------- | --------------------------------------- | ------------------------ |
| class       | string | Y           | High-level identifier of this node type | e.g. `Treasury`, `Vault` |
| name        | string | Y           | The name of the treasury                | -                        |
| description | string | Y           | A description of the name               | -                        |

### Metadata

* Schema ID: `treasury`
* Latest version: `1.0.0`
* Source: [https://github.com/0xLighthouse/ens-node-metadata](https://github.com/0xLighthouse/ens-node-metadata)
* CID: `QmcrTCuN3FmpTP66LzQqDtaxmK7j5wMNtHKQEjE2SCLUZr`
* Checksum: `sha256:bd72ed65798aa3db260b2fa04c75263df19b06bff9dfbad540921d82c41a76a3`
* Published at (UTC): `2026-02-18T13:18:28.000Z`

### Version history

| Version          | CID                                              | IPFS                                                                        | Published at (UTC)         |
| ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------- | -------------------------- |
| `1.0.0 (latest)` | `QmcrTCuN3FmpTP66LzQqDtaxmK7j5wMNtHKQEjE2SCLUZr` | [Open](https://ipfs.io/ipfs/QmcrTCuN3FmpTP66LzQqDtaxmK7j5wMNtHKQEjE2SCLUZr) | `2026-02-18T13:18:28.000Z` |


## Wallet

A wallet for holding or managing assets.

### Attributes

| Key         | Type   | Recommended | Description                             | Values                   |
| ----------- | ------ | ----------- | --------------------------------------- | ------------------------ |
| class       | string | Y           | High-level identifier of this node type | e.g. `Wallet`, `Account` |
| description | string | Y           | Indicates the purpose of the wallet     | -                        |

### Metadata

* Schema ID: `wallet`
* Latest version: `1.0.0`
* Source: [https://github.com/0xLighthouse/ens-node-metadata](https://github.com/0xLighthouse/ens-node-metadata)
* CID: `QmTdnHbDob1Cf7Uy1dYmrRezyETvf19QWcaNpFP3WSe2JD`
* Checksum: `sha256:1a6fadb35c51e238e7ddb947b1ac6b9e899df71247f0eb85c7724092fd075988`
* Published at (UTC): `2026-02-18T13:18:32.000Z`

### Version history

| Version          | CID                                              | IPFS                                                                        | Published at (UTC)         |
| ---------------- | ------------------------------------------------ | --------------------------------------------------------------------------- | -------------------------- |
| `1.0.0 (latest)` | `QmTdnHbDob1Cf7Uy1dYmrRezyETvf19QWcaNpFP3WSe2JD` | [Open](https://ipfs.io/ipfs/QmTdnHbDob1Cf7Uy1dYmrRezyETvf19QWcaNpFP3WSe2JD) | `2026-02-18T13:18:32.000Z` |


*Updated: 2026-02-19*

## ENSIP-X: Node Classification Metadata

### Abstract

This ENSIP proposes a standard method for using text records to declare the role of an ENS name/subname (node). Two types of standardized text records are introduced, which provide for labeling the role of node against a larger organizational structure, and for defining the structure of additional, context-dependent attributes that may be appended to that node.

### Motivation

In practice, ENS subnames are often used to represent organizational structures. For example, an ENS name belonging to an individual might have a subname which points to the individual's cold wallet, and another which points to a hot wallet that they use for voting in on-chain governance. DAOs or other on-chain organizations might have a top-level ENS name that represents the group as a whole, with subnames created to represent treasuries, smart contracts, working groups, committees, and other entities within the organization. This ENSIP offers a way to add metadata to each of those nodes to declare its role in the larger organizational structure, and to append context-specific metadata which is machine-readable and standardized, allowing dynamic discovery and recognition of the role each subname is meant to fulfill.

### Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

#### Metadata Records

This ENSIP builds on ENSIP-5 and ENSIP-24, and uses text records stored in each node's resolver to provide additional metadata for that node. We define two new unqualified, global key names (`class` and `schema`) which are hereby reserved for use in accordance with this ENSIP. Additional metadata attributes can also be added to a node and stored as text or data records, with their key names declared by the `schema` entry (explained below).

It is expected that each node will be configured to resolve to one or more on-chain addresses, and the metadata attributes attached to a node are understood to apply to the entity or entities represented by those addresses.

#### `class` Text Record

Nodes can specify a text record with the key name of `class`, the value of which serves to label the general role or purpose of that node. These values are largely intended to be useful to humans who wish to understand what importance to give to each node, but can also be used programmatically in filtering and recognizing categories of node for automated systems.

The value of this record MUST be pascal case, using only alphabet characters. Values SHOULD be limited to those outlined in the following table to maximize compatability across the ecosystem, however other values MAY be used for specialized use cases.

| `class` Value | Meaning                                                                                                                    |
| ------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Agent         | This node represents an autonomous software-controlled entity                                                              |
| Application   | This node represents a software application, service, or product                                                           |
| Committee     | This node represents a formal group with delegated authority to make decisions or provide oversight within a defined scope |
| Contract      | This node represents, and resolves to, a smart contract                                                                    |
| Council       | This node represents a high-level governance body with broad strategic authority and stewardship responsibilities          |
| Delegate      | This node represents a voter in on-chain governance, who may or may not have been delegated voting power from others       |
| Group         | This node represents a logical grouping of multiple child nodes                                                            |
| Org           | This node represents an organization or sub-organization within a larger entity                                            |
| Person        | This node represents an individual human                                                                                   |
| Treasury      | This node represents an account for funds that are collectively owned and/or managed                                       |
| Wallet        | This node's main purpose is to send, receive, and/or store funds                                                           |
| Workgroup     | This node represents an operational team focused on executing tasks or work within a specific domain                       |

It is understood that all on-chain addresses could have the ability to perform a base set of actions, including:

* sending and receiving funds
* calling smart contracts
* publishing new smart contracts
* providing signatures

Therefore, `class` designations like `contract` and `wallet` should only be interpreted as declaring that node's main purpose in the context of the organizational structure; nodes that do not use one of these classes can still point to addresses which are smart contracts and/or hold funds. The same address can be pointed to by multiple nodes, each with a different `class` designation and metadata describing a different aspect of that address/account.

#### `schema` Text Record

Nodes can specify a text record with the key name of `schema`, the value of which points to a JSON schema which declares which metadata attributes can be added to the node as text or data records, in addition to the global text records already specified in existing ENSIPs. The value of `schema` MUST start with one of the following prefixes, followed by the appropriate value:

* `ipfs://` - followed by the ipfs URI pointing to the JSON payload
* `https://` - followed by the http(s) URI pointing to the JSON payload
* `cbor:` - followed by the schema encoded in CBOR format

#### Schema Payload

If a schema is provided for a node, it specifies which additional metadata attributes are expected to be provided for that node, stored as text or data records. Schemas MUST follow the JSON Schema specification, [version 2020-12](https://json-schema.org/draft/2020-12/json-schema-core), and describe a single-level object in which property names match the text or data record key names. Attribute key names MUST use camel case.

Clients that facilitate storing metadata records SHOULD reject values that fail validation according to the provided schema.

Clients that facilitate retrieving metadata records MAY ignore values that fail validation according to the provided schema.

##### Additional details

* The schema's `$id` field SHOULD be used to identify the schema's creator and/or version.
* The schema's `title` field identifies what entity is described in the data structure. If the schema is intended to be used with a specific `class`, the value of `title` SHOULD be the same as the class it is meant to represent.
* If a node has a `schema` present but no `class` record set, the value of the schema's `title` SHOULD be used as the class identifier for the node.
* Schema authors are encouraged to populate the `description` field with an explanation of the organizational role fulfilled by nodes which use this schema, in line with the `class` descriptions listed above.
* Schemas MAY include definitions for key names which are declared as global in other ENSIPs, however if present, the descriptions of these keys MUST NOT be in direct conflict of their original definition provided by existing ENSIPs.
* Attributes can include an optional `recordType` ("text" | "data") keyword which indicates if the record is stored as `text` (ENSIP-5) or `data` (ENSIP-24) (default: `text`)

##### Basic schema example

```
{
  "$id": "v1.0",
  "title": "Person",
  "description": "This node represents an individual human",
  "type": "object",
  "properties": {
    "firstName": {
      "type": "string",
      "description": "The person's first name.",
    },
    "lastName": {
      "type": "string",
      "description": "The person's last name."
    },
    "proofOfHumanity": {
      "type": "string",
      "description": "A signed attestation of proof of humanity.",
      "recordType": "data"
    },
    "avatar": {
      "type": "string",
      "description": "a URL to an image used as an avatar or logo"
    }
  }
}
```

##### Parameterized Key Names

Schemas can support parameterized properties, which allow a single property to have multiple variant-specific values. Parameters are specified using bracket notation appended to the property when used as a key name:

```
keyName[parameter]
```

Schemas MAY simultaneously support both the base form (`keyName`) and parameterized form (`keyName[parameter]`). The parameterized form with empty brackets (`keyName[]`) SHALL NOT be allowed.

When both base and parameterized forms exist, clients SHOULD treat them as independent records, with the base form serving as a default when no specific parameter is requested.

To add a parameterized key to a JSON schema, add a regex pattern which enforces the use of brackets to the `patternProperties` object. The following example regex value will accept either the base form or the parameterized form, while rejected empty brackets: `^keyName(\[[^\]]+\])?$`

When parsing key names, the following regex can be used to isolate the base form (group 1) and the parameter (group 3, if provided): `^(keyName)(\[([^\]]+)\])?$`

**Note:** Defining which values are allowed to be passed inside of the brackets when setting and retrieving records is up to schema publishers and is outside the scope of this ENSIP.

##### Basic schema example including parameterized properties

```
{
  "$id": "v1.0",
  "title": "Person",
  "description": "This node represents an individual human",
  "type": "object",
  "properties": {
    "firstName": {
      "type": "string",
      "description": "The person's first name.",
    },
    "lastName": {
      "type": "string",
      "description": "The person's last name."
    },
    "avatar": {
      "type": "string",
      "description": "a URL to an image used as an avatar or logo"
    }
  },
  "patternProperties": {
    "^proofOfHumanity(\[[^\]]+\])?$": {
      "type": "string",
      "description": "A signed proof of humanity attestation. The name of a specific provider can be passed as a parameter.",
      "recordType": "data"
    }
  }
}
```

In this example, the owner of the node could use the key `proofOfHumanity[provider]` to store a proof of humanity attestation from a specific provider, and they could use `proofOfHumanity` to publish a default attestation to be retrieved if no provider is specified.

### Backwards Compatibility

This proposal is built upon existing ENSIPs and does not affect existing ENS functionality. It introduces no breaking changes.

### Security Considerations

None.

### Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).


## Resources

* View the [draft ENSIP](https://github.com/ensdomains/ensips/pull/64) to provide feedback

* Read the working group [Wiki](https://stealth-respect-4e8.notion.site/Organizational-Metadata-on-ENS-2313a8375c77801dad2ce5b513ce9450?pvs=74) to join meetins and workshops.

* Join our public [Telegram](https://t.me/+wh4CCm74pr04NGZk)

* Explore the [metadata manager](https://ens-metadata-interface.vercel.app/) to start classifying your subnames.


## Schemas

The node classification metadata spec dictates how JSON schemas can be appended to an ENS name (or subname) to expose which additional metadata attributes are expected to be provided for that node. It is expected that a popular, standardized set of schemas will become widely used, which will improve cross-compatibility across the industry, however anyone is free to create additional JSON schemas to facilitate attaching whatever metadata serves their purpose best.

In the section below, you can find our collection of proposed schemas which we hope the industry will use and build upon. All of these schemas are still a work in progress, and we are open to feedback and suggestions.

Our schemas are all published to IPFS to ensure immutability and availability for the long term. They also include an EIP-712 signature to provide proof of authorship.

### Schema Categories

Each schema is named for the `class` of node it is expected to be used with. We have also included a `globals` schema which includes text records defined by other ENSIPs.