[Discussion] [OBRA] Formalizing the Guardian Role onchain with Hats Protocol - Hats Protocol

This post follows the “[Template] Initiative proposals” template found here

  1. Aligned strategy: Which pre-approved strategy is this initiative driving forward?

[Strategy 5] Increase governance participation

  1. Funding request: What resources are being requested from SafeDAO in USDC?

$10k USDC

We are open to receiving a portion of the compensation in ETH or SAFE tokens (if/when the SAFE tokens become transferable).

Please note: our philosophy on fees is first and foremost aligned with our goal of creating and decentralizing Hats as a fully self-sustaining and non-extractive public utility. We envision a minimal protocol fee may be a good approach to support this in later versions.

We’re not sure what the long-term fee model looks like yet, but charging services fees with existing customers in the short term has been helping us 1) understand the level of value we are delivering, and 2) ensure partners have skin in the game while we invest large amounts of time and energy into manual implementation work.

  1. If applicable, upfront funding: Indicate if upfront funding is needed.

$2k USDC requested upfront

  1. Relation to budget: State the requested funding as a percentage of the total initiative budget (e.g. if you ask for 50k for Strategy 1: 25%)


  1. Metrics and KPIs: Which metrics and KPIs will the initiative be measured against?

This initiative will particularly impact the following two metrics/KPIs identified in [Strategy 5] Increase governance participation:

“Creation of tooling with believable impact on transparency” – this initiative will increase transparency of the Guardian role by providing the role with an onchain source of truth. Through the Hats interface, anyone will be able to see who is holding the role at a given time, along with the responsibilities, authorities, and eligibility criteria of the role. When Guardians reach the end of their term, their Guardian hats will be automatically toggled off and they will immediately lose any associated permissions that are connected onchain or by token-gate. If any Guardians become ineligible for the role (e.g., do not maintain a certain token balance; do not stake above a certain threshold), they will automatically lose their hat along with any associated permissions.

“Impact on facilitation of governance process” – this initiative will save time and money by automating time-consuming community management tasks, increase decentralization by minimizing trusted actions and disintermediating human managers, and reduce wasted motion by simplifying Guardian onboarding and offboarding

  1. Initiative description: What is the initiative about?

Hats Protocol is a platform for programmatically creating and managing DAO contributor roles, responsibilities, and permissions. Hats empowers decentralized organizations to get things done by making sure people, teams, and code have everything they need to do their best work, while holding them accountable via onchain role revocation mechanisms.

We have heard from André Geest that SafeDAO is seeking to bring their Guardian role onchain to advance its objective of “increasing governance participation.”

As the founders of Hats Protocol, we propose working with SafeDAO to:

1. Formalize the Guardian Role onchain

  • enhancing transparency and legibility of the role
  • concretizing the responsibilities and authorities of the role

2. Automate the granting and revocation of role-specific permissions

  • Set eligibility criteria for Guardians based on custom logic (e.g., allowlist, election results, token holdings, etc.)
  • Guardian role can be claimed by or granted to only those who meet the eligibility criteria
  • Automated revocation of Guardian permissions when an address falls out of eligibility
  • Permissions provided by the Guardian role (i.e. wearing an active Guardian hat) may include:
    • Discord role/ channel access
    • Telegram group access
    • Voting: proposal creation rights, voting power, specified voting weight (e.g., via Snapshot and oSnap)
    • With the optionality to add additional onchain or offchain permissions as needed

3. Enable automatic expiration of the role after a specified term limit

  • Configure the Guardian role and its associated permissions to automatically expire for a given address after a specified interval, i.e. a “season”
  • Set term limits for Guardians

We’ll set up your Hats tree exactly as desired, on whatever chain you prefer, and get your hats connected to the right authorities and minted to all the right addresses.

Potential follow-on initiatives:

In addition to the standard implementation detailed above, we might also consider upgrading your Hats Tree with one or more of the following options that would include custom development work from the Haberdasher Labs team:

A. Mini App: A custom front-end specific to SafeDAO Guardians. This could displays a user’s:

  • Wallet address and ENS
  • Guardian hat
  • Hat status along with the expiration date of the role
  • Voting power
  • Specific permissions associated with the role with links to access those permissions,
  • Any live “action items” they are responsible for
  • Any other critical information

B. Discourse Integration: We can also investigate the technical feasibility of a Discourse integration to display the Guardian hat status and voting power directly from within Discourse.

C. Custom Hats Modules: Use case-specific modules that read any onchain data of your choice in order to automate hat granting, revocation, and deactivation

Any custom solutions developed such as the above will need to be scoped and aligned with the DAO’s strategy to increase governance accessibility and tooling. If interested, we would love to have another conversation about these ideas to create a more fully fleshed out scope.

  1. Current status: Does the offering (product/service) already exist or is the funding used to create it?

Hats Protocol already exists as a fully deployed and audited protocol, a modules registry, and a front-end app. For more details on the Hats Protocol stack, see here.

  1. Risks: What risks does the initiative entail?

The primary risks we see are as follows:

  1. Governance facilitators do not continue to maintain the Guardian role onchain, causing the onchain role details to become out of date. To address this risk, we will be available to quickly address any questions that may arise, while providing you with a suggested governance process to make sure that the roles, responsibilities, and authorities for your DAO are always current.
  2. Hats does not currently integrate with Discourse roles and badges, which could lead to some added work for governance facilitators to ensure the data found on Discourse is up to date. As a follow-on scope, we can investigate the technical feasibility of a Discourse integration to display the Guardian hat status and voting power directly from within Discourse.
  3. The eligibility criteria you seek for the Guardian role is not yet expressed in a Hats module. Hats Modules are programmable extensions for roles. Modules can be connected to hats to expand their functionality, such as automatic granting/revocation and activation/deactivation based on specific conditions. Currently available modules enable DAOs to automate the granting and revocation of roles and permissions based on Token and NFT holdings (ERC20, ERC721, ERC1155), active subscriptions, election results with term limits, reputation scores, staking requirements to receive a role, allowlists, seasonality, specific roles or other hats, and an onchain signature of an agreement.

If you’re interested in using a module that does not already exist, we can help with custom development as needed, and can also support you to develop your own custom modules. We’ve created an open-source platform where anybody can develop and deploy a Hats Module permissionlessly. To help make this easier, we’ve built a factory contract that makes deploying new instances of a module quick and cheap. To be deployable via Hats Module Factory, a module needs to support some basic functionality. We’ve created a suite of dev tools to make this easy for builders: the HatsModule base contract contains everything necessary to be compatible with the factory, and the hats-module-template repo is the fastest way to get started developing a new module.

  1. Timeline and milestones: Provide a detailed timeline or roadmap, include key milestones

This process will take between 3-6 weeks and includes the following deliverables:

Structure design: Work with the SafeDAO governance team to craft a structure that maximizes capture-resistance for SafeDAO now and into the future. We will start with the Guardian Role as the beginning of the Hats Tree and expand over time from there.

  • Initial meetings to understand SafeDAO’s exact needs
  • Map out the technical requirements for bringing the Guardian role onchain using the Hats Protocol
  • Clarify the desired specifications of the Safe DAO Guardian role, including:
    • Responsibilities
    • Authorities
    • Accountabilities, including eligibility and revocation criteria
    • Deactivation and reactivation criteria
    • Compensation
  • Potentially also looking at bringing the Grants Council and Grants Council Member Role onchain

Eligibility & automation: Determine the right set of eligibility and toggle modules to be used for automated hat granting, revocation, and deactivation (e.g., elections eligibility), thereby drastically simplifying your group’s onboarding and offboarding processes and making best use of your group’s onchain data and assets.

  • Determine the right Hats Modules and hatter contracts to deploy for the Guardian role
  • Leverage these Modules to automate hat claiming, granting, revocation, and deactivation based on your organization’s onchain data where relevant

Implementation & deployment: Deploy desired eligibility & toggle modules currently available for your Hats tree and deploy your Hats tree to your desired chain, complete with detailed description of the role, responsibilities, and authorities associated with each hat

  • Start with a testnet version for feedback & iteration
  • Testnet implementation QA, including a trial run of the election process
  • Migrate to mainnet when ready
  • Mainnet implementation QA

With the modules coming out with this release, you can already automate the granting and revocation of roles and permissions based on:

  • Token and NFT holdings (ERC20, ERC721, ERC1155)
  • Active subscriptions
  • Election results with term limits
  • Reputation scores
  • Contributions
  • Staking requirements to receive a role
  • Allowlists
  • Seasonality
  • Specific roles or other hats
  • Onchain signature of an agreement
  • Combination of multiple criteria listed above

Maintenance: We’ll be available to quickly address any questions that may arise, while facilitating a governance process to make sure that the roles, responsibilities, and authorities for your group are always current.

  • Immediate synchronous support for urgent issues
  • 24-hour turnaround asynchronous support for information inquiries
  • Availability to help you update existing hats, create new hats, and iterate on your Hats tree as needed and on a regular cadence
  1. Initiative lead: Who is the accountable initiative lead? (individual or organization)

Haberdasher Labs, Inc., consisting of Spencer Graham, Nick Naraghi, and David Ehrlichman.

  1. Team: How many individuals in total will be working on this initiative and what role do they have? Please provide a brief background of the team members, highlighting their relevant experience and expertise

  • Spencer Graham — implementation, smart contract development, and support
    • Hats Protocol: Co-founder, Protocol Lead Hat & Technology Lead Hat Wearer
    • Previous work: core contributor to DAOhaus, member of Raid Guild, MetaCartel, and groundw3rk, contributor to clr.fund
  • Nick Naraghi (nintynick) — implementation, support, and stakeholder education
    • Hats Protocol: Co-founder, Strategy Lead Hat & Growth Lead Hat Wearer
    • Previous work: co-founder of EvenGov DAO, member of Raid Guild, groundw3rk, DIA, co-founder of an AI startup backed by 500 Startups
  • David Ehrlichman — implementation, support, and stakeholder education
    • Hats Protocol: Co-founder, Ecosystem Lead Hat & Marketing Lead Hat Wearer
    • Previous work: author of Impact Networks, co-founder of Converge, consultant to 50+ multi-stakeholder collaborations around the world, lead organizer for DAO Camp, founding coordinator of groundw3rk, contributor to EvenGov
  • Ido Gershtein — implementation, technical infra development, and support
    • Hats Protocol: Integrations Developer Lead Hat Wearer
    • Previous work: Researcher at DAOstack, contributor to DAOstar, Machine Learning software developer at Ceva
  • Scott Herren — builder
    • Hats Protocol: Client App Lead
    • Previous work: Seed Club, RabbitHole, RaidGuild, DAOhaus, MetaCartel, PoolTogether
  1. Additional support/resources: Are there any resources (non-financial) requested from the Safe Ecosystem Foundation or the core contributors?

We request 2-3 calls and ongoing asynchronous communication with André and/or the SafeDAO governance team to support the design and implementation details for this initiative.


I am a big fan of Hats and believe improving the Guardian role is essential.

I’ve noticed that most Guardians have not been very active in the Guardian channels or the Safe Forum. I can imagine separating more active Guardians from the rest and potentially rewarding them retrospectively with vested SAFE thought, comparable to Gitcoin’s citizen rounds.


Big fan of the Hats Protocol and team, would definitely support this initiative.



Defining and automating onchain, contribution tracking, accountability, and access controls to tools, rights, and platforms is a big opportunity to increase current DAO participation and prepare for large and fast paced growth as we move into the next market cycle.

Tracking Discourse forum contributions that impact roles, access controls, potential rewards, etc, is a priority as the majority of research, sharing info, and consensus building happens on the forum.

Onchain community tools market

  • Are there public case studies to share from projects, communities, DAOs, and companies that have proven value using Hats Protocol?
  • It’d be helpful to know what the best alternatives to Hats Protocol are?
    • What do the alternatives do uniquely well?
    • What does Hats Protocol do uniquely well?

Timeline and milestones

The “Split Delegation - Gnosis Guild” proposal does a great job of clearly and quickly visualizing the timeline and milestones in a table format. Moving to this format would help future readers quickly understand the expected outcome, timeframe, and funding request.


These are great questions – we’ll be presenting a demo on Wednesday and will share some cases studies and thoughts on alternatives then. We’ll then follow up with a recap here with highlights and answers to your questions.

1 Like

Thanks for these questions @adamhurwitz.eth. I responded to these in the draft thread, also copying below:

Here are some examples of Hats implementations referenced on the OBRA proposal review call today:

TreasureDAO: granting community representatives (called ARC Liaisons) special permissions to represent TreasureDAO in Arbitrum governance, both via onchain votes in the Arbitrum Governor (via Tally) and offchain signaling in Arbitrum’s Snapshot space: Tree #6 on Arbitrum One | Hats Protocol

RareDAO: streamlining the process of granting and transferring multisig signing authority from one set of committee members to another with each election: https://app.hatsprotocol.xyz/trees/1/22?hatId=

More details on Hats, authorities, modules, and the Hats app can be found in the docs: https://docs.hatsprotocol.xyz/

Regarding possible alternatives, generally we’ve seen:

  1. generic badges, attestations, or onchain signifiers - not purpose-built for roles, lack robust admin relationships and onchain accountability
  2. big spreadsheets or diagrams of multisigs with various signers - hard to keep organized, lack of transparency, not good for delegation to a single person
  3. manage role offchain - serious capture vector, lack of transparency
1 Like