Summary
Introduce a governance process for managing inclusion of Hats Protocol Trees within KlimaDAO and delegating/revoking specific permissions.
Establish an initial set of roles and permissions, progressing KlimaDAO’s organizational structure and establishing budgets and compensation models for these initial roles.
Motivation
Historical Context: Since launch, KlimaDAO’s internal organizational structure has relied on fairly informal governance processes and ad hoc permissioning. For instance, when a new contributor is onboarded, they are individually granted access to systems they require to complete their work (such as Notion, GitHub, or specific Discord roles).
This entails a great deal of manual toil to onboard and offboard contributors - as well as limiting transparency and accountability, which are core to KlimaDAO’s values and key to progressive decentralization.
Characteristics of Hats Protocol: Hats Protocol provides a flexible and composable solution for managing role-based permissions via verifiable on-chain mechanisms.
Implemented as a set of smart contracts, a Hats Tree represents a set of revocable on-chain roles in the form of an ERC-1155 token called a “Hat”, and relationships between Hats which define how roles are granted and revoked.
Proposal
# Permission Management Process
Addition of new Hats Trees and creation of new Hats within a given Tree both require a subsequent KIP governance proposal to be passed through the existing KlimaDAO governance process. Minor adjustments to permissions for existing roles with clearly defined authorities do not require a subsequent proposal.
For example, assuming this KIP is adopted, migrating the DAO’s collaborative knowledge base from Notion to Charmverse and granting existing Hats with access to edit the knowledge base will not require a governance vote, since that authority is explicitly delegated to the Top Hat as laid out in the Proposed Initial Permissions section.
# Proposed Organizational Structure
Top Hat:
- Assigned to a new multisig composed only of Directors and the President of the Klima Foundation
- This multisig is made of of signers who have legal obligations to the DAO’s legal entity
- Ability to manage the KlimaDAO ENS domain and the Snapshot instance
- Ability to administer the bounty board (currently Dework)
- All administrator-level permissions for KlimaDAO’s off-chain operational systems, as well as operational discretion to determine which systems to use for various DAO functions
- Ability to grant/revoke the DAO Signer Hat. Existing DAO Wallet multisig signers will be grand-fathered into the DAO Signer Hat
DAO Signer Hat:
- Grants signing authority on the DAO Wallet Multisig
- Executes monthly budget requests created by Protocol Team, once approved by Klima Foundation Director or -President via off-chain review process
Protocol Team Hat:
- Access to internal communications channels and services (e.g. Discord role, Notion pages, Google Workspace)
- Ability to grant and revoke the Bounty Hunter Hat and Change Reviewer Hat(s) unilaterally (i.e. a single Protocol Team Hat wearer can grant or revoke these Hats)
- Ability to vote on internal policy decisions (e.g. bond capacity) via a dedicated Snapshot Subspace for which only holders of the Protocol Team Hat can vote
- Ability to grant/revoke Marketing Manager Hat via majority vote in a dedicated Snapshot Subspace
- Proposes monthly budget for contributor compensation and expenses, which requires majority approval via an off-chain vote amongst protocol team members, with all transactions recorded on-chain.
- Protocol Team members are added and removed via token-based voting in a Snapshot Subspace, where holders of the Protocol Team Hat, Director Hat, and President Hat have the right to vote
Klimate Review Committee (KRC) Hat:
- Upon passing, DWG members will be converted to KRC members and protocol team members will fill in any missing KRC seats until a sufficient number of community members apply and are admitted to the KRC.
- Ability to add/remove wearers of the KRC Hat itself via majority vote, with potential members of the KRC submitting applications per KIP-35: https://forum.klimadao.finance/d/219-kip-35-decentralizing-kips-snapshot
- Voting on advancing specific RFCs to a KIP via a Snapshot subspace
Marketing Manager Hat:
- Access to Twitter, LinkedIn, and other media channels
Change Reviewer Hat(s):
- Set of one or more Hats manually granted by the Top Hat to known key contributors to the KlimaDAO codebase who are trusted to review and merge code within a specified domain
- Grants access to a KlimaDAO GitHub Organization Team for reviewing and merging code changes in a specific set of repositories, or similar change review permissions in other systems like Gitbook.
- For instance, we currently have full-stack and frontend contributors who work in the primary
klimadao
application repo, plus another group of data contributors who work on a separate set of repos. So there would be two Code Reviewer Hats initially: Data Code Reviewer and App Code Reviewer.
- Within the scope of this proposal, a similar Change Reviewer Hat could be created to govern write access to the KlimaDAO documentation, since it is maintained as a GitHub repository via Gitbook.
Bounty Hunter Hat:
- Access to bounty hunter communications channels and services (e.g. Discord channels, Dework board, Notion pages, Google Workspace)
- Ability to submit bids for bounty work on the KlimaDAO bounty board.
Snapshot Poster Hat:
- Grants the holder the ability to create proposals on Snapshot under the KlimaDAO space
Permissions managed by Protocol Team.
Compensation
KlimaDAO’s spending on OpEx is defined by the Green Ratio. At any given point, 10% of DAO assets are earmarked fund OpEx.
OpEx includes:
- Expenses
- Contributor remuneration
- Bounty costs
- Marketing costs
- Listing costs
- Etc
The Green Ratio effectively restricts the amount of OpEx spending allowed, and it supersedes the previous process of defining expenses.
The Green Ratio defines available funding, but not how it should be spent. In the precedent established by KIP-19, the Core & Stewards teams defined compensation.
Core and Stewards are now effectively replaced by the Protocol Team.
Under this proposal, monthly compensation is first proposed by the Protocol Team, then approved via a majority vote each month.
Initial Protocol Team members (9):
Existing foundation directors (2)
Existing foundation President (DJ)
TheLawyer
0xymoron
Optima
Cujo
Peter
Marcus
The last funding request from June approved the spending of $188k/mo for payroll, and $12k/mo for other expenses.
In the current protocol state, overall spend has trended between $50k/mo - $75k/mo. Expenses have been cut by 62.5% - 75%, depending on the month.
The protocol team is lean and optimized to steward KlimaDAO through the coming decade.
Considerations
Only existing contributor roles are modeled in this initial set of permissions. Permissions associated with other stakeholders (such as community members who could complete specific actions, or additional working groups or standing committees) can be added in future via the governance process outlined above.
Existing contributors who are already members of the group of people eligible to be granted each Hat under the status quo operating model will be granted their corresponding Hats during creation of the initial Hats Tree. For example, an initial member of the Protocol Team that currently has write access to several KlimaDAO GitHub repos, as well as editing access to the Gitbook documentation, would be granted the Protocol Team Hat and the appropriate Code Reviewer Hats.
Wherever possible, Token Gating will be used to implement this proposal’s delegated roles. However, even just ratifying this permissions-set via KIP clarifies the roles and structure of the DAO in a binding manner.
Furthermore, there is included on this forum post an Appendix of known token-gated implementations for key permissions like GitHub, Discord, and Notion. However, some other permissions may be difficult or impossible to token-gate at the moment - but new token-gating systems are being developed all the time to mitigate this over time.
Finally, since all Hats in the initial tree can be revoked by the Top Hat, any permissions for specific existing systems which are explicitly delegated to Hats in this tree, but cannot be easily token gated at the moment, are implicitly under the control of the Top Hat, who shall delegate these permissions as appropriate through the existing manual processes.
# Implementation Details
NOTE: the Top Hat will be temporarily assigned to a dedicated Deployer address (0xDdfF75A29EB4BFEcF65380de9a75ad08C140eA49) for the convenience of deploying and configuring the initial Hat Tree. Once the initial Tree is created it will be transferred to a multisig whose signers are only Directors and the President of the Klima Foundation.
Snapshot subspaces to be created:
Advancing RFC to KIP (KRC; >60% quorum; majority voting)
Protocol Team Membership (Protocol Team, President, Directors; >60% quorum; majority voting)
Implement token-gating for supported services (see Appendix below) as specified above.
If this RFC advances to a KIP, the following will be provided alongside the KIP to fully specify the Hats Tree to be deployed:
JSON exported from test hat
Calldata to be used to deploy Hats Tree
Links
Hats website: https://www.hatsprotocol.xyz/
MakerDAO Hats Protocol adoption MIP: https://mips.makerdao.com/mips/details/MIP93#sentence-summary
Detailed Hats Creation Spreadsheet: https://docs.google.com/spreadsheets/d/1G4bf-LC4oyrYljA4s_wVkVjXAl5RX7ZYaJiaQNBYyFg/edit?pli=1#gid=1924357179
The proposal will be put to a vote by the KRC for escalation to KIP.
Poll (active when/if escalated to KIP)
For Hats Tree
Against
Abstain
# Appendix: Known Token-Gating Implementations for Key Permissions
GitHub
It is possible to grant permissions to specific GitHub repositories and Organization teams based on connecting to a wallet holding a given token via e.g. Guild.xyz
Discord
Discord roles can be granted based on holdings a Hats token using either collab.land or guild.xyz
Notion
While Notion itself does not yet support token gated access, there are drop-in replacements like Charmverse that do: https://charmverse.io/
Google Workspace
Guild.xyz also support Google Workspace permissions for collaborating on documents
Bounty Board
Dework supports token gating for granting roles: https://dework.gitbook.io/product-docs/guides-for-orgs/setup-your-first-space#settings
Snapshot
Of course, Snapshot is a token gated voting platform so offers a great option for adopting public proposals via on-chain voting for e.g. making decisions within the KRC, or expressing formal opinions voted on by Hats holders, or even giving holders of specific Hats a voting power multiplier: https://github.com/snapshot-labs/snapshot-strategies/tree/master/src/strategies/hats-protocol-hat-id
Safe
Hats Protocol has off-the-shelf functionality for configuring a Safe multisig that allows any holder of a specific Hat to sign transactions: https://docs.hatsprotocol.xyz/hats-integrations/hat-gated-authorities/safe-multisig-signing-authority