Kickoff: Organizational metadata on ENS

[jkm.eth]

Hello!

We are leading a project sponsored by the Metagov Working Group to create a protocol for storing organizational metadata on ENS. The end result will be a standardized way for any kind of organizational structure to be represented as records stored under an ENS name. The most immediate use case will be for DAOs who want to offer transparency and security in sharing information about their organizational structure.

Storing this data on-chain would allow DAOs to:

• Present an official, public list of all their contract addresses (treasury, voting, governance tokens, etc)
• Describe the organizational structure of working groups, councils, committees, and any other bodies that are sanctioned by the DAO.
• Publicly acknowledge paid and/or unpaid delegates, and create a space for them to publish delegate statements, conflict of interest disclaimers, or other important information.
• Publish information that is required for regulatory reasons, such as contact details for an associated DUNA or legal entity, limited liability disclaimers, etc.

DAOs already use ENS names to represent themselves in a trustless/decentralized way, and for the DAOs whose ENS records can only be updated as the result of a DAO vote, organizational records will be considered the single source of truth.

What to expect

The initiative to develop this protocol is being led by Lighthouse Labs. The project was previously discussed here. We plan to produce a technical spec that can be published as an ENSIP or EIP, with a PoC implementation of code that populates and reads organizational records from ENS.

We will be holding regular meetings on Thursdays at 10am ET (3pm GMT) as listed on our Luma page. Our expected schedule is as follows:

• September 25, 2025: Chat with Ori from Mechanism Institute on strategy for community adoption
• October 9, 2025: Spec iteration and feedback
• October 23, 2025: Spec iteration and feedback
• November 6, 2025: Spec iteration and feedback
• November 20, 2025: PoC iteration and feedback
• December 4, 2025: PoC iteration and feedback
• December 18, 2025: Community roadshow

To get involved, please join our Telegram group!

[estmcmxci]

Hey jkm.eth, love this initiative. I understand the @Meta-Gov_Stewards sponsored your proposal.

@jkm.eth

We plan to produce a technical spec that can be published as an ENSIP or EIP, with a PoC implementation of code that populates and reads organizational records from ENS.

Could Lighthouse Labs share written progress updates toward the tech spec? Perhaps updating this thread. That way, when the time comes to present it to the DAO and the development teams supporting the protocol, they’ll already be primed on the implementation and its use cases.

—

@jkm.eth

Publish information that is required for regulatory reasons, such as contact details for an associated DUNA or legal entity, limited liability disclaimers, etc.

It makes sense for policy to follow processes that default to verifiable, trustless mechanisms. I’m curious how developments from your initiative might carry over into discussions about the role the DAO’s legal wrapper plays, and whether organizational metadata could help formalize or clarify those responsibilities in a transparent, onchain way.

[jkm.eth]

September 25, 2025: Community call

We spoke with Ori Shimony, a researcher with the EF, about why he thinks this project is important and what we can learn from his experience. Below is a summary of the conversation.

Ori’s Background & Experience

• Currently at Ethereum Foundation doing use case research
  • Identifying technical/adoption blockers for nascent use cases
  • Developing interventions and collaborations to remove barriers
• Founded Mechanism Institute
  • Created mechanism library cataloguing onchain mechanisms design space
  • Covers governance, public goods funding, DeFi market mechanisms
• Led dOrg (2019-2022)
  • First service DAO and first DAO with legal entity (Vermont BBLC)
  • Built DAO tooling and Web3 infrastructure through consulting model
  • Still operating with 6-8 active projects, ~150 contributors total
  • Private DAO with strict hiring process and non-transferable reputation tokens

What do you see as the most important use cases for organizational metadata?

• Counterparty verification and legitimacy
  • Service providers need verifiable credentials when representing organizations
  • Similar to corporate registries (UK Companies House) but for Web3
  • Addresses authorization problems (e.g., former members misrepresenting affiliation)
• Legal compliance and transparency
  • Essential for DAOs with legal wrappers (Duna, Marshall Islands structures)
  • Could become source of truth for organizational agreements and bylaws
  • Enables programmatic compliance monitoring
• Website and domain verification
  • Link between Web2 presence (websites) and Web3 identity
  • Custom ENS resolvers to verify CNAME connections
  • Prevents phishing and establishes official channels
• Enhanced wallet/interface integration
  • Metamask showing verified contract names during transactions
  • Profile verification across platforms (similar to X verification)
  • Quantitative trust metrics (earnings, token holdings, tenure)

Another idea for further down the line

• Organizational reputation system using EAS
  • Verified reviews from confirmed members/customers
  • Similar to Trustpilot/Glassdoor but with proof of affiliation
  • Scoring visible on platforms like Etherscan

Adoption Strategy & Blockers

• Primary challenge: collective action problem
  • Individual organizations lack strong incentive to adopt early
  • Benefits accrue to ecosystem, not individual adopters
  • Different DAO types (DeFi protocols vs service DAOs) have different needs
• Proposed solutions:
  • Legal compliance as primary driver (strongest incentive)
  • Integration with aggregators and tools (DeepDAO, Etherscan)
  • Blue checkmark system for verified organizations
  • Partnership with friendly jurisdictions (Wyoming Duna, Marshall Islands)

Who should we target?

• Look beyond traditional DAOs to broader organizational metadata
  • Web3 agencies and service providers
  • DeSci DAOs (high verification needs for scientific credibility)
  • Small private groups
• Potential to drive DAO creation by making onchain organization aspirational
• Integration with existing tools (Aragon’s new activity, Hats Protocol, etc)

What are some suggested next steps?

• Develop rough pilot with ENS implementation
• Engage legal specialists in DAO-friendly jurisdictions
• Target law firms and compliance service providers for feedback
• Create demonstrable standard before broader outreach
• Focus on solving specific legal/regulatory pain points as primary adoption driver

[jkm.eth]

Progress update: You will notice in our kickoff post above we proposed a schedule of events and meeting dates. We originally planned to have regular sessions throughout Q4 of this year, however we have since realized that we don’t always have enough content to warrant a group discussion. In order to be respectful of everyone’s time, we have decided to only schedule calls/meetings when we have something worthwhile to present/discuss/do. We will post notice of events here when they are scheduled, and they will always be listed on our Luma page.

The proposed schedule above also didn’t take into account the holiday season, and since many of the community members we want to involve will have limited availability during this time of year, we may need to push back much of the schedule into January and February.

Since our last update, we have been in conversation with Nouns DAO, MIDAO, Uniswap, and others about regulatory needs that could be addressed by having organizational metadata on-chain. This is in addition to previously exploring the pain points that could be solved by publishing contract addresses, wallet addresses, delegate information, and working group structures. Now that we have collected a lot of information from a wide variety of potential users, we are doing research into industry best practices for data schemas and have begun working on the next draft of the tech spec, so that we will have a starting point for our next round of conversations.

[jkm.eth]

Update on technical development: After having many discussions with potential users from across the ecosystem, we have been working on finalizing the technical foundation for the spec.

The first iteration of the idea was a top-down approach. It used the naming and structure of a .eth domain to convey meaning. For example, a top-level manifest file could specify that delegates.root.eth would contain information on all DAO delegates.

We have since proposed a new system which is much more flexible and easier to maintain. In this version, the roles of each “node” in a tree of subnames would be explained solely using text records, and the tree structure would be ignored. This means users are free to choose a naming scheme and layout that makes the most logical sense for their use case, and whatever they choose will be compatible with our system. This provides multiple benefits over the original idea:

• Cheap to implement (only one record per subname)
• Can be added to existing registrations with no changes required
• Compatible with other systems and use cases (e.g. it doesn’t break Enscribe contract naming)
• Easy to maintain: to update one node, only a single text record needs to be changed.
• Easy for non-technical people to understand; just like adding labels to each subname.

We have published an overview of this latest thinking on our Notion page with more details. For next steps, we will be asking for feedback/review by technical members of the community. If you would like to be involved, please join our Telegram group and/or watch this space for notice of our next working session.

[jkm.eth]

Here is a quick recap of some topics we have been investigating, and the decisions they led to:

JSON
Many related proposals (e.g. EIP-4824) have suggested pointing to JSON payloads to convey structured data. The first iteration of our plan also included using JSON to describe organizational structure.

We’ve since decided that this spec should prioritize on-chain access and ease of use, and so JSON should be avoided. Metadata attributes should be included as standalone records, allowing them to be queried and updated individually. This also makes it possible for users to manually query and manipulate individual records if needed, which greatly improves ease of use.

If a particular attribute needs to contain a complex value (like an array of entries), CBOR can be used to encode the value of the attribute, but multiple attributes should not be combined into one record.

Naming conventions
We looked into schema.org and various ontological organizations to see if there is an existing standard for naming data which could be applicable for our metadata attributes. None of the options we looked at included enough values specific to our use case, so they didn’t seem appropriate to implement and we are confident that defining our own attribute names will be acceptable.

Schema.org is focused on websites and SEO, however in the future it might be nice to have our attributes added into schema.org so that the same attribute names could be used when on-chain data is displayed on web pages. In anticipation of this, we will attempt to draw from schema.org’s existing naming conventions where applicable (e.g. attributes describing people), but we will prioritize choosing names that are most appropriate for the situation and not go out of our way to follow conventions which were designed for a different technology.

Next steps
We have begun drafting an ENSIP and creating mockups of what a UI implementation would look like, which will allow us to have more concrete technical discussions.

[jkm.eth]

Since our last update, we have completed another technical revision and greatly simplified the design of the system. It now allows us to rely less on validation rules enshrined in off-chain documentation, and makes it easier to have all intentions live on-chain. We also finished the first draft of our ENSIP, which we will iterate on together with contributors from the community.

Both of these can be found on our Notion page, with a quick overview below:

Technical design revision (v3):

We introduce two new global text record key names: “class” and “schema”.

By setting a “class” text record on a node, one can declare the organizational role of that node and that of the address it points to. This is mostly for the benefit of humans who are trying to understand the purpose of each subname, however these values can also be used by machines to classify or seek out specific types of nodes. The ENSIP includes a list of common class values (like “wallet” and “contract”) together with a description of each. Although any value can be used, sticking to one of the predefined values will increase compatibility across the ecosystem.

We’ve also introduced a “schema” record, which contains a URI pointing to a JSON schema definition which explains what attributes can be added to the node as additional text records, including the key name, type, and description of each.

If a “schema” record is populated, automated systems can ingest it and find out which key names they should query to retrieve the rest of the metadata. Additionally, standardized schemas can be published, allowing everyone who uses them to have their metadata properly formatted and presented by dashboards and other systems.

Once populated, this combination of records can be used to visualize ENS names in various ways:

Above: A hierarchical view of an entire ENS name can be displayed, highlighting the class value of each node, allowing for a human-friendly overview of the organizational structure.

Above: A node can be examined in detail showing its declared class and/or schema-specified attributes.

Above: All nodes can be autonomously indexed, with each node’s full ENS name as an identifier showing how it fits into the overall structure. When turned into a database (or spreadsheet), it is now easy to identify all of the key components of the organization or sort the data in different ways.

Additional details:

The draft ENSIP and technical overview on our Notion page include more detailed information, such as complex record types and how certain use cases could be achieved.

Next steps:

Now that we have collected community input, done research, designed a system, and drafted a proposed ENSIP, we are now ready to continue with community outreach and invite feedback and suggestions from contributors (phases 3 and 4 on our roadmap).

If you have any comments or feedback to share, please feel free to reach out! (details on the Notion page)