ERC20 Token with 1404 Restrictions
The SUKU token is an ERC20 compatible token with transfer restrictions added that follow the ERC1404 standard. The 1404 Restrictions will use whitelists to segregate groups of accounts so they are only allowed to transfer to designated destination addresses. At some point in the future, the transfer restrictions will need to be lifted and let any transfers succeed to/from any accounts.
All token features will be determined at deploy time, locking them in place.
- Name
- Symbol
- Total Supply
- Decimals
On deployment, all tokens will be transferred to the account that deployed the token.
There will be NO functionality for minting/burning tokens after the initial creation of the contract.
There will be a few different actors in the ecosystem.
- Issuer: This is SUKU who will have ultimate control of any changes in behavior.
- Administrator: The Issuer will have the ability to delegate admin permissions to other accounts.
- Owner: The Owners are the users who would like to hold and transfer tokens.
The Issuer account can add and remove other account addresses to a list of Administrators. Only the Issuer should have the ability to do this.
Once an account has been added to the Administrators list, the administrator can add/remove accounts to/from any of the whitelists. They can also enable/disable transfers between whitelists.
Before tokens can be transferred to a new address, it must be validated that the source is allowed to send to that desitnation address. If the sending client does not check this in advance and sends an invalid transfer, the transfer functionality will fail and the transaction will revert.
The Issuer account will have the ability to transfer tokens to any address, regardless of whether restrictions are enabled or the whitelist configuration state. The Issuer is not gated by any of the restriction logic.
Any address can only be a member of one whitelist at any point in time. If an administrator adds any address to a new whitelist, it will no longer be a member of the previous whitelist it was on (if any). Adding an address to a whitelist of ID 0 will remove it from all whitelists, as whitelist ID 0 is invalid. Removing an address from the existing whitelist will set it to belong to whitelist 0. All addresses belong to whitelist 0 by default.
Any whitelist can be configured to have multiple Outbound Whitelists. When a transfer is initiated, the restriction logic will first determine the whitelist that both the source and destination belong to. Then it will determine if the source whitelist is configured to allow transactions to the destination whitelist. If either address is on whitelist 0 the transfer will be restricted. Also, the transfer will be restricted if the source whitelist is not configured to send to the destination whitelist.
Example
- Whitelist A is only allowed to send to itself.
- Whitelist B is allowed to send to itself and whitelist A.
- Whitelist C is allowed to send to itself and whitelists A and B.
- Whitelist D is not allowed to transfer to any whitelist, including itself.
A total of 255 whitelists can be utilized, each with the ability to restrict transfers to all other whitelists.
By default, all whitelists will NOT be allowed to transfer between source and destination addresses within the same whitelist. This must explicitly be enabled. By default all whitelists block all transfers.
Administrators will have the ability modify a whitelist beyond the default configuration to add or remove outbound whitelists.
If a transfer is restricted, the code will follow the ERC1404 spec and revert the transaction. Any wallets interacting with an ERC1404 token contract should first query the contract to determine if the transfer is allowed, and if not, show the appropriate error to the user (including the reason code/text from the contract).
At some point in the future, the Issuer can turn off the transfer restriction functionality. Only the Issuer should have the ability to do this. This is a one-time and permanent change that cannot be undone. Once restrictions are disabled, all transfers to and from any address are allowed.
You should be able to install dependencies and then run tests:
$ yarn
$ yarn test
For unit test code coverage metrics:
$ yarn coverage