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.
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.
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.
Two pluggable modules make a hat programmable rather than merely administered, per the hat-properties reference:
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.
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.
"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, and unchanged on 1 October 2026:
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 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.
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 – casting a ranked ballot mints exactly one soulbound, non-transferable vote token, and buying, selling and transferring mint none, the trade-side accrual having been removed in the genesis redeploy of 11 September 2026 – and your weight rests on both 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.