Let's talk about token standards

in #erc7776 years ago (edited)

Most of ICOs are using ERC20 tokens. We have more that 500 tokens with 25 billion USD market cap! But there are a few really ugly things about it.

  • You can't really easily use it in your smart-contracts.
  • There is known bug with allowance.
  • It's impossible to recover it from smart-contracts if you accidentally send tokens there.

Many people don't know that there are a few more nice proposals: ERC223,ERC827, ERC721, ERC777 and now, I'm also proposing ERC965 for have one more nice extension which I needed. But first let's describe shortly each of mentioned standards.

ERC223

More that a year ago, ethereum classic developer Dexaran proposed ERC223 which should solve some of ERC20 problems (e.g. possibility to use tokens in smart contracts without doing two transactions).

The problem of ERC223 is that transaction will fail if receiving smart-contract don't support it (e.g. multi sig wallet). Also some exchanges have problem with supporting two transfer functions with same name but different signatures (amount of parameters).

Vitalik Buterin is also not a big fan of ERC223 because he is proposing in future to convert all accounts into smart contracts. In such case ERC223 token transactions will almost always fail.

ERC777

Recently there was proposed new advanced token standard ERC777

I do believe that ERC777 is way to go, that's why I used this standard for my own time token JaroCoin.

Main features:

  • Uses the same philosophy as Ether in that tokens are sent with send(dest, value, data).
  • Both contracts and regular address can control and reject which token they send.
  • Both contracts and regular addresses can control and reject which token they receive.
  • The tokensReceived function also avoids the double call needed in the ERC20 standard (approve / transferFrom).
  • The token holder can "authorize" and "revoke" operators who can send tokens on their behalf. These operators are intended to be verified contracts such as an exchange, a cheque processor or an automatic charging system.
  • Every token transaction contains a userData bytes field and a similar operatorData – in case of an operator transaction – to be used freely by the user (token holder) and the operator respectively to pass data to the recipient.
  • It is backwards compatible way with wallets that do not contain the tokensReceived function by deploying a proxy contract for the wallet.

Please watch video to learn more:

ERC965

ERC777 solves almost all currently known issues with tokens. There is only one thing which lack in there - possibility to transfer tokens without paying for gas.

Just a few days ago on crypto meetup one of participants was complaining that he can't move his golem out of Jaxx. I asked him if he has ethers there, and obvious answer was NO.

Let's take another example. JaroCoin users just want to book my time using JARO token but to do that they would need to pay for gas. That would mean that they are required to always store some amount of eth in their wallet. I would be happy to pay for gas for them but natively it's not possible. That's why I have proposed ERC777 extension - ERC965 Pay via cheque. With this extension it's possible to implement function in wallet which would not send tx directly into blockchain. Instead it would sign it and send to some king of proxy which would persist tx into blockchain and pay for gas.

I'm glad that this problem meets other people needs and that issue is already discussed amount Ethereum community.

If you have any proposals on how to make Send by Checque even better, please join discussion on GitHub: https://github.com/ethereum/EIPs/issues/965

Coin Marketplace

STEEM 0.30
TRX 0.11
JST 0.033
BTC 64223.84
ETH 3158.34
USDT 1.00
SBD 4.29