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
Hey jkm.eth, love this initiative. I understand the @Meta-Gov_Stewards sponsored your proposal.
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.
—
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.
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)
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.
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.
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.