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
- Establishes the Hats Modules Registry as the base layer of module curation
- 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:
0xac9650d8000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000026000000000000000000000000000000000000000000000000000000000000001e4b052925e000000010002000400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000009000000000000000000000000eb25842011d853650b401163d333cd6ae70d4553000000000000000000000000eb25842011d853650b401163d333cd6ae70d4553000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000001600000000000000000000000000000000000000000000000000000000000000042697066733a2f2f6261666b726569627a74616e65336662797661347635776d736578326f666865776d6572366163687a67376d796d6a6b3273346f766a336d6a66340000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000042697066733a2f2f6261666b726569673264716462713433376d67337862346878627a6c656c79366372637370647a713672796d7a6576727067687366706d726935690000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001e4b052925e000000010002000400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000009000000000000000000000000eb25842011d853650b401163d333cd6ae70d4553000000000000000000000000eb25842011d853650b401163d333cd6ae70d4553000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000001600000000000000000000000000000000000000000000000000000000000000042697066733a2f2f6261666b72656967336d6c64696a76626f373734337a6237376e777569706b7378797868696f676732366e6b3736356a68656b7279367a326d63610000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000042697066733a2f2f6261666b7265696534357970777767696d36797974656c696d6b6d6367727a64717737736f7a72336263646173696275773476703578687869636900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
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:
- Common infrastructure to enable higher-level curation layers (such as token-lists style repo).
- More capture-resistant curation infrastructure (such as moving the Registry onchain in some fashion).
- More robust system for handling expedited review (such as an auction queue).
- 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.
Acknowledgements
This proposal includes insights and perspectives from protoDAO stewards BPetes, Payton, Ido, Scott, Juliette, and Brennan. Thank you!