ERC-1178: Multi-Class Fungible Token Standard

[albertchon]

No description provided.

[coinfork]

This is essentially what we're doing in #1155, I suggest contributing to that EIP instead.

[PhABC]

Commenting here instead of the pull request ;

The way I see it, #1178 is specifically for fungible tokens (which is what we need as well), while #1155 wants to support both NFTs and FTs within a single contract. In this case, I see 1178 being a subset of 1155, where all tokens are fungible. Or, 1155 as being 1178 with "Class ID Specific Logic" functionality (some IDs are fungible tokens, some aren't). I talk about this a bit more in this comment on the #1155 thread and would love you hear what you think @achon22.

[albertchon]

It does indeed seem the case that the multi-class functionality can be modeled using the 1155 standard. However, as I mentioned in the pull request, conforming to this standard introduces additional complexity which not all developers may want to deal with (I certainly feel this way).

I've found that a different team interested in implementing security tokens also took a look at #1155 and found it to be unnecessarily complex and preferred a standalone multi-class standard.

Why shouldn't we allow for both standards to exist? For including NFTs, #1155 has its benefits and for MCFTs (multi-class fungible tokens) #1178 has its own.

[PhABC]

Yes, I agree with what you just said ^. Check out my last comment in #1155 and see if that seems like a more appropriate route.

[wighawag]

I like the simplicity of the standard and I see as mentioned the potential of combining it with ERC721. There is already such attempt at combining ERC721 with ERC1178 : ERC721x : https://erc721x.org

I think an ideal approach to combine would be to leave both standard as they are and make the contract implement both.

Currently though, a contract cannot both implement ERC1178 and ERC721 since both use totalSupply and it might not be a good idea that such function act semantically as both. This is probably true for existing tools working with ERC721 that expect totalSupply to represent the number of unique items and not a combination of ERC1178 tokens and ERC721 tokens.

I proposed a few days ago a proposal to deal with what I imagine will be more and more frequent as more standard comes into being: standards that benefit into being composed together but can't because they use same functions signatures : #1407

While I don't see 1407 being accepted soon, we can start namespacing methods using simple prefixing like mentioned by @chriseth in the issue

I suggested in the issue a double _ to make it clearer than a simple _ probably already used as word separator in some function naming convention. like erc1178__totalSupply

Feel free to suggest other separator idea or improvement over at #1407

On top of that, Solidity do not allow 2 Event with the same Name (regardless of signature). As such solidity will complain on having 2 different Transfer event (like in ERC1178 and ERC721)

This could be solved similarly by prefixing all function and event name with erc1178__

as a result the interface would be :

pragma solidity ^0.4.24;

contract ERC1178{
    event erc1178__Transfer(address indexed _from, address indexed _to, uint256 _classId);
    event erc1178__Approval(address indexed _owner, address indexed _approved, uint256 _classId);

    //// optional ////
    function name() public constant returns (string _name);
    function erc1178__className(uint256 classId) public constant returns (string _name);
    function symbol() public constant returns (string _symbol);
    /////////////////

    function erc1178__totalSupply() public constant returns (uint256 _totalSupply);
    function erc1178__individualSupply(uint256 _classId) public constant returns (uint256 _individualSupply);
    function erc1178__balanceOf(address _owner, uint256 _classId) public constant returns (uint256 _balance);
    function erc1178__classesOwned(address _owner) public constant returns (uint256[] _classes);

    function erc1178__approve(address _to, uint256 _classId, uint256 _quantity) public;
    function erc1178__transfer(address _to, uint256 _classId, uint256 _quantity) public;
}

I left name and symbol since they should be sharing the same semantic between ERC20/ERC721 and ERC1178

[HassanFahmy]

Proposing that we add an event to log the conversion between classes/ filling bids for conversion.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.