Making ENS the standard for organizational identity

DAO-Wide Temp Check
1

TL;DR:

@arnold and I are taking lead on forming a group to develop a technical standard for storing organizational metadata on ENS. This will be formalized as a time-limited sub-group under one of ENS’s current working groups, tasked with producing an ENSIP and promoting adoption.

We are looking for feedback on this plan.

The Problem

DAOs have data that is important to share publicly, including things like:

  • Addresses of DAO contracts and treasury wallets
  • Delegates, their statements, conflicts of interest and other details
  • Where proposal discussions and votes are taking place
  • Off-chain organizational structure: working groups, stewards, committees, etc.

Currently, every DAO handles this differently, and these details are usually scattered between multiple web 2.0 locations (website, Github, Discourse, Tally, Agora, etc).

This makes it hard to know where to find information that is trustworthy and up-to-date. It also makes it impossible for dApps, smart contracts, and other services to programmatically retrieve this information in a trustless, web3 way.

This has been a known problem for a long time, with multiple attempts to solve it.

There is real demand for this problem to be solved, but so far no one has hunkered down and done it. ENS can change that.

The solution

We believe ENS is uniquely positioned to establish itself as the ecosystem’s central registry for this type of data. ENS is already the leader for individual identity, so extending this to also serve on-chain organisations is a natural extension.

We are in the process of producing a standard for how to store metadata as individual text records under ENS names/subnames, allowing for the creation of a federated knowledge graph for on-chain organizations.

Some standout benefits to doing it this way:

  • ENS can become the single source of truth for on-chain information about DAOs and communities
  • Records on ENS are credible, since they can only be updated by authorized entities
  • Delegates and users can update their own records, decentralizing the flow of information
  • The system is completely open and infinitely adaptable to new use cases
  • No new functionality needs to be added to ENS; all that’s left is to agree on a standard

Overall, we believe this would be a great improvement to ENS, leading to more usage and adoption, and would become an invaluable service to the entire Ethereum ecosystem.

Progress so far

A draft spec has been started and is open for comments: DAO registry - HackMD

We have presented our work to the MetaGov, Ecosystem, and Public Goods working groups, to gather initial feedback and to gauge support for pursuing this idea.

The response has been very positive, with community members highlighting specific aspects of this idea they would like to see implemented.

Timeline

We are now in the process of figuring out where/how the sub-group (“pod”) should be established, after which the entire process should take no more than 6 months.

Stage I: Outreach (up to 3 months)

  • We will engage with DAOs, vendors, and service providers to assemble representatives from across the ecosystem to participate

Stage II: Working sessions (up to 3 months)

  • We will hold 6-8 working sessions, once every two weeks with async work in between, to finalize the standard

Deliverables

  • Produce a formal ENSIP detailing the standard
  • Produce a testnet implementation to demonstrate populating metadata, validating schemas, and retrieving schemas

How to get involved

For now, everything is being done in public and everyone is welcome to share their thoughts. Participation in working sessions will be dependent on an application process.

If you have any thoughts on this implementation plan please share them below, and if you would like to more actively participate, please join the project’s Telegram group: Telegram: Join Group Chat

14 Likes
2

The Enscribe team is very interested in this proposal, as mentioned on the Ecosystem call.

Whilst the specific area we’re interested in is ENS for smart contracts, the concept of having standards to store metadata associated with smart contracts in a canonical manner could be incredibly useful.

For instance, contract source code verifications could be linked to named smart contracts on ENS in a standardised format. This can help standardise access to verification data across a number of sources and could potentially feed into standardised approaches for packaging smart contract applications.

We’re keen to try and contribute to the working group, with a view to understanding if the approach could

  • be generalised to support a wider array of use cases
  • or if established, how a similar approach could be takento support smart contracts
6 Likes
3

Workshop Notes (Workshops + Community Call)

We had our first community call on Thursday, Jul 17th. There were 10 attendees, and we did a brainstorming workshop to better explore the project. Below is a summary of our discussions.

What is the purpose of the group?

Building an open, canonical registry for DAOs (and other on‑chain organisations) on ENS. The goal is to make organisational metadata—contracts, roles, treasuries, delegates, compliance info—cheap to publish, easy to crawl, and standardised across chains.

Motivations:

  • Governance tooling currently relies on scattered, proprietary data silos.
  • Delegates, analysts, and regulators lack a single, trusted source of truth.
  • ENS already anchors personal identity; extending it to organisational identity is the logical next step.

Pain Points We’ve Observed

  • Multiple delegate profiles: delegates end up recreating their bios in two or three different dashboards.
  • High gas to update: editing an ENS text record on L1 can be expensive.
  • Opaque term limits & roles: for example, committee members are tucked away in Notion, and council/steward tenures are hard to uncover.
  • Treasury address sprawl: multisig wallets spread across chains are difficult to organise and verify.
  • Cross-chain discovery gap: “there’s no way to find and verify DAOs across chains.”
  • Custom records ≠ standard: text records can hold anything, but without a schema, tooling can’t reliably use them.
  • Transparency ≠ Accessibility: the data is on-chain, yet it isn’t machine-readable or well-indexed.

Why Now?

  • Namechain could make frequent ENS writes affordable.
  • DAOs are maturing beyond the foundation model and need legitimacy.
  • Regulatory clarity drives demand (DRC advocacy, CoinCenter, StandWithCrypto).
  • Competing data vendors are emerging—establish a public‑good standard before walled gardens form.

Example Use Cases

  • Cross-chain Dashboards: DeepDAO/L2Beat-style explorer with unified view.
  • Governance Tooling: On-chain verification of roles (council, stewards) for contract-level permissions.
  • Delegation Insights: Rich delegate directories and voting histories.
  • Treasury Management: Canonical list of multisigs and escrow contracts.
  • Research & BI: Queryable dataset for governance effectiveness studies.
  • Compliance & Reporting: Machine-readable filings for regulators.
  • Anti-capture Frameworks: Monitor concentration of control & term limits.

“This standard exposes an organisation’s structure in a trustless, canonical, and crawlable way via ENS.” — m @estmcmxci

Target Audiences

  • Developers & Product Teams (wallets, dashboards, indexers).
  • DAO Contributors & Delegates (identity & reputation).
  • Researchers & Academics (open governance dataset).
  • Regulators / Policy Groups (Company‑House‑style registry).
  • Data Platforms (Dune, The Graph, Messari, Space‑and‑TimeDB).

Suggestions for Technical Approach

  • Eventual EIP‑style spec
  • Develop Proof of Concept on testnet to validate write/read flows.
  • Parallel spec writing + implementation dog‑fooding.
  • Leverage ENS text records with agreed JSON schema.
    • CCIP‑Read optional for bulky off‑chain blobs.
    • Reference ABI registry (“ENScribe”) to map contract addresses ⇄ ABIs.
  • Deep focus on DX/UX Experience with respect to target audiences

Success Metrics

  • Adoption: X flagship DAOs publish the schema; ENS recognised as org‑ID standard.
  • Integration: Major dashboards & infra (Infura, Alchemy, Viem) support read/write.
  • Defrag: Fewer duplicate delegate profiles; smoother DX.
  • Credibility Signals: Grants/funding from ENS DAO & ecosystem.
  • Standard Cohesion: No rival specs gaining material traction.

Ecosystem Engagement Strategy

  1. Secure ENS support to anchor legitimacy.
  2. Dog‑food internally; present POC for more concrete feedback.
  3. Leverage delegates to champion adoption.
  4. Outreach to infra (Infura, Alchemy), data platforms (Dune, The Graph, Messari), and tool builders (Tally, Agora, Aragon).
  5. Maintain transparent forum thread + open spec drafts.
  6. Look to DRC/CoinCenter for regulatory alignment.

Risks & Challenges

  • Private/Proprietary Competitors may attempt closed registries.
  • Data Aggregator Moats (protecting business models) could resist.
  • Standard Fragmentation if spec isn’t authoritative enough.
  • Public‑Good vs Sustainability – funding & maintenance.

Some actions to take:

  1. SWOT & Risk Assessment (lessons from DAOstar; anti‑capture considerations).
  2. Competitor Landscape Report (Space‑and‑TimeDB, proprietary dashboards, etc.).

Quotes

  • “We believe in ENS as an identity standard for individuals, and it’s not much of a leap to make ENS an identity standard for organizations.”
  • “Promoting organizational transparency could bring legitimacy to DAOs and make them more trustworthy.”
  • “We need to strike a balance between being authoritative enough to avoid fragmentation, and being inclusive to foster adoption.”
  • “This registry could help regulators and end-users understand what stage a DAO is at and how it operates.”

Resources

All resources can be found on our public Notion page.

4 Likes
4

@estmcmxci appreciate you sharing this and I believe having an org ID standard would definitely be useful. Also, ENS is the right place for us to make it easy to access and check on the Ethereum ecosystem.

Currently, to index, research or add new DAOs to the dashboard on anticapture.com we have to go after most of that information ourselves through badly organized docs, forums and unreadable governance processes, or get in calls with operators that may or may not actually know how things work in the back.

Having a well established source of truth would be great, but the challenge often lies in the maintenance of the information. I see a lot of value if practices like the DAO IPs were published and followed (specially DAOIP-2 / ERC-4824 ), even if they have to be extended, given they are pretty brief and only describe “core” elements that won’t manage all demand over time.

There’re some issues with having things like lists of members, but URI referencing lists of toke nholders should suffice for most DAOs imo.

Curious on how this moves forward, gonna try to stay in the loop here, but please let me know if there’s something on TG for easier discussion.

3 Likes
5

Nothing is decided yet, but one possibility is that delegate statements would be attached to the delegate’s own ENS. Then you can monitor token balances and delegations to get a list of voters and look up each person’s ENS to find if they have a statement published.

Please do join our public Telegram! Telegram: Join Group Chat

1 Like
6

This is literally the what prompted us to explore this in more detail! Thanks for sharing your experience. Looking forward to jamming more on this.

1 Like
7

Community Call Summary: Thursday 31st

  • Roadmap Draft: James shared a public draft of the roadmap.
  • Fireside Chat: Rashmi from DAOstar discussed personal and organizational motivations behind pushing DAO standards, sharing key learnings from the journey.
  • Standards Mapping: The group began mapping historical attributes from existing standards to reduce redundancy.

Key Takeaways:

  • Most organizations initially see standards as “nice to have” — framing and regulatory relevance (e.g., DAOIP-9) are crucial to shifting this to a “must have.”
  • Interfaces and self-serve onboarding will be critical to adoption — reduce friction, reduce handholding.
  • The term “spec” is more approachable than “standard” and may ease adoption.
  • Existing assumptions were largely validated through experience — the project is on the right track.

Additional:

Resources
Expanded resources and commentary can be found on our public Notion page.

3 Likes
8

I have some experience in this area. In 2017 Delaware amended their General Corporations Act & Limited Liability Act expressly authorizing corporations & LLCs to maintain their books and records on blockchain - shortly their after I became the 1st attorney to memorialize smart contract addresses in documentation filed with the State.

More recently I obtained a provisional patent for a system and method for managing books and records (e.g. legal documentation) using blockchains for real-time legal compliance, and though this could have been independently developed I elected to integrated it into the ENS protocol by leveraging subdomains and records. See: TOKENIZATION LLC - Mint/Own/Manage a Delaware LLC on ENS

Other lawyers in the space have done similar things to scale legal protections (mint a LLC protected series/tokenized ownership) but never touched onchain legal compliance much less integrated into ENS protocol.

For illustrative purposes, ENS DAO uses subdomains effectively for the organization but both subdomains and organizational resources could be mapped to the parent ens.eth, or a preferred name, effectively using records. In my linked post you’ll find the below image - something of a legal oracle of legal entities (organizations) which map books and records (organizational legal data) to ENS.

image
image828×817 72.1 KB