Onchain Atlas

Hats Protocol

A non-upgradeable protocol that encodes organizational roles as revocable, non-transferable ERC-1155 'hats' arranged in admin trees, letting DAOs delegate authority programmatically instead of socially.

▶ Run interactive simulation animated mechanism with editable parameters

Statusongoing
Launched2023-07-11
ChainsEthereum, Optimism, Arbitrum, Polygon, Gnosis Chain, Base, Celo, Avalanche C-Chain, Scroll
Mechanismshierarchical-role-trees, non-transferable-erc1155-tokens, eligibility-modules, toggle-modules, revocable-delegation, deterministic-create2-deployment, tree-linking-grafting
Official sitehttps://www.hatsprotocol.xyz/
Project X@hatsprotocol (verified_by_official_website)
FoundersSpencer Graham (@spengrah), nintynick (Nick) (@nintynick_), David Ehrlichman (@davehrlichman)

How it works onchain

Diagram of how Hats Protocol's mechanism worksOpen full-size diagram
Original diagram derived from this entry’s researched mechanism description.

Summary

Hats Protocol is an onchain roles-and-permissions primitive for DAOs and other internet-native organizations. It represents each role as a "hat" — a non-transferable token conforming to the ERC-1155 interface — arranged in a hierarchical tree where every hat's admin is another hat. Wearing a hat grants whatever authorities the organization has attached to it (multisig signing rights, token-gated access, budget streams, moderation powers), and hats can be programmatically granted, evaluated, and revoked. Built by Spencer Graham (previously DAOhaus/Raid Guild), nintynick, and David Ehrlichman, the v1 contracts were audited twice (Trust Security, February 2023; Sherlock, May 2023) and the final v1 was deployed on July 11, 2023 at the same CREATE2 address (0x3bc1...d137, v1.hatsprotocol.eth) across Ethereum mainnet and many L2s/sidechains. The protocol is deliberately non-custodial, non-upgradeable, and AGPLv3 open source. Its core thesis: DAOs fail not for lack of voting mechanisms but for lack of legible, accountable, revocable delegation — roles should be first-class onchain objects, not entries in a Notion doc.

Design (Mechanism)

  • Hat trees. A hat's identity is a structured uint256: the top 4 bytes identify the "tophat" (tree root, typically held by the DAO itself), followed by up to fourteen or fifteen 16-bit level chunks. The admin of every hat is another hat higher in the tree, so authority to create, assign, and modify roles is itself delegated through roles — recursion as an org chart.
  • Non-transferable ERC-1155. Hats conform to the ERC-1155 interface (so existing token-gating tools recognize them) but wearers cannot transfer them; they can only renounce. This makes hats function as revocable credentials rather than assets, deliberately breaking full ERC-1155 compliance (no safe-transfer hooks).
  • Eligibility modules. Each hat can point to an eligibility contract (or a human/multisig address) that rules on whether a wearer is eligible and in good standing. Ineligibility dynamically zeroes the wearer's balance — revocation without a transaction. Modules can encode staking, elections, term limits, or subjective review.
  • Toggle modules. A separate contract or address controls whether a hat is active at all, enabling automatic sunsetting of roles (e.g., season end, quorum failure).
  • Mutability controls. Hats can be created mutable (admins can change supply, modules, details) or immutable (credible commitment that a role's powers cannot be silently altered).
  • Tree linking ("grafting"). Whole trees can be linked under another tree's hat, letting subDAOs nest under parent DAOs while retaining internal structure.
  • Composability layer. Authorities attach via a periphery ecosystem: Hats Signer Gate (hat-gated Safe multisig signing), token gates, DAOhaus Moloch v3 share allocation, streaming/payment integrations, and later modules for Farcaster account delegation and AI-agent permissions.

Outcome

Ongoing and adopted, though as infrastructure rather than a consumer phenomenon. The official site claims adoption by "over 50 top DAOs"; documented users include Raid Guild (hardening core roles and departments after outgrowing "social memory"), DAOhaus-ecosystem Moloch DAOs, and numerous Optimism-ecosystem and treasury-ops teams. The team launched a "protoDAO" on September 21, 2023 to begin progressively decentralizing governance of the protocol and its periphery. The core v1 contract has operated since mid-2023 without a known exploit (two pre-launch audits; a v1.0 deployment from March 2023 was deprecated and redeployed in July 2023 after a community-found edge case in tophat linking). No token has been launched as of last verification, and no protocol fee is extracted at the contract level, so "commercial" success is hard to measure; success to date is measured in integrations and persistence. Later development expanded toward AI-agent role management (e.g., MCP-based tooling), extending the same permissions model to non-human agents.

Why it worked

  • It solved a real, unglamorous problem. DAOs had governance tokens but no native way to express "who is responsible for what, with which powers, until when." Hats made delegation legible and revocable, directly addressing the accountability gap that plagued 2021-era DAOs.
  • Standards-adjacent design. By conforming to the ERC-1155 interface, hats worked instantly with existing token-gating and wallet infrastructure, giving integrations for free.
  • Credible neutrality. Non-upgradeable, non-custodial, feeless, same address on every chain — organizations could build authority structures on it without platform risk, a point the founders emphasized repeatedly.
  • Modular periphery. The eligibility/toggle module pattern kept the core minimal while allowing arbitrary policy logic at the edges, so the protocol never had to predict every governance style.

Limitations and criticisms

Hats' addressable market is inherently narrow: it launched into the post-2022 contraction of the DAO sector, and adoption remains deep but concentrated in governance-native communities (Raid Guild, DAOhaus, Optimism ecosystem) rather than mainstream organizations. The absence of a token or fee model means no direct value capture at the protocol layer; sustainability depends on the team/protoDAO funding model rather than protocol revenue. Encoding an org chart onchain also carries a real cold-start cost — upfront design effort that informal teams tend to defer until dysfunction forces the issue, which caps how fast the protocol can spread beyond already-organized teams. And because eligibility/toggle logic lives in a modular periphery rather than the audited core, the security and reliability of any given hat's revocation ultimately rests on whichever module an organization chooses — a flexibility/assurance trade-off the core team cannot fully control.

Lessons

  • Roles, not just votes, are the missing DAO primitive. Token voting allocates decisions; it does not allocate responsibility. Making delegation explicit, bounded, and revocable is what lets DAOs actually execute.
  • Revocability requires breaking transferability. Credentials that can be sold are not credentials. Deliberately violating full ERC-1155 compliance (non-transferable, dynamic balances via eligibility checks) was the right trade against standards purity.
  • "Authority as a tree" composes. Making every role's admin another role turns governance into a recursive data structure — subDAOs, departments, and term-limited seats all fall out of one mechanism plus modules.
  • Neutral infrastructure earns trust slowly. Non-upgradeable, feeless, same-address-everywhere deployment maximized trust and integrations but deferred any business model — a viable choice only with patient funding.
  • Ship after audits, and be willing to redeploy. Deprecating the March 2023 v1.0 over an edge case, then redeploying a fixed final v1 in July 2023 before broad adoption, was cheaper than immutability regret later.

Redesign (EDITORIAL — hypothesis, not fact)

This section is a hypothesis, not a record of fact. A redesigned Hats might attack the cold-start and sustainability problems directly. First, ship "org templates as one transaction": audited, forkable tree presets (working group, elected council, seasonal pod) claimable via multicall, so a small team gets a working accountability structure in minutes rather than a design project. Second, add an opt-in, module-level fee switch — e.g., a small fee on premium eligibility modules (elections, staking-slashing) flowing to a protocol treasury — preserving the feeless neutral core while giving the protoDAO durable revenue. Third, lean into the agent economy: hats as the canonical permission wrapper for AI agents (spend limits, scoped API/tool authority, human-held admin hats with instant revocation) would position the protocol where organizational headcount is actually growing. The main risk of this redesign is that any fee or productization erodes the credible neutrality that drove adoption in the first place; the fee switch would need to be immutable-by-default-off at the core layer.

Sources

  1. Hats Protocol Docs — primary (docs)
  2. Hats Protocol v1 core contracts (GitHub README — mechanism, authors, audits) — primary (contract)
  3. Hats Protocol v1 release (2023-07-11, deployment addresses) — primary (contract)
  4. Hats Protocol v1.0 release (2023-03-31, deprecated) — primary (contract)
  5. Hats Protocol official site — primary (docs)
  6. Hats Protocol contract addresses (docs) — primary (docs)
  7. Hats protoDAO: How to Join the Community & Help Build Hats — primary (governance)
  8. RaidGuild case study — primary (analysis)
  9. Audit reports (Trust Security Feb 2023; Sherlock May 2023) — primary (audit)

Related experiments

Last verified: 2026-07-26 · Spot an error? Suggest a correction