-
Notifications
You must be signed in to change notification settings - Fork 31
Customizable transfer restrictions per Hypercert #83
Comments
If a secondary owner isn’t allowed to transfer the hypercert, they also can’t donate/retire/dedicate it, right? Can we ensure that they can always retire it? |
First draft of transfer restrictions here @holkeb are these 3 policies sufficient? |
Closing for now until we get more guidance from legal on whatever else they need in the contract. |
@bitbeckers responding here to your telegram message. cc @Jipperism For the pilot we want all hypercerts to have the transfer restriction FromCreatorOnly. So this should be hard coded into the frontend for the pilot. However, the contract should allow for all three policies. @ryscheng also wanted to check to what extent these policies are upgradable, e.g. adding other policies later. At least for me that's still an open question. |
We should be able to add more policies in the future, they just show up as new enum elements. |
Let's make sure to test this when we add in the storage gaps and testing out the upgradeability further |
For each hypercert, we want to be able to set how transfers are restricted by the minter at mint time
For example:
from
is the original minterto
is from an allowlist.Potential implementation pathway:
https://docs.openzeppelin.com/contracts/4.x/api/token/erc1155#ERC1155Pausable
https://docs.openzeppelin.com/contracts/4.x/api/token/erc1155#ERC1155-_beforeTokenTransfer-address-address-address-uint256---uint256---bytes-
The text was updated successfully, but these errors were encountered: