Inside a Hats Module
Typically, Hats Modules inherit from the HatsModule.sol contract. This is an abstract contract that provides a generic structure that modules can extend to support any specific use case.
It serves several key functions:
Provide the basic boiler plate required for a new Hats module contract.
Enable compatibility with HatsModuleFactory.sol, the easiest and cheapest way for users to deploy new instances of a given module.
Enable compatibility with the module registry, which facilitates user discovery and integration into Hats front ends.
Inheriting from HatsModule.sol is necessary to be deployable via HatsModuleFactory, to be listed in the Module registry, and to appear natively in the applications using the registry.
However, it is not required for compatibility with Hats Protocol more generally. See the docs for Eligibility and Toggle modules for those requirements.
The remainder of this documentation assumes inheritance of HatsModule.
HatsModule.sol
HatsModule.sol's primary function is to enable a module to be configured and deployed via HatsModuleFactory. Often, each new hat to which a module is attached involves a new instance of that module, so its important for deployment to be gas-efficient. Additionally, each module is likely to be called many times over its life, so its also important for runtime execution to be gas-efficient.
For these reasons, HatsModule.sol is structured as a minimal proxy (clone) contract — similar to the EIP-1167 standard — that also supports immutable arguments. It implements the gas-efficient LibClone.sol library.
See the following pages for more detail about how HatsModule.sol operates:
pageImmutable ArgumentspageModule SetuppageVersioningExtensions
There are a couple stock extensions to HatsModule.sol that are useful starting points for common types of modules:
HatsEligibilityModule.sol: implements
IHatsEligibility.solHatsToggleModule.sol: implements
IHatsToggle.sol
Last updated