We need a better token standard than ERC20 for the smart contracts ecosystem

[vminkov]

It is currently dangerous (meaning many undesired consequences could follow) if the smart contracts ecosystem adopts like Ethereum the ERC20 token standard.

We, at LimeChain, want to suggest a new approach to handling asset-backed tokens.

Summary

Enable receivers of token/asset transfers to handle the transaction in an arbitrary way.

Abstract

A better token standard that fixes a lot of the issues of the ERC20 standard by replacing the transfer() function and adding a few extras.

Motivation

First, Ethereum's ERC20 standard brought a lot of pain to centralized exchanges because it forced them to create a unique deposit wallet address for each user in the database in order to make sure it is exactly this user who made the token transfer and then to fund this intermediary wallet address with ETH in order to be able to forward the tokens to a cold wallet address. There were many attempts to make a fix for this (forwarding smart contracts, infinite approve() on the intermediary wallet address, etc.), but the costs were never really taken off of the receiver of the transaction.

Second, the ERC20 transfer() allowed anyone to send unsolicited tokens to any address, including locking the tokens forever in a smart contract, sending all kinds of trash tokens to Vitalik Buterin's address or having to use Uniswap before making a second transaction to make the payment in the desired token/asset. This feature of transfer() is likely to make the use of ERC20 wrapped assets uncomfortable for institutional investors who do not want to be sent tokens of toxic assets or toxic senders.

To summarize, enabling the receiver to include their own transfer handler logic will significantly improve the use of asset-backed tokens, allowing things like

• privately recognizing the sender/reason of a direct transfer to a cold wallet by attaching a custom identifier to the transfer
• leaving unsolicited token transfers as not accepted by default or even reject them automatically
• automatically convert the transferred asset to another desired asset by using a DEX router
• split the transaction costs arbitrary between the sender and the receiver by refunding the sender in the same tx or converting a chunk of the asset to the native token, so the validator fee is topped up
• require prior to the tx or subsequently do KYC/AML checks before allowing the token asset to be added in the cold wallet/smart contract
• cross-chain bridges will be able to support direct transfer offers made from the wallet apps UI standard transfer functions

Specification

The ERC20 transfer(to, amount) function is removed and replaced by a makeOffer(to, amount, memo) function that instead of writing the transfer to the Map<Address, uint> balances map, first writes it to another map Map<Address, Map<Address, (uint, String, uint)>> offers and then looks up if the receiver has specified an address of a smart contract that implements a default transfer handler function and calls it. If no such is specified by the receiver, the transfer is locked forever until the receiver decides to act upon it. A second function makeLimitedTimeOffer(to, amount, memo, expirationTime) will enable the sender to retrieve the sent tokens after some offer expiration time.

You can find a pseudocode implementation with use cases here:

https://github.com/LimeChain/token-standard-proposal https://github.com/LimeChain/PSPs/blob/master/PSPs/drafts/psp-21.md

[gilescope]

It's definitely not that clear if a token really supports all the semantics of the ERC20 standard and as such many whitelists are used to subset to known good implementations. As an example of what happens to those that didn't whitelist here's a heartwarming tale: https://github.com/Defi-Cartel/salmonella

[HCastano]

I do agree, there need to be better standards than ERC-20. However, it's unclear to me if the Ink repo is the best place for discussions around standards. Standards are not part of the language and should therefore be discussed in a language netural place. I'm going to close this issue because of that.

Pinging @cmichi and @Robbepop in case you have different opinions about this.

https://github.com/LimeChain/token-standard-proposal

This link is broken by the way.

[vminkov]

I believe the place to promote a token standard is the examples directory of the ink repo. Currently there is only ERC20 for fungible assets.

We want to have a discussion so one standard at least is finalized, implemented and put in the examples directory.

P.S. The correct link https://github.com/LimeChain/PSPs/blob/master/PSPs/drafts/psp-21.md

[HCastano]

@vminkov The discussions around standards should ideally be in the PSP repo, as you're already doing.

I've added a "standards" label so that in the future early discussions around standards can be started here. However, they should make their way to the PSP repo for review.

It would be totally fine to open an issue or a PR with an implementation of a proposed PSP as an Ink example, so feel free to do that once you're ready.

[cmichi]

I think this is a related issue: https://github.com/paritytech/ink/issues/552.

[vminkov]

@cmichi if we implement the proposed standard, can we have it included in the ink examples directory? We would like to promote it around the community as the better standard that is also better suited for cross-parachain swaps

[cmichi]

@vminkov Yes, I think it would be great if you could go forward creating a PR for your PSP. It would be great to subsequently have an ink! example as a follow-up to an accepted PSP.