Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why does ERC1155MixedFungibleMintable needs store the type of both fungible and non fundgibl #23

Open
timPrachasri opened this issue Nov 12, 2019 · 4 comments

Comments

@timPrachasri
Copy link

Why do ERC1155MixedFungibleMintable needs store the type of both fungible and non-fundgible in the upper 128 bits? For non-fungible it makes sense since the lower 128 bits are ID, but for fungible, why do we need to store the type in upper 128 bits as well

 // Store the type in the upper 128 bits
        _type = (++nonce << 128); <---- this one

        // Set a flag if this is an NFI.
        if (_isNF)
          _type = _type | TYPE_NF_BIT;

        // This will allow restricted access to creators.
        creators[_type] = msg.sender;

proposal

  • why don't we move _type = (++nonce << 128); in the condition if (_isNF) instead ?
@AC0DEM0NK3Y
Copy link
Contributor

If Type A (fungible), Type B (non-fungible) and Type C (fungible) all needed to be minted in your contract how would your code handle that situation?

@ghost
Copy link

ghost commented Nov 13, 2019

@AC0DEM0NK3Y I don't get what situation did you mean since when minting there're two different functions for fungible and non-fungible
(which are

  • function mintNonFungible(uint256 _type, address[] calldata _tos) external creatorOnly(_type)
  • function mintFungible(uint256 _id, address[] calldata _tos, uint256[] calldata _quantities) external creatorOnly(_id)

)
and when identifying credit whether it is fungible or non-fungible there are a masking bit for that.

In your case (Type A (fungible), Type B (non-fungible) and Type C (fungible)), the id for A, B and C could be like the following (let say I store ID in the uint8 instead of the uint 256)

  • A: 0000 0001
  • B: 1010 0000
  • C: 0000 0011

@AC0DEM0NK3Y
Copy link
Contributor

There is a common create function, that is where the code the OP mentioned was pulled from.

...and sure you could store it there yes, but now to get type you first have to test fungibility and then either use a mask or pull from uint8 (essentially a mask on the lower bits), and have limited yourself to 255 fungible types.

By storing the type in the same place for all you can use a common way to get the type from any id.
But it's up to you, the id mechanism is up to the implementor this is just an example of how you could do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants
@timPrachasri @AC0DEM0NK3Y and others