How to Design ERC721 & ERC20 in ERC1155?

Support Contracts
1

If I have a farm that includes 2 Cats in (ERC721), $50(ERC20) in the beginning.

before upload contract to Chain(pseudo code )

_mint(1,cat,1);
_mint(2,cat,1);
_mint(3,$,50);

2 Sheep(ERC721) and earn
€50(ERC20)

pseudo code
On-chain code which can not be changed but update through author of contract.

_mint(4,sheep,1);
_mint(5,sheep,1);
_mint(6,€,50);

The Question1 is what is the right way to use ERC1155 to extend the Dapp Items, just directly call the _mint() without caring about specific index(id) which given to NFT or FT

The Question2 came from Q1 if NFT and FT use the ids disorderly like this

_mint(index=1, NFT)
_mint(index=2, FT)
_mint(index=3, NFT)

Will this token design be bad for retrieving or fetching data late?

2

I don't think this token design will be particularly bad for retrieving data later.

It sounds like you need some way to make sure you're not minting "$50" where you had a sheep before. One thing we've done before with ERC1155 is to use a token id format that separates the different kinds of token ids so that for example fungible tokens start with bit "1" and non fungible start with bit "0".

1 Like
3

I thought we use ERC1155 should prevent "id" conflict between FT & NFT. I am not sure the meaning of the bit "1", bit "0" you mentioned. maybe separate 256bit into half. there is an example in The EIP-1155, in order to save and load 'id' through FT 128bit and NFT 128bit which need extra convert function to use them.

I am trying to use 1M as fungible token types starting with 1 to 1,000,000 which is enough to save those types. non-fungible token starting with 1,000,001 to 999999999999....
Do you think is this is a good solution :grinning_face_with_smiling_eyes: for managing 2 token types for retrieving and scalable data later?
Thank you!

4

That sounds good! It's similar to what I was proposing. Just define ranges that should be FT or NFT.

1 Like