---
title: "Hats Protocol"
url: "https://caper.network/wiki/dao-governance/tooling/membership/hats-protocol"
updated: 2026-09-01
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Hats Protocol

|  |  |
| --- | --- |
| **Category** | Roles & permissions infrastructure (onchain org layer) |
| **What it is** | Programmable roles as ERC-1155 tokens ("hats") arranged in an admin tree |
| **Builder / status** | Built by Haberdasher Labs, which [announced on 24 June 2026](https://www.bitget.com/amp/news/detail/12560605475828) that it was closing and handing Hats on as a community public good. Contracts unchanged and non-upgradeable; hosted app and docs reported as funded only [to the end of 2026](https://www.bitget.com/amp/news/detail/12560605475828) |
| **Core contracts** | [Hats-Protocol/hats-protocol](https://github.com/Hats-Protocol/hats-protocol) – last pushed 23 July 2024, and the [project describes v1 as](https://www.hatsprotocol.xyz/) "open-source, well-documented, non-custodial, and non-upgradeable" |
| **Post-handover activity** | No repository in the [project's 75-repo GitHub organisation](https://github.com/Hats-Protocol) has been pushed since 15 April 2026 (checked 13 August 2026) |
| **Composes with** | [Safe](/wiki/dao-governance/tooling/treasury/safe), [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac), [Snapshot](/wiki/dao-governance/tooling/voting/snapshot), [Tally](/wiki/dao-governance/tooling/voting/tally) |
| **Adoption** | Self-reported "trusted by over 50 top DAOs" – treat as directional |
| **Related** | [DAO tooling overview](/wiki/dao-governance/tooling/dao-tooling-overview), [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity), [Execution](/wiki/governance/execution) |

**Hats Protocol** is onchain infrastructure for **roles and permissions** – the layer that answers _who in a DAO is allowed to do what_. Most governance tooling decides _what_ an organization does ([Snapshot](/wiki/dao-governance/tooling/voting/snapshot) for signalling, [Tally](/wiki/dao-governance/tooling/voting/tally) for onchain proposals, [Safe](/wiki/dao-governance/tooling/treasury/safe) for custody); Hats sits underneath them and encodes _who_, turning a job description into a token a smart contract can read. It describes itself as ["roles & permissions for the open internet"](https://www.hatsprotocol.xyz/) and was built as open-source infrastructure by Haberdasher Labs. On **24 June 2026** Haberdasher Labs [announced it was closing](https://www.bitget.com/amp/news/detail/12560605475828) and transitioning Hats Protocol into a community-run public good, citing an inability to reach the network effects and revenue a company needed. What that did and did not change is set out below.

## Hats are role tokens

A **hat** is a role represented as an [ERC-1155](https://eips.ethereum.org/EIPS/eip-1155) token, per the [protocol documentation](https://docs.hatsprotocol.xyz/). When an address holds a balance of one of a given hat, it is a **wearer** of that hat and carries whatever responsibilities and permissions the hat bundles. A single hat can have many wearers up to a `maxSupply`, and – crucially – **hats are not transferable**: a wearer can voluntarily _renounce_ a hat, but cannot sell or send it to someone else. A role is granted by the organization, not traded on a market. Each hat carries a fixed set of [properties](https://docs.hatsprotocol.xyz/for-developers/hats-protocol-for-developers/hat-properties) – `details` (name/description metadata), `maxSupply`, an `admin`, an `eligibility` module, a `toggle` module, a `mutable` flag, and an `imageURI`.

## The Hats tree and admin hierarchy

Hats are linked into a **Hats tree** – a hierarchy that mirrors an org chart. At the apex sits the **Top Hat**, held by whoever holds ultimate authority over the tree: an individual, a multisig, or a whole DAO. Every other hat has an **admin** – a parent hat whose wearers can create child hats, mint them to new wearers, change a mutable hat's properties, and revoke hats that are misused or no longer needed. Because admin authority flows down the tree, a DAO can delegate a branch of responsibility to a working group without handing over control of everything else, and can always reach back down the branch to reclaim it. This is the mechanism Hats calls an **accountability relationship**: authority is delegated but revocable, so a contributor's power lasts exactly as long as the org wants it to.

## Eligibility and toggle modules

Two pluggable modules make a hat _programmable_ rather than merely administered, per the [hat-properties reference](https://docs.hatsprotocol.xyz/for-developers/hats-protocol-for-developers/hat-properties):

- **Eligibility modules** decide, per wearer, whether an address is _eligible_ to wear the hat and remains in **good standing**. An eligibility module can be another contract – a token balance check, a staking requirement, a [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) vote, an offchain attestation – so a role can be granted or automatically stripped by rule, not by a manual transaction.
- **Toggle modules** decide whether the _hat itself_ is active or inactive, affecting every wearer at once regardless of individual standing – useful for time-bounded roles or roles that switch off when a condition lapses.

Whether these can change after creation depends on the `mutable` flag: an **immutable** hat locks its properties permanently, while a **mutable** hat lets its admin adjust them later – the same immutability-versus-adaptability trade-off that runs through DAO design, from [Liquity's](/wiki/daos/stablecoins/liquity) frozen contracts to [governed](/wiki/daos/stablecoins/aave-gho) parameters.

## How it composes with the rest of the stack

Hats is deliberately a _layer_, not an app – its value is that other tools read hats to gate their own actions. The landing page names integrations with [Snapshot](/wiki/dao-governance/tooling/voting/snapshot) (gating who can create or pass certain votes), [Tally](/wiki/dao-governance/tooling/voting/tally) (proposals), Decent (workspaces), and Unlock (identity), and the protocol is commonly paired with [Safe](/wiki/dao-governance/tooling/treasury/safe) multisigs and [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac) modules so that _wearing a hat_ becomes the permission to sign a transaction or trigger a module. The project reports Hats is ["trusted by over 50 top DAOs"](https://www.hatsprotocol.xyz/); as with all self-reported adoption figures, treat the exact count as directional. Its natural place in a treasury stack is alongside execution tooling like [Zodiac](/wiki/dao-governance/tooling/frameworks/zodiac): Zodiac decides _how_ a decision reaches a Safe, Hats decides _who_ is authorized to be part of it.

## What the wind-down actually changed

"Transitioning to a public good" is a phrase that can describe two very different outcomes, so it is worth separating what is guaranteed by the code from what depends on somebody continuing to care. Checked on **13 August 2026**:

- **The contracts are safe, and that is not a promise but a property.** The project's own developer page describes Hats Protocol v1 as ["open-source, well-documented, non-custodial, and non-upgradeable"](https://www.hatsprotocol.xyz/). A non-upgradeable, non-custodial contract cannot be switched off, drained or altered by a company that no longer exists, so every existing hat, tree and eligibility check keeps working exactly as before. This is the good half of the [tooling-discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity) trade, and it is the half most projects do not get.
- **The hosted layer is on a clock.** The wind-down was [reported](https://www.bitget.com/amp/news/detail/12560605475828) as keeping hosted resources online "until the end of the year". The app and documentation both still answer today, but a DAO whose operators reach their roles through `app.hatsprotocol.xyz` should treat that front end as expiring rather than permanent, and should know how to read and mint hats without it.
- **The code has not moved since before the handover.** The core contracts repository has not been pushed since **23 July 2024** – unremarkable for finished, non-upgradeable contracts. What is more telling is the surrounding stack: across the organisation's 75 public repositories, the most recent push to any of them is **15 April 2026**, more than two months _before_ the public-good announcement. Community stewardship has produced no visible commits in that organisation since.
- **The marketing site still sells.** hatsprotocol.xyz carries no wind-down notice at all: it still offers "Book a demo" and lists open roles. A reader arriving from a search engine gets no signal that the company behind it has closed – which is precisely why a DAO's tooling due diligence has to read repositories and contracts rather than landing pages.

The net position is a good one by the standards of this failure class: an immutable primitive that survives its maintainer, with a hosted convenience layer that does not. The exposure is not that hats stop working – it is that nobody is now obliged to ship a fix if a module, an integration or an interface breaks, and any organisation depending on Hats has quietly become its own maintainer.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-a-caper) has no role layer to install, because it needs almost no privileged roles in the first place. Membership is flat: influence is not a hat an admin grants but a record you earn – every ballot and every trade mints a _soulbound, non-transferable_ vote token – 1 per ranked ballot, 0.01 per XRD of gross value on each leg of a trade – and your weight is `w = (t · v) / (V · T)`, the product of what you hold and the participation you have accumulated (see [Voting](/wiki/governance/voting)). No wearer sits between a member and the treasury: once a proposal passes, [execution is permissionless](/wiki/governance/execution) – every settle and execute entry point on the protocol is declared `PUBLIC`, so anyone can submit the transaction that carries out the winning option – and the one credential that _is_ privileged, the treasury admin badge, never leaves the contract's own vault; it is presented as a proof inside a single atomic call and returned before the transaction ends. Where Hats gives a large organization a revocable tree of delegated authority, a caper aims to need less delegated authority at all: fewer roles to grant, fewer to revoke, and no standing key for anyone to lose or abuse.

## References

- [hatsprotocol.xyz](https://www.hatsprotocol.xyz/) · [Hats Protocol documentation](https://docs.hatsprotocol.xyz/) · [hat properties](https://docs.hatsprotocol.xyz/for-developers/hats-protocol-for-developers/hat-properties).
- [Hats-Protocol/hats-protocol](https://github.com/Hats-Protocol/hats-protocol) and the [Hats-Protocol GitHub organisation](https://github.com/Hats-Protocol) – repository push dates read from the GitHub API on 13 August 2026.
- [Haberdasher Labs to close and transition Hats Protocol to a public good](https://www.bitget.com/amp/news/detail/12560605475828), 24 June 2026 – the wind-down was announced by the team on X rather than on the project blog, so this report is cited for the quoted terms.