TL;DR: The purpose of this document is to explore the implementation of Hats protocol’s role-based toolkit as the new distribution of influence model within the Grants Org. This would replace the existing mechanism, which is powered by Otterspace badges. It would not only replace the existing tooling, it would lay the groundwork for expanding the distribution of influence to an even broader set of stakeholders within Grants, and increase accountability between the Grants Committee and the community.
We would appreaciate feedback on this model by June 15th.
Overview & Background
Since November 2022, the Grants program has used Otterspace badges to distribute influence on the grant application and approval process to beyond the Grants Committee. Although the Grants Committee still holds final signing power to distribute funds, this mechanism enables past grantees (represented by Otterspace badges) to express their support or disapproval of new grant applications. This happens through participation in an off-chain Snapshot poll, allowing them to signal their input to the Grants Committee to help inform a final decision on any given application.
While this was a great initial experiment with distributing influence within the Radworks Grants program, the tooling and mechanism have their limitations. It required bordumb to manually distribute badges rather than being able to automate that process. In 2023, the team developing Otterspace badges dissolved, and while the badges are still active, the tech is not being actively developed to enable new functionality.
We propose upgrading this infrastructure from Otterspace badges to Hats. Implementing Hats Protocol as the new distribution of influence mechanism within the Grants Org not only provide an updated tooling infrastructure for this mechanism, but also allows for automation of distributing, claiming and revoking Hats (or roles & authorities) amongst the stakeholders involved. The adaptability and modularity that Hats offers, as well as the team’s commitment to open source and decentralization make Hats a sensible, mission-aligned solution to implement to further Radworks’ and the Grants Org’s the decentralization effort.
Why Hats?
Hats Protocol is an onchain roles protocol that empowers groups with the responsibility, authority, and accountability needed to get things done. “Hats” are programmable, revocable, and legible roles, represented onchain by tokens that conform to the ERC-1155 interface. Hat-based roles can be flexibly imbued with responsibilities, authorities, accountabilities, context, and more.
They are connected together in a tree structure (aka a “Hats tree”) to create flexible operational and governance structures that are controlled by an organization or its designees, which can then be visualized in any Hats front-end. The Hats trees are collectively controlled by the wearer of the “Top Hat”, which could be an individual or a group, such as a DAO.
Hats tokens can be held by any address including an EOA, multisig, or contract. When an address has a balance of 1 of a given Hats token, it is considered a “wearer” of that “hat”. Then, by way of various token-gates, that address is granted to the authorities that have been associated with that hat. Eligibility modules can enable addresses to claim and wear a given hat only if they fulfill specific eligibility criteria, making the distribution of Hats highly customizable based on the needs of the community/mechanism.
Implementation
The implementation would be supported by Haberdasher Labs, the founding team of Hats Protocol. We imagine the implementation of Hats into the Grants program rolling out in a few different iterations. The first iteration outlined below focuses on replacing the existing tooling (Otterspace > Hats) and suggests expanding who has influence within the Grants mechanism.
V1: Update Infrastructure, Expand Influence
The first version of implementation would:
- Replace the existing Otterspace badge-based mechanism with a Hats tree
- Expand who is able to signal influence within Grants to include core developers from other Radworks Orgs (Radicle & Drips), in addition to past grantees
- Ensure better accountability of the Grants Committee to serve their community-mandated purpose by allowing trusted community members to elect/remove Committee members
We imagine the mechanism to look something like this:
Roles & Authorities:
Utilizing the modularity and flexible customization of Hats, we want to automate the claiming/removing of Hats as often as possible.
Top Hat:
- Would first be created by individual (e.g. bordumb) but ownership would be transferred to Radworks community
- Authorities: Create new “child” Hats within the Grants Org tree, ability to dissolve/remove and child Hats (i.e. the DAO would have the ability to dissolve this mechanism if they choose)
Grants Lead:
- 1 Hat
- Authorities: Ability to create “child” Hats within the Grants Org tree
- Claimability: Assigned by the Top Hat to the grants lead
Grants Committee:
- Total of 12 (TBD) Hats
- Authorities: Hat wearers are also signers of the Grants Committee multisig
- Claimability: First round manually distributed, thereafter self-claiming via result of offchain election (Jokerace)*
Past Grantees:
- Unlimited number of possible Hats
- Authorities:
- Signaling support/disapproval for new grant applications
- Signaling support/disapproval of Grants funding categories determined in annual Org proposals
- Elect/remove a member of the Grants Committee
- Claimability: Manually distributed by Grants Lead (for now).
Radworks Devs:
- 1,000 (can be increased if needed)
- Authorities:
- Signaling support/disapproval for new grant applications
- Signaling support/disapproval of Grants funding categories determined in annual Org proposals
- Elect/remove a member of the Grants Committee
- Claimability: Manually distributed by Grants lead (for now)
Processes:
Grant Application process: This mechanism would not change the existing process, it would simply allow more contributors to have influence in the decision making process. The application platform would remain on Discourse.
Signaling to Grants Committee: The off-chain signaling of support/disapproval of grant applications would likely remain on Snapshot.
Distribution of Grants from Committee Multisig: The Grants Committee will continue to use Gnosis Safe to execute final onchain vote / distribute grants to grantees.
Election of Grants Committee: We imagine hosting elections for the Grants Committee on Jokerace. The Jokerace Eligibility Module enables the winners of offchain elections to result in gaining or losing access to a Hat. (See forum post outlining this in more detail). This will grant the community the ability to hold Grants Committee members accountable more directly.
Future Iterations
Future iterations will focus on dog-fooding Radworks tooling, increasingly integrating Radicle, Drips and even $RAD into the application review mechanism. This includes moving all Grants documentation over to Radicle, having the entire application process take place on Radicle (instead of Discourse/github), and increasingly paying grantees in $RAD.
In addition, I am helping facilitate preliminary talks between Hats and the Radicle Integrations & Tooling Org to explore Hats-gated repositories on Radicle. This would allow for more permissionless access to private repos via Hat holdership based on specified and verifiable credentials, rather than having to manually add someone to repos. More information on this to come in the form of a forum post over the coming months.
Experiment Sandbox
The structure and nature of the Grants Org naturally provides a great model to experiment with this type of tooling and expansion of influence on currently more centralized decisions within the Radworks ecosystem. If this experiment goes well, we can look at expanding the use of Hats across Radworks to empower stakeholders with clear roles and new ways to influence decisions across the ecosystem. Plus - any tree can be adopted into another tree - meaning if a broader mechanism for Radworks is ever set up, the existing Grants tree could be added to a larger Radworks tree.
We can also experiment with how we can incorporate and further expand the distribution and holding of $RAD with this mechanism. For example, requiring a Hat claimer to hold any or a specific amount of $RAD at any given time in order to claim or retain a Hat (via ERC20 Eligibility & Eligibility Module). Another idea could be that the longer someone holds a Hat and actively uses it (e.g. actively participates in signaling opinion towards new grants proposals) could qualify them to receive $RAD as a reward for their persistent participation.
Feedback 
There is currently a larger effort to upgrade the Grant’s program in various ways to fit the needs of grantees and find ways to get more involvement from key stakeholders within the Radworks ecosystem. To align ourselves with the timelines of these efforts, we would appreaciate feedback on this model by June 15th.
- Do the efforts of this initiative to update and expand the distribution of influence mechanism within Grants resonate with you? How important is it to the community to decentralize power within the grants program?
- For core developers, do you see yourself participating in this signaling mechanism? Why or why not?
- Is there anything that is unclear about the mechanism, how badges would be distributed or what authorities they would have?
A huge thank you to @bordumb and @spengrah from the Hats team for their input on this draft!