formatUnits and parseUnits

[novaknole]

Hi @zemse @ricmoo

I came up across a very interesting topic.

We have a form, where user can enter token address and token amount. It's an editable form.

Scenario Explained..

1. user enters this page..
2. we show token address and token amount. NOTE: the amount shown in the form is not always the amount returned from contract. What we do is on the token address, we fetch decimals and then use ethers.utils.formatUnits(amount, decimal).
   let's say token address was 0x....1 and amount was 100.18
3. User can update the form, so enters the new token address. Then, changes the amount from 100.18 to 50.15... When user clicks save, we can't send 50.15 to the contract, so we again fetch the decimals on the new token address and then do ethers.utils.parseUnits("50.15", decimals). Here the problem is that what if decimals was returned 0 or null as it doesn't exist on the newly entered token... Now, parseUnits will throw an exception and not sure even if I swallow the exception, what I should be sending to the contract ? Maybe i should be sending 5015 instead of 50.15, but It doesn't seem correct to me.

I'd appreciate the ideas...

By the way, if decimal is null, formatUnit by default uses 18 decimals, but here it says that if you don't specify, it's 0 and not 18. https://ethereum.stackexchange.com/a/100073/46200

[zemse]

Heya!

Here is what ERC20 specs say about decimals:

Returns the number of decimals the token uses - e.g. 8, means to divide the token amount by 100000000 to get its user representation. OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present.

So if the method does not exist, then you simple don't divide by 10^decimals(), and display the number as it is (meaning you have to explicitly pass 0 in parseUnits and formatUnits).

[novaknole]

Yeap... @ricmoo

Definatelly.

Seems like I have to work on UI to handle all edge cases...

Thanks a lot to both of you..

[ricmoo]

(quick note; if the method is not implemented it will throw an error, not return null, so you need to trap this regardless, you cannot just pass in the result ;))

[novaknole]

True. I am handling this in the subgraph and always return null if it's not defined...

[novaknole]

@ricmoo I realized one caveat though...

Even if I let users enter 10.0 or 10.02918 kind of numbers in the amount field, they might still enter 100000000 , which means that in this case I shouldn't be doing parseUnits., because what's the point ? if it doesn't contain numbers after ., then user somehow escaped my scheme.

Do you think checking . in the amount and if it doesn't exist, then I don't do parseUnits at all, seems a correct way ?

[zemse]

Sometimes users might just write 10 but still mean 10.0, and this might result in unintended behaviour. It could be better to present a switch that allows users to add 18 or whatever decimals or skip that.

[ricmoo]

You should never swallow an error like that. You will almost certainly not do what your users will want. If there is no decimals, it is not a very compliant ERC-20 contract (and may not be an ERC-20) contract at all.

In that case I would throw up a big red warning, explaining the situation, and that if they wish to proceed, they need to enter the number of decimals themselves.

Keep in mind 0 is a completely valid value for decimals. It just means it is indivisible. Bernie babies are fungible, but are not divisible (at least their value would be drastically impacted).

It should never return null; it will throw a CALL_EXCEPTION if the method doesn’t exist.