The Organizational Graph Protocol. Encode your organization's roles, agents, and permissions into a programmable graph with Hats Protocol
hello@hatsprotocol.xyz
RaidGuild is increasing its effectiveness as a decentralized organization by automating contributor permissions, accountabilities, and role-based compensation and "leveling up"
Author: Elliott Conway
RaidGuild is one of the oldest dev shop DAOs in the web3 space, with nearly 200 jobs (called “raids”) under its belt. However, since crossing Dunbar's number, the DAO required a clearer and more accountable way of operating. Primarily organized through Moloch DAO smart contracts and a Discord server, RaidGuild reached a level of complexity where these tools alone no longer suffice in understanding who is responsible nor who is qualified to hold different roles and permissions.
Today, RaidGuild uses both Hats Protocol and CharacterSheets (a gamification layer on top of Hats, built by RaidGuild) to harden core roles and "departments" in the guild, and clarify expertise. Through this, RaidGuild hopes to reduce its reliance on social memory and social coordination throughout its operations. Importantly, it also hopes to do this without sacrificing the somewhat irreverent and anarchic culture that is so key to its identity.
As a dev shop DAO, many components are required to keep things operating smoothly:
Currently, RaidGuild has too many members to operate without an excessive amount of social coordination and memory. Since this large influx of people, members have had to ask around in Discord to find out who is still active, who is qualified for certain raids, and who is responsible for a particular core role.
Many attempts to remedy this have come and gone. Some tools are too monolithic, some lack key integrations, and some had the potential to gridlock RaidGuild into a corporate structure that it naturally avoids. The guild needed something that was easy to opt into, ready to integrate with other tools, and ultimately still fun.
Enter Hats Protocol. While before, roles and expertise certainly existed; now, they are finally visible. By using Hats to formalize roles on-chain, it not only gives others clarity as to who is doing what, it also ensures the doers know exactly what they are responsible for.
Hats also enabled RaidGuild to set up payment streams to people in key positions, which the DAO has historically been against doing due to a lack of clarity in the role. The hat wearer now knows more precisely what their job is, what their pay is, and when their term is up. At the end of each quarter, the hat wearers are assessed and re-elected if the job is done well.
CharacterSheets (think of a DnD character sheet) logs member activity on-chain, and expresses it visually in the form of classes, XP, levels, and items. Notably, under the hood, the permission structure is just a Hats tree: players, characters, GameMasters, and admins each have their own hat and their own set of scoped abilities.
As raids are completed, XP is distributed to those who worked on the raid, leveling up their characters' classes based on the kind of work they did. This not only helps track the accumulation of expertise in a given skill, but it also gives a decent proxy for who is still active (based on when they last received XP).
While Hats brings clarity and accountability to roles within the guild, it also has the extensibility to allow something like CharacterSheets to make the structure fun and gamified.
RaidGuild is also experimenting with a concept called the Elder Hat, which can be seen as a way to automatically promote members to core roles. Right now, a core role is given a hat, and thus certain permissions (like admin rights) in the software RaidGuild uses via a manual election. With the Elder Hat, this role can be earned automatically via class level in CharacterSheets. For instance, if a member reaches level 12 as a Warrior (frontend engineer), this could qualify them for a Warrior Elder Hat, giving them higher privileges in the RaidGuild Github organization. This again takes something that is now social and moves it into a rule-based and automatic process.
As RaidGuild continues to build out CharacterSheets, Hats will necessarily remain a core component. One potential future feature is the concept of Network Characters (NPCs) in CharacterSheets, which can be viewed as a smart contract with partial GameMaster abilities.
Currently in RaidGuild, a member's character can receive XP for attending Discord meetings. Under the hood, this is triggered by a Discord bot wearing a GameMaster hat. However, this GameMaster hat gives the bot an excessive amount of power (for instance, the ability to give a character any amount of XP).
In the future, there could exist a market of NPCs that have a controller (like the Discord bot), internal restrictions on what they can do (such as preventing more than 100 XP per hour from being minted), as well as a GameMaster hat. In this way, anyone creating a CharacterSheets game could build out the mechanics of their game simply by giving a GameMaster hat to their choice of NPCs. Want to add an item shop to your game? Just find the Shop Keeper in the NPC market, and install it by giving it the GameMaster hat.
Additionally, as noted earlier, the Access Control List core of a CharacterSheets game is just a Hats tree. Therefore, in the future, CharacterSheets games could be created by importing an existing Hats tree, allowing any org with a Hats tree to gain a gamification layer on top of it. While this feature does not exist today, any organizations that require a level of structure while remaining fun are invited to fork either CharacterSheets or the RaidGuild Hats tree to build on the creative organizational structure that RaidGuild has pioneered.