3

Is it possible to make one ERC20 compliant token contract, but have different classes of tokens circulating under the same token name?

e.g. You are distributing concert tickets validated by a token contract called "TicketToken", and have three open seating areas; Floor, Mezzanine, and Obstructed. Can you attach a classifying string to the token to delineate the class?

5

In short: maybe, but it might not be the best idea.

I would advise against such functionality, even if it is possible, since it negates the fungibility of the tokens (i.e. one token is not worth the same as another), and dApps that are ERC20 compliant do not expect this.

Try this:

Another solution would be to make three separate tokens; one for each of the classes.

You can attach a string to these different tokens in the name field as per the ERC20 protocol, and use that to delineate class in your dApp.

Still:

To answer your question in a strict sense, I don't think extending an ERC20 token to include metadata like this would necessarily make it non-compliant.

But by the same token (brutal pun.) the ERC20 protocol does not provide a way to differentiate between tagged tokens, so you would have to build that functionality into your extension as well.

In other words, ERC20 would have to be extended to support this, and it would not be transparent to ERC20-compliant consumers (wallets, etc.) what the difference was between the tokens, even if your dApp knows.

Perhaps some future EIP will implement "tagged tokens", and dApps will evolve to support that standard, but for now it isn't this way.

Other info:

  • Do you have any examples of non-compliant tokens using this? It seems a bit wasteful to have multiple contracts in the early stages, when all of the planned EIPs will break my current ones. I am trying to issue one convertible token contract now in plans for this. My idea actually would have hundreds of classes, and be updated with new classes. Maybe there is a way to track (serialize) a token's issue order/date? The tokens would be integers with no decimals. The issue amount of tokens could be mapped far into the future unlike venue seats. – TrumpPaiPence Jul 5 '17 at 21:13
  • 1
    If you want to be ERC20 compliant then it is one contract: one token. But since you mentioned that doesn't matter to you, you could just use a mapping for the balance of each "subtoken", and have transerFrom/to methods for each balance or something like that. I don't know of any contracts that behave like this right now, after a quick search. – Travis Jacobs Jul 5 '17 at 21:23
  • 1
    I'm totally paranoid about the call stack attacks with these long drawn out functions. I'm thinking it is best to keep as short and air tight as possible. I just had a tangential idea now that might work for my project because of your answer, thanks for your help! – TrumpPaiPence Jul 5 '17 at 21:41
  • 1
    My solution is to use ENS subdomains for each class to make it easy to understand for humans. So class1.myensdomain.eth is the first class, and all of the contracts are just duplicates. more gas intensive, but more segmented and less to go wrong. Perhaps the root domain can manage the exchanges of token classes. – TrumpPaiPence Jul 5 '17 at 21:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.