---
title: Hats Protocol Overview
author:
- nintynick
- Spencer Graham
---

# 🧢🎩👒 Hats Protocol: DAO Role NFTs


>No one [DAO member] should have all that power
>The clock's ticking, I just count the hours
>Stop tripping, I'm tripping off the power
>...
>You got the power to let power go?
> [name=DAOnye West]

## An introduction to Hats

To be effective while also being decentralized, DAOs must be able to give their members authorities and responsibilities while avoiding centralized points of failure. Who adds the people to the multisig? Who has control of Discord admin and the Twitter account? When the DAO gives these powers to people, how can the DAO hold them accountable to behaving well while also resisting capture?

This is where Hats Protocol comes in. **Hats are non-transferable NFTs that grant authorities to their Wearers — the accounts that hold them.**

You can think of a Hat like a role. It has eligibility requirements such as a number of tokens or shares held or staked, it can be granted and revoked at the behest of the Hat creator, and because it's an NFT, it is interoperable with other protocols and apps that support things like access control, reputation management, and organizational legibility.

Importantly, Hats have the built-in capacity for increased accountability around responsibilities in a decentralized organization. In addition to explicit responsibility definitions and visibility, Hats may require tokens or DAO shares to be staked in order for a prospective Wearer to become eligible for the role.

To use Hats in your DAO, you need to instantiate two contracts: one that mints the Hat NFTs, and another that checks if Wearers are eligibile for and compliant with the requirements to wear the Hat. In this document, we describe these two contracts and their parameters as the foundation of a new primitive in the DAO world. We're excited to see what emerges out of the Hats! 🎩🐰

## What kinds of Hats might your DAO wear?
We all know that most DAO members wear many hats. With Hats Protocol, you can make those Hats literal, specific, and capture-resistant. Here are some of the use cases that are already apparent to us:

- Assignment and accountability for hard (executive) power to DAO contributors
- Signer on a multisig
- DAO Twitter access
- Discord admin roles
- Code repository admin rights
- Assignment and accountablity of soft power to DAO contributors
- Work stream leadership
- External representative
- Commitment to complete a specific part of a project
- Organizational legibility in other protocols and apps through an on-chain NFT-based definition of roles
- SubDAO membership, e.g. via Orca Protocol
- Off-chain access control (Twitter, Github, etc), e.g. via Lit Protocol
- Role management in Discord (and similar platforms), e.g. via CollabLand and Guildxyz
- Role visibility, e.g. via wallets, DAO UIs, and Sobol/Nestr/etc

## Hats Protocol Design

The Hats system is organized by objects, agents, and mechanisms.

### Objects
#### Hats
The primary object is a **Hat**. A Hat is represented as a non-transferable NFT (likely implemented as ERC1155), and has the following properties (see Additional Details section for more):
- Name
- Details (or description)
- Eligibility threshold
- Eligibility contract
- Owner
- Oracle
- Conditions

There can be more than one amount of a particular Hat (e.g. to give 5 contributors the same access to the DAO's twitter account). This amount is established by the `maxSupply` property of a given Hat.

#### Offers
To wear a particular Hat, a prospective Wearer must first make an **Offer** to wear it. Offers have the following properties:
- The Hat to be worn
- The prospective wearer
- The offer, denominated in the same units as the Hat's eligibility threshold

### Agents
The two primary types of agents are Hat **Owners** and Hat **Wearers**. Agents that want to wear a Hat are referred to as **Prospective Wearers**.

#### Owners
Owners are typically DAOs, though can also be individuals. They exhibit the following behaviors:
- Create Hats, including setting Name, Details, Eligibility Threshold, Eligibility logic, Oracle, and Conditions
- Accept Offers from qualified Prospective Wearers
- Deactivate Hats that no longer need to be worn (via the Conditions mechanism)

#### Wearers
Wearers are typically individuals, though other entities (eg multisigs or even DAOs) can also wear Hats. Within the protocol, they can exhibit the following behaviors:
- Fulfill Hat eligibility requirements (eg staking)
- Submit Offers to wear Hats
- Relinquish ("take off") Hats they no longer wish to wear

### Mechanisms
Mechanisms modify Hats and Wearers. There are four mechanisms:
- **Eligibility**
- **Penalties**
- **Oracles**
- **Conditions**

Oracles and Conditions can each be triggered in one of two ways:
1. Mechanistically, i.e. encoded in a smart contract
2. Humanistically, i.e. determined by a person or group of people, such as an EOA, multisig, or DAO

#### Eligibility
DAOs can establish criteria that Prospective Wearers must meet in order to be eligible to wear a Hat. That criteria can be defined by any contract state. For example any of the following could serve as Eligibility criteria:
- Must hold >X amount of some token or NFT
- Must have >X amount of shares for some DAO
- Must stake >X amount of some token or NFT
- Have reputation above X level
- etc

In the Elgibility mechanism, X can vary from Hat to Hat, but the eligibility unit must remain constant across Hats. Similarly, criteria can be combined as long as the amount X for all but one of the criteria remains constant. In other words, the criterion for a given Hat must be expressible in a single variable, i.e. the Hat's Eligibility threshold.

#### Penalties
DAOs can also establish Penalties for not fulfilling a Hat's responsibilities. Example Penalties include:
- Slashing staked tokens or NFTs
- Slashing DAO shares or rep
- Sending "shame" tokens to the wearer's wallet
- etc

The credible threat of a sufficiently potent Penalty holds Wearers accountable to the responsibilities of their Hats.

Like Eligibility, the magnitude of a Penalty can vary from Hat to Hat, but the penalization unit must be constant.

#### Oracles
Oracles determine whether a Hat Wearer is fulfilling the Hat's responsibilities (as defined in its Details). If the Oracle finds that the answer is No, the Hat is revoked and the Penalty for that Hat is triggered.
- Mechanistic Oracles are tuned to on-chain state changes, such as the Wearer making a particular transaction.
- Humanistic Oracles are judged ad hoc by the Oracle entity. Often this is the DAO itself.

#### Conditions
Conditions determine when and if a Hat remains active.
- Mechanistic Conditions can be things like expiration timestamps or other on-chain state changes.
- Humanistic Conditions are not pre-defined; rather, they are determined ad hoc by the Conditions entity. For example, the Owner may set their own address as the Conditions entity to be able to deactivate a Hat at their discretion.

Deactivating a Hat unwinds everything without a Penalty: the Hat NFT is burned and the Wearer's Eligibility is unlocked (e.g. stake is returned).

### Additional Details
Additional details for the properties of a Hat not covered above.

#### Details
- "What is the Hat?"
- Specific authorities / responsibilities / commitments associated with wearing the Hat
- Possibly a link to an off-chain description

## Hats Protocol Architecture

A modular architecture facilitates a wide range of use cases and customization.


[image source](https://app.diagrams.net/#G1aB602uX34FClamZ0HvVWR3pJpGv8TOpr)

### Hats Contract (HC)
- Storage
- Hat objects
- Offers
- Hat balances for Wearers
- Functions
- Create Hat
- Record Offer (forwarded from HEPC)
- Accept Offer
- Check Hat Conditions (calls Conditions contract)
- Deactivate Hat (called by Conditions)
- Request Oracle Ruling (calls Oracle contract)
- Rule on Hat (called by Oracle)
- Record Relinquish call (forwarded from HEPC)
- Unlock Eligibility (forwarded to HEPC)
- Mint Hat NFT
- Burn Hat NFT

### Hat Eligibility & Penalty Contract (HEPC)
HEPC contracts can be customized, but must inherit from the HEPC abstract contract and `override` the `virtual` functions

#### HEPC Abstract
- Storage
- Prospective Wearer eligibility, by Hat
- Virtual Functions
- Submit Eligibility
- eg stake
- Submit Offer (forwarded to HC)
- Relinquish Hat (forwarded to HC)
- Apply Penalty
- eg slash stake
- Unlock Eligibility
- eg return stake
- Other Functions
- Check Eligibility (internal)

### Hat Oracle
Humanistic Oracles must be able to call the Rule function on the HNC.

Mechanistic Oracles must conform to the IHatOracle interface.

#### IHatOracle
- Virtual Functions
- Submit Oracle Ruling

### Hat Conditions
Humanistic Conditions must be able to call the Deactivate Hat function on the HNC.

Mechanistic Conditions must conform to the IHatConditions interface.

#### IHatConditions
- Virtual Functions
- Deactivate Hat