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. In June 2026 Haberdasher Labs announced it was winding down and transitioning Hats Protocol into a community-run public good — the onchain contracts are unchanged and the full stack is now open source.

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.

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 — each vote mints a soulbound, non-transferable vote token, 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 — 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.