Proposal: Modules Registry Curation, v0.1

This is the proposal to define the first version (officially v0.1) of the curation mechanism and guidelines for the Hats Modules Registry. For background, design goals, and other considerations, see the original Discussion post.

This forum post will be up for 48 hours before I submit the onchain proposal to the protoDAO (see Appendix A). Input and feedback within that window can still be incorporated into the final proposal.

The Present Proposal

  1. Establishes the Hats Modules Registry as the base layer of module curation
  2. Delegates the responsibilities and authorities to a) curate the Registry, and b) to govern the module curation mechanism(s) to two new hats within the protoDAO tree.

1. The Hats Modules Registry

With the primary goal of creating a credibly neutral list of safe and usable modules, the present proposal focuses on creating the base layer of module curation. It intentionally leaves room for additional layers and modes of curation to emerge on top that differentially meet the needs of various ecosystem participants.

The Hats Modules Registry…

  • Is a global registry of safe and usable modules.
  • Establishes the metadata foundation for apps to effectively and efficiently distribute modules to Wearers.
  • Optimizes for credible neutrality by being curated primarily based objective criteria (see section 1.2).

1.1 Curation Rubric

Curators (see section 2.1) should approve modules for the registry if they meet the criteria outlined below. The primary factors are safety and usability, with the latter comprising of adherence to the registry submission schema and quality/accuracy of the submission content.

If this proposal is passed, these guidelines and rules for curating the Registry will be added to the modules-registry repo.

1.1.1 Objective Criteria

These criteria are objective. Curators with the relevant skills should be able to evaluate submissions with relatively low effort, and cross-Curator agreement should be high. Assessment of many of these criteria can likely be automated over time.

Category Objective Criteria
Safety - The module works as described; no bugs
- Is not malicious
Schema Adherence - Metadata is complete
- Implementation contract is deployed to at least one chain
Quality - Automated tests pass
- Metadata (including name, descriptions, other documentation) is accurate

1.1.2 Subjective Criteria

Subjective criteria take more effort to evaluate and also tend to have lower cross-Curator agreement, both adding to curation overhead. Additionally, they also introduce uncertainty for module developers over whether or why their module may be rejected, which harms credible neutrality and may have a cooling effect on module development.

Over the medium to long run, as additional layers of curation emerge, subjective criteria should probably be pushed upwards, away from the base layer Registry. In the near term, however, given the current close relation between the raw registry data and what end users see, for this first version we will experimentally ask Curators to assess a small amount of subjective criteria. The inclusion of subjective criteria in the rubric should be re-evaluated in Season 2.

Category Subjective Criteria
User-Friendliness Metadata is legible and affords clarity to end users

1.2 Curation Cadence

If this proposal is passed, the following cadence guidelines and rules will be added to the modules-registry repo.

1.2.1 Standard Cadence

  • Monthly
  • All newly approved modules and changes to registered modules are to be announced at the end of each month
  • To be included in a given month, new submissions or changes must be submitted no later than one week before the end of the month
  • Within this constraint, Curators may review async or devise their own process and timing

1.2.2 Expedited Cadence

  • On an ad hoc basis, module developers may request review outside of the standard cadence.
  • It is up to Curator discretion for when and how quickly they honor requests for expedited review.

2. New Hats

Curating and governing the Registry is the responsibility and authority of the protoDAO. The present proposal creates two new hats and delegates those responsibilities and authorities to each.

2.1 Modules Registry Curator

With this proposal, the protoDAO delegates the responsibility and authority curate the Modules Registry to a new Modules Registry Curator hat.

While the exact qualifications for this role will be determined as part of the first version of this mechanism, it is likely that wearers of this hat likely should have some ability to review and understand smart contract code.

2.1.1 Module Curator Hat Properties

The properties of this new hat are defined in the Hats protoDAO Tree Update JSON and tx calldata listed in Appendix A. They are also listed here for convenient review:

Property Description
Name Modules Registry Curator
Description The role of the Modules Registry Curator is to ensure a high standard of quality and usability for modules within the Hats Ecosystem. They do so by reviewing and approving submissions and modifications to the Hats Modules Registry in accordance with the curation guidelines and in collaboration with fellow Curators and the protoDAO at large.
Responsibilities Review submissions and modification requests in accordance with the Curation Rubric and Cadence. Uphold the standard of safety and usability for the Registry. Provide input to the Module Curation Mechanism Committee on ways to improve the Registry and curation mechanism.
Authorities Approve module submission PRs in the modules-registry repository. Merge PRs when approved by 2 or more Curators.
Admin Hats protoDAO Role Admin
Eligibility Hats protoDAO
Toggle Hats protoDAO
Mutable Yes
Max Supply 9
Image modules_curator.jpg - Google Drive

2.1.2 Initial Wearers

The present proposal will be followed by a subsequent proposal to mint the Module Curator hat to an initial set of wearers. Current candidates are below. If you’d like to be a founding Module Curator, please respond to this thread.

  • nintynick.haberdasherlabs.eth
  • gershido.eth
  • spencer.haberdasherlabs.eth

2.2 Module Curation Mechanism Committee

With this proposal, the protoDAO delegates the responsibility and authority to govern the Modules Registry and other module curation mechanism(s) to a new Module Curation Mechanism Committee, with membership in the committee defined by the Module Curation Manager hat.

While the exact qualifications for this role will be determined as part of the first version of this mechanism, this committee will likely be comprised of wearers of the Module Curator hat as well as other Stewards with expertise in designing and managing governance and incentive mechanisms.

2.2.1 Module Curation Manager Hat Properties

The properties of this new hat are defined in the Hats protoDAO Tree Update JSON and tx calldata listed in Appendix A. They are also listed here for convenient review:

Property Description
Name Module Curation Manager
Description The role of the Modules Registry Manager is to foster a healthy ecosystem of Hats Modules. They do so by governing the Hats Modules Registry mechanisms in collaboration with other Managers and the protoDAO at large.
Responsibilities Ensure the Registry and curation mechanism meet design goals and improve over time. Investigate, develop and propose new mechanisms to improve Registry curation and foster a healthy ecosystem of Hats Modules.
Authorities Approve PRs to change the submission schema and curation rubric in the modules-registry repository. At least 2 Managers must approve a PR before it can be merged.
Admin Hats protoDAO Role Admin
Eligibility Hats protoDAO
Toggle Hats protoDAO
Mutable Yes
Max Supply 9
Image curation_manager.jpg - Google Drive

Note that both hats confer their respective authority to wearers via the same Github PR approval mechanism. In practice, this means that Module Registry Managers technically can, if they so choose, approve PRs related to new or changed module submissions. The constraint not to do so is a social one, potentially resulting in revocation of their hat.

2.1.2 Initial Wearers

The present proposal will be followed by a subsequent proposal to mint the Module Curation Manager hat to an initial set of wearers. Current candidates are listed below. If you’d like to be a founding Module Curation Manager, please respond to this thread.

  • prose11.eth
  • bpetes.eth
  • brennanmulligan.eth
  • gershido.eth
  • scottrepreneur.eth
  • nintynick.haberdasherlabs.eth
  • spencer.haberdasherlabs.eth

Appendix A: protoDAO Tree Changes

Tree Edit JSON

Import this JSON file into the Hats app to preview the proposed changes.

Transaction calldata

This is the raw data that will be executed onchain if this proposal passes.

Target contract (Hats.sol): 0x3bc1A0Ad72417f2d411118085256fC53CBdDd137

calldata bytes:


Appendix B: Room for Future Refinements

The present proposal is simple and constrained. Recognizing that we will learn a lot about the challenges and needs of the Hats Module ecosystem over time, it intentionally avoids designing mechanisms, processes, or policies to address a number of issues that we today expect to arise.

Here are a number of areas where future refinements are likely to be valuable and even necessary:

  1. Common infrastructure to enable higher-level curation layers (such as token-lists style repo).
  2. More capture-resistant curation infrastructure (such as moving the Registry onchain in some fashion).
  3. More robust system for handling expedited review (such as an auction queue).
  4. An explicit mechanism or process for how existing modules respond to future changes to the registry schema.

These areas—and more—are expected to be the subject of future proposals and work by the Module Curation Mechanism Committee.


This proposal includes insights and perspectives from protoDAO stewards BPetes, Payton, Ido, Scott, Juliette, and Brennan. Thank you!


Hey there! Really cool initiative and a nice step in the direction of decentralization of the modules list! One question I had was:

Where does responsibility around maintenance for accepted modules fall? I know there are standards that need to be met before a module is approved (e.g. has to be bug-free), but what if something breaks? Is it also part of the Module Curation Hat wearer duties to make sure all modules remain functioning/up to date or at least “sound the alarm” to the community when modules stop working for some reason? Or does this not fall under their responsibilities explicitly?


Great question!

As I’m currently thinking about it, curators are not responsible for maintenance or triage of modules on the registry. The rationale here is that we want ultimately to create a marketplace-like system where module developers have incentives for their modules to be more highly used, and therefore have an incentive to maintain them well.

Since the Modules Registry repo is public, anybody can open a PR. This means that anybody—including curators, other Stewards, and members of Haberdasher Labs—can submit a request to deprecate a module that no longer functions. Curators would then be responsible for assessing the PR and approving it if indeed the module is no longer functional.

Does that make sense to you? My expectation is that this all will evolve and grow more concrete and robust.

1 Like

Great work here. I think the breakdown of the Hats, responsibilities and authorities, and initial wearers is really well constructed and reusable for other protoDAO proposals and beyond.

Dividing 1) Curation from 2) Curation Mechanism development makes sense to me. I would even be open to having the Registry Curator hat be admined by the curation mechanism committee. Should we have a separate hat / shared account for the committee itself?

The experience of importing the tree JSON file into the app worked well for me. Some notes:

  1. May need to recreate the changes to tree based on the latest state (protoDAO wearer address update + recent community hat claims). If someone else claims the community hat between proposal submission and proposal execution, will that be a problem?
  2. In your view, should we remove “Define and approve and update the mechanism for curation of items on the Hats Module Registry” and “Curate the Hats Module Registry” from the protoDAO hat (ID 1.2), or leave it there and also include on the new hats? Do we need a UI affordance to show “redelegation” or something?
  3. Is there a way to use or otherwise to connect the Github PR approval authority, or are those going to be connected up manually using emails?

Overall, looks great to me! Thanks for your work on this.



Thanks for reviewing!

We should be fine since the calldata — which is what actually executes the changes — will not interact with additional wearers of any hats.

We should keep them. The protoDAO is delegating these to the new hats, but that doesn’t mean it doesn’t have them anymore.

Unfortunately not. It will need to be manual.


This makes a lot of sense! Thanks for the answer!

1 Like