A semi-soulbound ERC20 token to be distributed to incentivized participants.
Report Bug
·
Request Feature
Table of Contents
This is a simple ERC20 contract purpose built to allow for programmatic distribution of a semi-soulbound incentive token. The contract utilizes OwnableRoles to allow multi-party management of the token, be it programmatic or manual. The design is intended to reduce friction when utilized within DAOs or similar structures. Each address that receives a mint allocation can use it to distribute tokens however that address desires or is programmed to do. Allocations can only be reduced to what has been issued so far, there is no over or undersubscription when it comes to mint allocations.
SocialCredits was designed using Foundry, so I recommend familiarizing yourself with that if required.
- Foundry
curl -L https://foundry.paradigm.xyz | bash foundryup
- Set up your ERC20 project using Foundry
forge init ProjectName
- Install SocialCredits
forge install zodomo/SocialCredits --no-commit
- Import SocialCredits
Add the following above the beginning of your project's primary contractimport "../lib/SocialCredits/src/SocialCredits.sol";
- Inherit the module
Add the following to the contract declarationcontract ProjectName is SocialCredits {}
- Populate constructor arguments
Add the following parameters and declaration to your constructorconstructor( string memory name_, string memory symbol_, uint256 _maxSupply, address _owner ) SocialCredits(name_, symbol_, _maxSupply, _owner) {}
Once deployed, the owner can fully operate the contract. If they wish to delegate permissions to other addresses, they can do so with the grantRoles(address, uint256) function.
The function allocate(address, uint256) is used to allow EOAs or contracts to call mint(address, uint256) up to the allocation specified.
setLockExemptSender(uint256) and setLockExemptRecipient(uint256) are important for allowing DEXes to function and platform contracts to manipulate tokens. Uniswap router and pair need to be exempted as sender to allow for liquidity removal and buys, and platform contracts must be exempted as recipients in order to enable users to send them to platform contracts which can then send the tokens if they have sender exemptions too. Keep in mind, these exemptions are bypassing the transfer lock, so exempting the pair as a recipient allows sells to occur during the lock as well.
If tokens need to be burned without reducing the max supply, have the minter call forfeit(address,uint256) instead of burn(address,uint256). The forfeit() function returns the tokens to the minter's allocation. Use of burn(address,uint256) will reduce max supply!
Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.
If you have a suggestion that would make this better, please fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement". Don't forget to give the project a star! Thanks again!
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/AmazingFeature) - Commit your Changes (
git commit -m 'Add some AmazingFeature') - Push to the Branch (
git push origin feature/AmazingFeature) - Open a Pull Request
Distributed under the AGPL-3 License. See LICENSE.txt for more information.
Zodomo - @0xZodomo - zodomo@proton.me - Zodomo.eth
Project Link: https://github.com/Zodomo/SocialCredits