# Eligibility Modules

Eligibility modules have authority to rule on the a) eligibility b) good standing of wearer(s) of a given hat.

### Wearer Eligibility

Wearer Eligibility (A) determines whether a given address is eligible to wear the hat. This applies both before and while the address wears the hat. Consider the following scenarios for a given address:

|                             | Eligible                         | Not Eligible                        |
| --------------------------- | -------------------------------- | ----------------------------------- |
| **Doesn't wear the Hat**    | Hat can be minted to the address | Hat cannot be minted to the address |
| **Currently wears the Hat** | Keeps wearing the hat            | The hat is revoked                  |

When a hat is revoked, its token is burned.

### Wearer Standing

Wearer Standing (B) determines whether a given address is in good or bad standing. Standing is stored on-chain in `Hats.sol` to facilitate accountability.

For example, a hatter contract implementing staking logic could slash a wearer's stake if they are placed in bad standing by the eligibility module.

An address placed in bad standing by a hat's eligibility module automatically loses eligibility for that hat. Note, though, that ineligibility does necessarily imply bad standing; it is possible for an address may be ineligible but in good standing.

Any address can serve as an eligibility module for a given hat. Hats Protocol supports two categories of eligibility modules:

1. **Mechanistic eligibility** are logic contracts that implement the [`IHatsEligibility` interface](https://docs.hatsprotocol.xyz/for-developers/v1-protocol-spec/interfaces/ihatseligibility.sol), which enables the Hats.sol contract to *pull* wearer standing by calling `checkWearerStanding` from within the `Hats.balanceOf` function. Mechanistic eligibility enables instantaneous revocation based on pre-defined triggers.
2. **Humanistic eligibility** are either EOAs or governance contracts. To revoke a Hat, humanistic eligibility must *push* updates to the Hats contract by calling `Hats.ruleOHatWearerStanding`.

Unlike admins, eligibility modules are explicitly set as addresses, not hats. This is to avoid long, potentially illegible, chains of revocation authority that can affect wearer penalties (such as slashed stake).

Eligibility modules offer a large design space for developers to extend and customize organizational infrastructure. See [Building Hats Modules](https://docs.hatsprotocol.xyz/for-developers/hats-modules/building-hats-modules) for more information.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.hatsprotocol.xyz/for-developers/hats-protocol-for-developers/eligibility-modules.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.