Hello ENS! My name is Spencer Graham, aka spengrah.eth. Iām a longtime Ethereum and DAO builder and contributor, and Iām writing this post on behalf of Hats Protocol, the project I cofounded several years ago to help DAOs operate effectively without sacrificing on decentralization.
The purpose of this post is to open a conversation with the ENS community and explore opportunities where Hats may be able to offer value to the DAO. Recently, I joined the Meta-Gov Stewards weekly call to initiate this discussion, and the warm welcome Hats received encouraged me to take the next step here on the forum.
This is an open call for feedback. I look forward to your ideas, questions, and responses!
What is Hats Protocol?
Some of you may already be familiar with Hats Protocol as a way to create and manage DAO roles onchain. While this remains accurate, weāve recently found a better way to articulate what Hats is really all about: Hats Protocol is the unstoppable API for programmable organizations.
The primary insight of Hats Protocol is that roles are the atomic unit of organizational structure. Every organization is comprised of a network of interrelated roles, which are bundles of responsibilities, permissions/authorities/resources, eligibility requirements, accountability mechanisms, compensation, and more.
By instantiating roles as software objects, we can give organizations programmable interfaces for all of those properties. And by instantiating them onchain, DAOs can program themselves with all the benefits of smart contracts: autonomy/sovereignty, automation, composability, integration with permissionless financial primitives, etc.
A number of organizations use Hats Protocol today for many use cases ranging from council-based governance to moving their entire organizational structure and operations onchain. You can see some of these in our case studies. This just a sample of whatās possible with Hats, many of which make one another more valuable. As weāve helped DAOs improve their operations and practical decentralization, weāve learned that the best approach is to start small. With that in mind, the next section outlines several use cases that may be good places for ENS DAO to get started with Hats Protocol.
Candidate Starting Opportunities for Hats to help ENS DAO
Here are four potential ways that ENS could get started with Hats. While I personally believe these would have substantial value for ENS DAO today, I encourage you to think about these more as thought-starters and concrete examples than formal proposals.
- a) Give the DAO admin control over Working Group multisigs
- b) Onchain steward elections
- c) Enforce steward terms onchain
- d) Onchain steward permission management
A) Give the DAO admin control over Working Group multisigs
Currently, the DAO relies on social trust and reputation rather than onchain authority to manage the Working Group multisigs. While this has worked well thus far, it does have some known drawbacks. For example, the Secretary must be added as a signer on each multisig to protect against lock risk, which i) does not fully protect against that risk (consider how often the Secretary and multiple Stewards are in the same physical room at conferences), and ii) increases collusion risk when the Secretary also serves as a Steward.
Using Hats Protocol and our Safe integration, ENS DAO could retain onchain administrative control over each Working Group multisig, including control over the signers as well as the ability to execute any transaction (eg to claw back funds). This would greatly reduce the above risks while also eliminating the need for the amendment proposed in the above-linked thread.
B) Onchain steward elections with C) onchain terms
Working Group Stewards are currently selected and managed via offchain processes (see DAO WG Rules 5, 6, and 7), relying on trusted parties to execute the will of the DAO.
Using Hats Protocol, ENS DAO can put itself back in full charge by bringing Steward elections fully onchain. Stewards would be elected into an onchain role, which could come pre-configured with various properties including permissions (see next section) and even robust accountability mechanisms (more on this later), and which could be programmed to be automatically revoked after their 1-year term (unless of course they are re-elected).
The Hats eligibility module interface that makes this possible lets developers program how a given hat is issued and to whom. Developers have already built a number of standard modules for common use cases (including a simple election concept), and the ENS community (or anybody) can build a custom module to fit the DAOās exact election requirements.
D) Manage Steward permissions onchain
Stewards have permissioned access to several DAO-owned resources, including Working Group multisig signing rights and membership in the Steward group chat on Telegram. Currently, when a Steward is elected or removed, those permissions must be granted and revoked manually by trusted parties. This has operational cost as well as security implications, which limits the type and amount of DAO-owned resources and tools that Stewards can be given access to in order to best achieve their important responsibilities.
Using Hats Protocol, all Steward accesses and permissions ā including onchain and offchain alike ā can be granted and revoked as a single bundle, all securely onchain by the DAO or any programmatic logic it desires.
Additional Opportunities / Future Thought-starters
Beyond the potential starting candidates above, there are many additional improvements that ENS DAO could make to its governance and operations using Hats. To spark some ideas from the ENS community, here are some of the opportunities I see.
One category of improvements relates to hardening the Working Group rules by making the onchain instantiation of the related roles the source of truth for those roles. All of the WG rules can be expressed role responsibilities, authorities/permissions/powers, selection criteria, and accountability mechanisms.
This is a generalization of the four use cases above, also unlocking other advantages:
- Enabling the DAO to claw back a Working Groupās assets from its multisig, eg after it has dissolved or in the case of misaligned behavior by its Stewards.
- Strengthening qualification requirements and accountability mechanisms for Stewards, such as requiring that a Steward hold (or stake) a minimum amount of $ENS, sign a Working Group agreement/policy, or be subjected to 3Ź³įµ party arbitration.
- Moving the source of truth for Working Group rules from centralized Github hosting to decentralized onchain DAO control.
- Upgrading the Working Group creation process from a social exercise to a robust and clear onchain process.
Similarly, instantiating the Secretary and Lead Steward roles onchain would bring many of the benefits to those roles and related DAO rules.
Another area of opportunity is hardening access control and permissioning of Discourse and other DAO-owned resources. For example, Discourse admin/moderator rights could be attached to the relevant hats (Secretary, etc). More speculatively, general forum write permissions (which is currently gated manually) could be automated with onchain logic of some kind (eg holding a minimum amount of $ENS tokens).
The last specific category Iāll raise here is the potential to harden DAO <> Foundation relations. According to the Foundation bylaws, the DAO has control over the Foundation directors, supervisor, and members. The DAO could use Hats to strengthen those bonds by enforcing that control onchain.
More generally, Hats turns an organizationās structure into a platform for development and bottoms-up innovation. For example, anybody introducing a proposal to the DAO could express their proposal in terms of the changes it would make to the DAOās onchain structure. Further, developers could permissionlessly build extensions and integrations for the DAO, expanding its capabilities. Iām excited to see more ideas from the community!
One active example is the Org Identity research proposal recently put forward by @jkm.eth and @arnold. Since an organizationās fractal identity is expressed as roles, Hats would be an ideal integration with an ENS-powered standard for organizational namespace. Some powerful ideas include resolving hats/roles from ENS domains and subdomains, using ENS records as the source of hat metadata (eg role responsibilities), and bringing the full dimensionality of Hats-powered roles to the org dataset indexed by ENS.
Other Important Considerations
Whenever considering adopting a new tool or capability, there are a number of non-functionality considerations that DAOs should make. Here Iāll do my best to anticipate some of these questions.
Platform Risk
Hats Protocol seeks to minimize the risk that all stakeholders take when deciding to use, integrate, or build on Hats. We approach this from both a technology and governance perspectives.
- All Hats contracts and are fully open source (AGPL or MIT licensed), immutable, and unowned.
- All contracts are permissionlessly deployable via create2 factories to the same address on all evm-compatible chains (eg no reliance on our team to deploy to additional chains, such as Namechain).
- Our subgraphs are open source (MIT licensed) and deployed to the decentralized graph network.
- Our SDKs are also open source (MIT licensed).
- Our two existing front end applications are not yet open source. However, all source of data they use are publicly publicly available via some combination of onchain state, decentralized indexers (subgraphs), or decentralized storage (IPFS). And, we are looking for the right time/opportunity/approach to open-source UI code, and so we are very open to discussing this further.
Hats is designed to be maximally composable without introducing any tightly coupled dependencies, so using Hats does not incur any platform risk from dependencies, and would not tie ENS to any specific tools to which Hats integrates.
Hats is a horizontal protocol built on open standards, designed to work with any other protocol or platform. Multiple governance platforms have already integrated Hats into their offerings, and we have been in conversation with existing ENS governance platforms (including Tally and Agora) to integrate.
Of course, for these commitments to be credible over the long run, Hats Protocol itself must be operated and governed by a DAO, just like ENS. While that is not fully the case yet, we are on that path. For the past 18 months we have been incubating a protoDAO and dogfooding our own technology to prepare for a governance transition.
Security
The primary Hats contracts have received multiple audits and have suffered no hacks or bugs since being deployed in 2023. See our security docs for more detail.
Open Call for Feedback
Thank you for your time and attention. I am excited to hear your questions, concerns, thoughts, feedback, and ideas! I will be actively monitoring this thread and you can expect quick responses.
