ERC-1372 Multi-Class Token Standard vNext

[aquiladev]

Simple Summary

A standard interface for multi-class tokens (MCTs).

Abstract

The following standard allows for the implementation of a standard API for MCTs within smart contracts. This standard provides basic functionality to track, transfer, and convert MCTs.

Personal motivation

Token factory is the first name of the concept. After the investigation I found the similar multi-class token concept. It has been bothering me for the last 3 months. I am familiar with #1155, #1178, #1203 proposals, but there is one tiny issue that makes me worried, which actually motivated me to write the proposal of my own. In my opinion the above-mentioned proposals have a small flaw which opens a room for improvement.

In my proposal I'm going to cover only the MCT. It is up to the community to discuss, decline, accept, change or merge the proposal with the existing ones.

Explanation is based on #1203

Motivation

I completely agree with general motivation from #1203

Key

The tiny difference and at the same time the biggest advantage of the proposal is the access key (class in #1155, #1178, #1203 proposals).

I'm proposing to use bytes32 type as a key for a token, whereas all proposals use uint265 type.

Why is it so important?

It is much easier to use rule based keys than index keys.
Here are some examples of the key's rule:

• token owner (account as well as contract)
• multiple owners,
• month_year
• color
• index
• etc

In order to create the key we can utilize keccak256(rule). Default key can be keccak256('')

Specification

contract ERC1372 is ERC20 {
    function totalSupply(bytes32 _class) public view returns (uint256);
    function balanceOf(address _owner, bytes32 _class) public view returns (uint256);
    function transfer(address _to, bytes32 _class, uint256 _value) public returns (bool);
    function approve(address _spender, bytes32 _class, uint256 _value) public returns (bool);
    function allowance(address _owner, address _spender, bytes32 _class) public view returns (uint256);
    function transferFrom(address _from, address _to, bytes32 _class, uint256 _value) public returns (bool);

    event Transfer(address indexed _from, address indexed _to, bytes32 _class, uint256 _value);
    event Approval(address indexed _owner, address indexed _spender, bytes32 _class, uint256 _value);
    event Convert(uint256 indexed _fromClass, uint256 indexed _toClass, uint256 _value);
}

Credits

Thanks to all the authors of the related proposals.

I would appreciate to discuss the proposal with @coinfork (#1155) @achon22 (#1178) @jeffishjeff (#1203) and co-authors.

Copyright

Copyright and related rights waived via CC0.

[ericbinet]

You can losslessly cast back and forth between bytes32 and uint256. Neither ERC-1155, nor ERC-1203 impose a format on the class value. A hash can be used without using bytes32.

An added benefit is that operations on uint256 cost less gas then bytes32.

[aquiladev]

@ericbinet good arguments, thanks!

Is it possible to do implicit cast between those types? For instance function expects uint256, but I sent bytes32 (string).

What kind of operations do you mean in the particular case? Is there any cost differences for access by index for different index's types?

[coinfork]

What kind of operations do you mean in the particular case? Is there any cost differences for access by index for different index's types?

Using bytes32 in various cases is more expensive than using uint256. For example, simply passing a bytes32 value in a function parameter (like bytes32 _class in this standard) will be more expensive than a uint256 parameter.

[ericbinet]

As far as implicit casts go, this would be handled by your client code. If you use Web3 in JavaScript, all numbers are sent to Ethereum as BigNumbers. Conversion is handled by the library.

If you rely on web3.sha3("data to hash, info on token class"), this function returns a hex string that is accepted by functions expecting a uint256.

On Web3 1.0, this function is named web3.utils.sha3 and is aliased as web3.utils.keccak256

[jeffishjeff]

@aquiladev Thanks for citing my EIP-1203 :) Glad to see my idea being validated by others and as @ericbinet pointed out, our differences may be trivial.

Frankly though, I have essentially stopped working on EIP-1203 after giving another pass on EIP-1155 by @coinfork and found it to be a superset of what I was trying to do. In the comment section, there is a (very) lengthy discussion on standardizing the _class (or _id) bit packing format. The TL;DR version is that we're leaning toward moving that to its own standard (personally think it'll be a series of, with common business logic embedded for different sectors which is really cool) and leave EIP-1155 focused on addressing the multi-class part.

Take a look and see if you agree that we can all join force behind one proposal.

[aquiladev]

fair arguments, I think the proposal is no longer needed