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 for signalling, Tally for onchain proposals, 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" and was built as open-source infrastructure by Haberdasher Labs. On 24 June 2026 Haberdasher Labs announced it was closing 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 token, per the protocol documentation. 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 – 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:

• 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 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 frozen contracts to governed 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 (gating who can create or pass certain votes), Tally (proposals), Decent (workspaces), and Unlock (identity), and the protocol is commonly paired with Safe multisigs and 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"; 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: 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". 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 trade, and it is the half most projects do not get.
• The hosted layer is on a clock. The wind-down was reported 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 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). No wearer sits between a member and the treasury: once a proposal passes, execution is permissionless – 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 · Hats Protocol documentation · hat properties.
• Hats-Protocol/hats-protocol and the Hats-Protocol GitHub organisation – repository push dates read from the GitHub API on 13 August 2026.
• Haberdasher Labs to close and transition Hats Protocol to a public good, 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.