pumpedlunch / hatseligibilitymodules

a number of separate eligibility modules for use in Hats-Protocol

HatsEligibilityModules

HatsEligibilityModules is a repo containing a number of separate eligility modules for Hats Protocol. The modules are summarized below:

• AddressEligibility: check if addresses are on a whitelist that admins can edit
• DecentralistEligibility: checks if an address is on a Decentralist list
• ERC20Eligibility: checks if addresses meet a minimum balance of an ERC20 token
• ERC721Eligibility: checks if addresses meet a minimum balance of an ERC721 token
• ERC1155Eligibility: checks if addresses holds at least one minimum balance of a set of ERC1155 token Ids

All contracts are based on the Hats Protocol's repo: hats-module

Note: The contracts in this repo have not been audited - use at your own risk.

Deployments

For Eligibility Module deployments, see Releases.

Development

This repo uses Foundry for development and testing. To get started:

1. Fork the project
2. Install Foundry
3. To compile the contracts, run forge build
4. To test, run forge test. The tests require a private key and a valid mainnet rpc API KEY. A .env.example file is provided.

hatseligibilitymodules's Issues

Optimize for loops

The following optimizations and cleaner code can be achieved in for loops:

1. Since i is set to a known value, incrementing i can be done without over- or underflow checks.
2. ++i is slightly cheaper than i++
3. Solidity uints are initialized by default to 0, so when beginning a loop at i = 0, its not necessary to explicitly initialize i to be 0.

These three changes can be applied to blocks like the following...

for (uint256 i = 0; i < len; i++) {
     isEligible[_addresses[i]] = true;
}

...to get:

for (uint256 i = 0; i < len; ) {
     isEligible[_addresses[i]] = true;

     unchecked { 
          ++i;
     }
}

These optimizations can be applied to AddressEligibilityModule.sol

Normalize module naming convention

While ERC20EligibilityModule and ERC721EligibilityModule derive eligibility from a single token, ERC1155EligibilityModule derives eligibility from one of multiple tokens. Using the same naming scheme for both single and multi token modules creates some confusion.

I'd suggest changing to MultiERC1155EligibilityModule.

Optimization in ERC20EligibilityModule

Since a logical expression's type is a bool, the ternary in the following line is not necessary

HatsEligibilityModules/src/ERC20EligibilityModule.sol

Line 62 in 0586c24

eligible = balance >= MIN_BALANCE() ? true : false;

It can be shortened to eligible = balance >= MIN_BALANCE();