# Representing organizations on ENS

**Author:** 1a35e1.eth <[e-mail]>
**WG Coordinator:** jkm.eth <[e-mail]>
**Version:** 0.5.0-draft
**Date:** 9 June 2025
**ENSIP-X**: Representing organizations on ENS

---

## Background

At [Lighthouse](https://lighthouse.cx/), we surface DAO metadata from multiple systems to help users vote more effectively on mobile. Currently, much of this data (including contract addresses and delegate information) requires manual discovery and ingestion.

We would prefer to source and present this data from an official, public canonical source such as ENS, rather than relying on manual updates.

## Introduction

This RFC outlines a standard for DAOs to write metadata to ENS in a canonical manner, building on historical attempts in the ecosystem.

ENS innovations like subnames, CCIP-Read, wildcard domains, and the upcoming Namechain L2 provide the components for a global, trustless, and crawlable graph of organizational data. We propose a minimal, flexible schema that can:

* Model DAO structures, including delegates, working groups, and treasuries.
* Store structured DAO metadata via ENS text records.
* Facilitate discovery of DAO-related information.
* Support fine-grained attributes that can be resolved from diverse off-chain vendors.

## Approach

ENS is uniquely positioned to become the canonical source of truth for organization metadata across EVM-aligned blockchains.

Already established as the leader in on-chain identity, a natural evolution is to explore how ENS’s architecture could be leveraged for organizations at scale.

Key considerations include:

> *Hierarchical registry*

ENS’s support for subnames means subgroups of a DAO can be organized under a single root. This hierarchical naming allows for straightforward traversal of the DAO’s structure from a known root domain. Subnames with well-defined namespace labels (e.g., "delegate", "wg") encode an organizational structure that is easily discoverable and portable.

> *Data storage and formats*

ENS text records provide a verified on-chain source of truth for metadata. These records can also serve as organization-approved anchors to off-chain data sources (via content URIs), adding portability and trustworthiness to the data.

By standardizing the keys and formats of these text records, DAOs can ensure their data is widely consumable.

> *Permissions*

Subname management and resolver controls give DAOs full control over access and schema evolution.

There’s no need for custom admin logic for maintaining a registry when using ENS; existing tools like Safe multisigs or role-based systems like Hats can be used to manage name ownership and updates.

This approach aligns with typical on-chain governance practices (e.g. a DAO-controlled multisig updating ENS records after a governance proposal passes).

> *Tooling (SDKs / CLIs)*

By leaning on existing infrastructure, developers and integrators can leverage standard ENS libraries (such as ensjs or viem) to read and write DAO registry data. There is also a rich design space for extending functionality via off-chain resolvers, which can be used to fetch complex or voluminous data on demand without bloating on-chain storage.

## Specification

### Schema declaration

To trustlessly opt in to this standard, an organization sets a `dao.registry.schema` TXT record on its root ENS name. The value of this record is a URI (e.g. HTTP(S) link or IPFS CID) pointing to a JSON schema file that defines the structure of the DAO’s ENS records. This schema informs indexers how to traverse and interpret all related records.

ens.eth
└── [dao.registry.schema]: "https://ens.xyz/ensipx/0.1.4/schema.json"

Benefits:
* **Opt-in and Evolvable**: Organizations can choose to opt in and easily adopt evolving standards by updating the schema reference. If an organization wishes to deviate from a standard spec, it can fork or modify the schema and declare it in this record.
* **Interoperable Parsing**: Downstream consumers (indexers, UIs, wallets) can parse the DAO’s ENS records according to the declared schema. Even if a schema is forked, as long as it remains compliant with the base structure, it softens the burden on indexers by retaining familiar patterns.

### Top-level metadata

The root ENS name stores key metadata about the DAO as ENS text records. For example, a DAO might set the following records on its root name (the exact keys and schema are to be determined):

ens.eth
├── [dao.name]: "ENS DAO"
├── [dao.description]: "Ethereum Name Service"
├── [dao.website]: "https://ens.domains"
├── [dao.logo]: "ipfs://Qm.../ens-logo.png"
│ 
├── [contracts]: "JSON TYPED ARRAY"
│
├── [governance]: "JSON TYPED ARRAY"
│
├── [dao.registry.schema]: "https://host/schemas/0.1.4/schema.json"
└── [dao.registry.updated]: "2025-06-13T10:00:00Z"

In this layout:
* `dao.name`, `dao.description`, `dao.website`, `dao.logo` provide human-readable basic info.
* `contracts` and `governance` can serialise typed JSON definitions.
* `dao.registry.schema` ensures the schema is discoverable as part of the metadata, and `dao.registry.updated` is a convenience entry containing the timestamp of the last update to the registry data.

### Subname Namespace design

Subnames are used to categorize groups and accounts within the DAO’s ENS namespace. By convention, specific prefixes (namespaces) designate different categories. For example, a DAO might use a prefix like `wg` for working groups and `delegate` for delegates:

ens.eth
├── wg.ens.eth            (working groups category)
|    ├── public-goods.wg.ens.eth     (a specific working group)
|    └── retro-funding.wg.ens.eth    (another working group)
|
└── delegate.ens.eth      (delegates category)
     ├── alice.delegate.ens.eth     (delegate account for Alice)
     └── bob.delegate.ens.eth       (delegate account for Bob)

In this example, `wg.ens.eth` is a subname that serves as a container for working groups, and `delegate.ens.eth` is a container for delegate entries. The prefixes (`wg`, `delegate`, etc.) are reserved to represent those categories in a structured way.

This naming convention allows programmatic discovery: an indexer could fetch all subnames under ens.eth and immediately distinguish categories by these prefixes.

### Validation

The JSON schema referenced in `dao.registry.schema` dictates which ENS TXT record keys are valid and what formats their values should have. In other words, it acts as the contract for what data the DAO is expected to provide and how.

For example, if the schema defines `dao.name` as a simple string, then setting `dao.name` to a HTTP URI (like "https://...") would be invalid according to the spec.

The schema can also define reserved keywords and patterns for names and keys. For instance, the spec might reserve certain prefixes so that any subname matching `*.(wg|council|group|committee).<root>.eth` is recognized as a group category.

### Delegates

A subname can represent a delegate or any role-bearing individual in the organization. The DAO can create a delegate subname and set the delegate’s EOA (Externally Owned Account) as the manager/controller of that subname. This allows the delegate themselves to maintain their metadata (profile, statement, status, etc.) within the DAO’s namespace.

The delegate’s subname would contain TXT records following a standard format for delegate information. For example:

ens.eth
└── alice.delegate.ens.eth
     # Optional fields:
     ├── forum.username: "AliceInSpace"
     ├── delegate.profile: "alice.eth"         (e.g. ENS name or profile link)
     ├── delegate.metrics: "https://example.com/delegates/alice"  (off-chain stats)
     # Required fields:
     ├── delegate.name: "Alice Wonderland"
     ├── delegate.status: "active"
     ├── delegate.of: "ens.eth, uniswap.eth"   (DAOs this person represents)
     ├── delegate.groups: "wg.meta.ens.eth"    (groups this delegate is part of)
     └── delegate.statement: "ipfs://Qm...Baz" (IPFS hash of delegate statement)

In the above example, `alice.delegate.ens.eth` is a delegate entry. Alice could directly update her own delegate profile since she is the controller of that subname.

The `delegate.of` field indicates the DAOs that Alice is a delegate for (self reported), and delegate.groups might list any internal groups or committees she is part of within that DAO.

All subnames under `*.delegate.ens.eth` would be expected to follow this schema for delegates.

## Ecosystem unlocks

Adopting a shared ENS-based registry for DAO metadata unlocks several ecosystem benefits:

### Attestations

DAOs that conform to this spec can be badged or highlighted in user interfaces as “*verified*” or "*compliant*", enhancing their credibility.

Furthermore, third parties (reputation services or standards bodies) could issue on-chain attestations that a DAO’s registry setup adheres to the standard. This can build trust with users that the DAO’s data is reliable and structured.

### Delegate discovery

Using this registry, it becomes easier to discover which DAOs a given address or individual is involved in. For example, if we want to find all DAOs where `charlie.eth` is a delegate, a tool could search for ENS subnames controlled by charlie.eth’s address. If charlie.eth is set as the manager of charlie.delegate.uniswap.eth and charlie.delegate.1inch.eth, one can infer Charlie is a delegate in Uniswap and 1inch DAOs just by traversing ENS records:

charlie.eth
├── charlie.delegate.uniswap.eth
│    ├── delegate.statement: "Uniswap is the best AMM!"
│    └── delegate.status: "active"
└── charlie.delegate.1inch.eth
     ├── delegate.statement: "1inch is the best aggregator!"
     └── delegate.status: "active"

This cross-DAO view of participation is enabled by the common naming scheme and the ability to search ENS for subdomains by manager address.

### Accounting

DAOs may opt in to disclose associated treasury addresses or assets using this schema.

For example, a DAO could list treasury or multisig addresses under a known key (like treasury.*.eth subnames or a [dao.treasury] record). This would enable easier programmatic aggregation of a DAO’s on-chain assets for reporting and analytics.

### Monetized Data Feeds (Micropayments)

Offchain reads combined with emerging standards like [x402](https://www.x402.org/) (an HTTP 402-based micropayment protocol for web APIs) presents a way to monetize data retrieval.

DAOs could delegate authority to trusted data providers who serve complex data (e.g. historical voting records or analytics). These providers might charge a small fee per query (using the x402 model). Because the ENS record points to the provider's URI, the entire flow can be automated: wallets or applications retrieve the TXT record, follow the URI, receive a “402 Payment Required” response, pay the fee, and get the data — all in a seamless, trust-minimized manner.

### Federation

This architecture is vendor-agnostic. Unlike relying on one monolithic subgraph or a single API, a DAO can choose different providers for different data types and simply update the ENS records to point accordingly. All data pointers still live under the DAO’s ENS domain, ensuring users and apps have a unified namespace to query.

Some implications of this model:

* **Specialized Data Providers**: Niche providers can serve domain-specific information (for example, a service that specializes in treasury portfolio analytics or governance proposal history). They can offer data for free or monetize it (using the x402 pay-per-use standard) depending on the DAO’s preference.
* **Trustless Routing**: Since the DAO controls the ENS record pointing to a provider, users can trust that a query is being directed to a source endorsed by the DAO. Service providers can facilitate the requests, ensuring accountability and aligning with DAO funding (e.g., if a DAO wants to subsidize certain data queries for its users).

Those familiar with GraphQL federation understand the how this solves fragmentation at scale.

## Ease of use

To make managing these records practical at scale, we propose using a set of proxy contracts or specialized resolvers to optimize updates. This would allow batching multiple ENS record updates in one transaction (saving gas) and ensure that all updates conform to the spec’s rules.

For example, a DAO could have a custom resolver contract that enforces the schema (rejecting invalid records) and groups writes so that a complex update (like rotating a delegate and updating their info across several fields) happens atomically. This approach guarantees consistency in a complex multi-part update and can integrate with existing DAO frameworks (e.g., the resolver only allows the DAO’s multisig or governance contract to execute certain updates).

## Impact

If widely adopted, this ENS-based DAO registry could have significant impact:

* **Interoperable**: Many voting and governance platforms (Lighthouse, Agora, Tally, Snapshot, etc.) could read from and write to a common ENS-based registry. This means a delegate’s profile or a DAO’s info updated via one interface would instantly be available to all others, reducing fragmentation.

* **Discoverable**: Information is stored on ENS, which is publicly accessible and indexable. Any interface or user can discover a DAO’s structure and key info by querying the ENS name, without needing to find documentation or APIs for that DAO.

* **Low Cost**: DAOs only need to write data once to ENS (which is relatively cheap, especially with text records on L2 or via Namewrapper). Consumers can then query this data as needed, caching it or indexing it, without imposing additional costs on the DAO for each query (beyond optional vendor fees).

* **Discoverable**: Any interfaces (not restricated to voting) have a cannonical source of truth information.

* **Flexible Permissioning**: The model works for both closed and open contribution. A DAO can restrict who can create or edit subnames (for example, only the DAO multisig can add new delegates), or it can allow self-service registration with controlled permissions (using ENS Namewrapper features like fuses to allow self-subdomains). Each DAO chooses its desired level of decentralization in managing the data.

* **Upgradable and Extensible**: Because this relies on ENS Namewrapper and resolvers, DAOs can upgrade their setup over time. Namewrapper allows features like revocable subdomains, expiring records, and versioned data schemas. If the standard evolves or a DAO’s needs change, they can introduce a new schema version and update the dao.registry.schema record to signal the changes.

## Moonshots

Looking ahead, a few aspirational ideas could further enhance this system:

* **zkTLS for Offchain-Reads**: Explore using zkTLS (zero-knowledge proofs for TLS) to verify off-chain data. This could provide cryptographic guarantees that the data from an HTTPS endpoint is authentic and untampered, without relying entirely on trust in the data provider.
* **schema evolution**:
* `[dao.announcements]` pointer to official announcements stream
* `[*.calendar]`, pointer to open calendar

## Next Steps

- Finalize schema and required/reserved fields
- Create ENSIP proposal draft
- Implement reference registry and resolver contracts
- Deploy to testnets with sample DAOs (ENS, Gitcoin, Optimism)
- Build open-source CLI to browse and introspect structure

$ ens inspect ens.eth --format=tree
=> 🔗 Canonical ENS: ens.eth
🏛  Working Groups:
├── metagov.ens.eth
│   ├── lead: 0x8f...12b
│   ├── text[charter]: https://gov.ens.domains/t/metagov-charter
│   └── budget: $320,000 USDC (vesting: 6mo)
├── publicgoods.ens.eth
│   ├── lead: 0xd1...77a
│   ├── text[charter]: CCIP → https://api.ensdao.eth/ccip/publicgoods
│   └── budget: $200,000 USDC
├── ecosystem.ens.eth
│   └── notes: “Merged with publicgoods in 2025”

🎙  Delegates (delegate.of=ens.eth)
├── alice.eth (0xabc...123)
│   ├── votingPower: 12,500 ENS
│   └── text[profile]: https://delegate.xyz/alice
├── bob.eth (0xdef...456)
│   └── votingPower: 4,800 ENS

💰 Treasury
├── contracts:
│   ├── main: 0x1234...beef (Safe)
│   ├── vesting: 0xbeef...cafe (LinearVesting)
├── totalAssets: 1.8M USDC + 120k ENS

$ ensdao inspect ens.eth --format=json
=> {
  "canonical": "ens.eth",
  "structure": {
    "groups": {
      "metagov.ens.eth": {
        "lead": "0x8f...12b",
        "mandate": "0x8f...12b"           
      },
      "publicgoods.ens.eth": {
        "lead": "0x8f...12b",
        "mandate": "0x8f...12b"
      },
      "ecosystem.ens.eth": {
        "notes": "Merged with publicgoods in 2025"
      }
    },
    "delegates": [      
      {
        "name": "bob.eth",
        "address": "0xdef...456",
        "votingPower": 4800,
        "delegateOf": "ens.eth"
      }
      ...
    ],
    "treasury": {
      "contracts": {
        "main": {
          "type": "Safe",
          "address": "0x1234...beef"
        },
        "vesting": {
          "type": "LinearVesting",
          "address": "0xbeef...cafe"
        }
      },
      "totalAssets": {
        "USDC": 1800000,
        "ENS": 120000
      }
    }
  },
  "metadata": {
    "fetchedAt": "2025-06-19T10:00:00Z",
    "signature": "0x...",
    "version": "v0.4.0-draft"
  }
}

## Appendix

### References

* CCIP spec, https://eips.ethereum.org/EIPS/eip-3668#use-of-ccip-read-for-transactions
* Offchain meta resolution discussions
* https://discuss.ens.domains/t/draft-ensip-off-chain-name-meta-resolution/17019/8
* https://discuss.ens.domains/t/ensip-supersession-resolver-implementations-and-client-integrations/19771
* https://discuss.ens.domains/t/ensip-16-v2-metadata-api-improvements/19500

### Previous progress

Related themes from options that have been explored in the past. The Final Approach lists what has been deployed thus far. Sources listed below.

| Theme | Options Explored | Final Approach |
|--------------------------|----------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------|
| Registry Architecture | Global registry, per-chain, per-DAO | Per-DAO deployment; frontends support selected chains |
| Data Storage | All on-chain, hybrid (on-chain + IPFS), off-chain (GitHub, Ceramic) | Hybrid: minimal on-chain data + IPFS for metadata |
| Write Permissions | Only delegates, anyone with claim, whitelisted third parties | Delegate-only writes with signature; optional admin whitelist |
| Schema and Validation | Single schema, multiple schemas, schemaless; on-chain vs frontend validation | Versioned schemas, validated via SDK, not enforced on-chain |
| Tooling (SDK + Subgraph) | Build SDK (sign JSON, gasless), subgraph for indexing per chain | Modular SDK + subgraph, chain-aware and DAO-specific |
| Governance and Roles | No roles, admin/multisig, upload time limits | Multisig admin role for whitelist + schema management |

Past proposals and implementations that this work builds upon:

* April 2025, [Towards a DAO ID](https://daostar.org/reports/daoid.pdf): A report by DAOstar that introduced concepts for standardized DAO identities and cross-platform compatibility.
* March 2024, [DAOIP-7](https://docs.daostar.org/DAOIP/7): A DAOstar proposal to use Ethereum Attestation Service (EAS) for recording certain DAO data.
* Nov 2023, [DAOIP-5](https://github.com/metagov/daostar/commits/main/DAOIPs/daoip-5.md): An earlier iteration of a DAO metadata standard (Metagov/DAOstar initiative).
* Nov 2023, [DAO delegate registry](https://github.com/show-karma/dao-delegate-registry): An smart contract implementation of a delegate registry, highlighting real-world needs for delegate info.
* June 2023, [DAO Delegate Registry Specification](https://docs.google.com/document/d/1q8DTt7zvMQ-fj8mGgJ8f8zA7icjn3aqxZzgxalRPR9w/edit?tab=t.0#heading=h.ox58ddltxb8r): A collaborative spec (Google Doc) that catalogued common delegate attributes across platforms.
* Feb 2022, [ERC-4824: Common Interfaces for DAOs](https://eip.tools/eip/4824): A DRAFT Ethereum standard that laid groundwork for representing DAO data in a unified way on-chain and off-chain.

> *Ecosystem feedback*
When a previous solution was presented in [Arbitrum DAO](https://forum.arbitrum.foundation/t/an-eip-4824-powered-daouri-for-arbitrum-dao/26386), an overwhelming majority of voters were in favour of an ENS based approach. This categorical support should hopefully encourage DAO members to support and take action.


* https://dhive.io/proposal/1392