Proposed ERC20 change: make 18 decimal places compulsory

[vbuterin]

Rationale:

• Reduces the user experience complexity of adding ERC20 tokens
• Allows ERC20 transfer transactions to be easily detected and have the correct value shown on wallets (incl hardware wallets) without requiring pre-setup
• Ensures that in any on-chain exchange, the price as expressed in computer units (ie. wei or equivalent) is the same number as the price as expressed in human units (ie. ether or equivalent), reducing the risk of confusion or bugs

[RafaelCosman]

Would propose not making it compulsory, could be default. Here at TrustToken we have some real use cases where less than 18 decimals makes sense.

https://github.com/trusttoken/trusttokens

[adrianmcli]

I'm very sympathetic to this proposal, but I think it's a bit too late to make it compulsory given how some coins already are (like USDC that uses 6 decimals).

However, we really need some kind of name or maybe a separate standard for 18-decimal ERC20 tokens.

Building dapps that are supposed to work with multiple ERC20 coins is getting really annoying when most coins are 18 decimals except for a handful that come up and surprise you during development.

[3sGgpQ8H]

All ERC-20 token amounts are integers, as well as all Ether amounts. This is quite common practice in financial IT, and crypto-financial IT isn't different.

When large token amount is to be presented to a user, it could be convenient to render it in larger units, rather than in base units. For ether amounts, common larger units are GWei (10^9), Szabo (10^12), Finney (10^15), and Ether (10^18). Less common units are KWei (10^3), MWei (10^6), KEther (10^21), etc. When rendered in any of such units, ether amount could look like a fractional number, but this is only the rendering artifact, and this doesn't make the amount itself fractional. Just think about file sizes. We all know, that all file sizes are integers and measured in bytes at file system level. However, for a user, file size could be rendered as 1.23 MB, which looks like a fractional number. Another example is fiat amounts. All USD amounts are actually integer (measured in cents), however they could be rendered as $1.23 or even $1.23M. Of cause, such rendering doesn't make the amounts themselves fractional.

For ERC-20 token, situation is the same. UI may render large token amount using larger units. For token representing backup storage space, such units could be KB (1024), MB (1048576), GB (1073741824), or TB (1099511627776). For token, representing eggs, such unit could be a dozen (12). Of cause, one token may have several different units, suitable for amounts of different scale. For example, tokenized ether may logically inherit units commonly used for ether, such as GWel, Szbao, Finney, and Ether. The idea, that simple “decimals” property could cover all use cases was initially wrong, as it doesn't cover tokens, whose units are not powers of ten, and it doesn't cover tokens that have multiple larger units.

The introduction of “decimals” property, however, led to a great confusion, as people started thinking that ERC-20 token amounts are fractional, which is not the case. Initially, “decimals” property was meant to be used only by off-chain applications, such as wallets, in order to improve user experience. However, smart contracts started using this property for things like exchange rates. Instead of maintaining fractional exchange rate between base units of two tokens, which would be a proper solution, some smart contracts maintain integer exchange rate between “full” token at only side and token base unit at another side. For example, USD/ETH exchange rate is maintained not as 1 Wei = 0.00000000000000024746... cents, but rather as 1 ETH = 24746 cent.

In my understanding, such approach is an abuse of “decimals” property, and leads to a number of problems. The main problem is that the precision of calculations starts depending on the value of token base units. This makes it impossible to use such smart contracts with tokens, whose base units have significant value.

[github-actions[bot]]

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[bot]]

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.