Decimals for Native Tokens

Decimals can be registered in the Cardano Token Registry: https://developers.cardano.org/docs/native-tokens/cardano-token-registry/

So that, for example, SUNDAE registering six decimals in https://github.com/cardano-foundation/cardano-token-registry/blob/master/mappings/9a9693a9a37912a5097918f97918d15240c92ab729a0b7c4aa144d7753554e444145.json leads to wallet apps (in this example Eternl and Nami) displaying up to six decimals behind the decimal separator:

But at least Daedalus ignores this (but seems to read other things from the token registry):
screenshot-2022-05-16-13:41:59

So, the exact same value is displayed as 0.008272 SUNDAE in some wallet apps and as 8272 SUNDAE in one not totally irrelevant other wallet app.

This could lead to some confusion (and, as far as I can see, already does). The design for ADA and Lovelace is quite different. There, the smaller unit has a clearly distinguished name. We always can make clear if we are talking about ADA (with up to six decimal places) or about Lovelace.

Shouldn’t that be implemented for native tokens, too? So, that a different name is given to the token with decimal places in the registry (or later, perhaps, in on-chain metadata) and we clearly know, if we are talking about the small or the large unit.

More radical proposal would be to totally abandon that decimals setting and just advise applications to implement SI prefixes for all fungible tokens. Always mint the smallest unit and have kTOKEN, MTOKEN, GTOKEN, … for free. Registry or on-chain metadata could then just state that the preferred display for, e.g., SUNDAE, is MSUNDAE, but no confusion can arise, what is meant.

3 Likes

Hello @HeptaSean

If you click settings in the second screen shot you are able to manual change decimal places for a token. It also gives you default for that token as a first choice.
SettingsFTDae

After choosing decimal place and saving all those tokens will display correctly:
1Sunday

Good question would be as to why would they enable all this with recommended decimal places already selected as default, yet made it a manual conversion for every token.

They even went as far to make yellow warning labels telling you that token has decimal places or that you are using not recommended amount of decimal places. All this could be avoided if they just allowed for default set by token to be displayed as … default decimal places.

If you read release notes of 4.1 where they implement this it make very little sense all the effort they put into warning labels, yet default option is just there.
Source:https://iohk.zendesk.com/hc/en-us/articles/900006759746-Daedalus-4-1-0-release-notes#:~:text=Decimal%20places%20for%20native%20tokens,has%20eight%2C%20for%20instance).

Unless there is something else we need to be aware when it comes to decimal places/ tokens/ transaction/ etc…

This would be great if it catches on. You could have Sunday token that is made of 1,000,000 Scoop tokens (for example). Seems a lot more user friendly then generic yellow warning signs :+1:

2 Likes

Thank you! And: What?!?

Okay kind of user error that I did not see that. But: Did I disable it or is it not enabled by default or is it not enabled by default, because I am on Flight?

And:

I had no warning signs anywhere. Or are they just in the settings, but not in the main view? What would be the sense behind that?

Plus: It is still counter-intuitive that before changing the setting, it says that I have 8272 SUNDAE, and after changing it, it says that I have 0.008272 SUNDAE. They cannot usually both be true.

Edit: Nope, no warning to be seen anywhere. And 0 is the “default”, although 6 is “recommended”:
screenshot-2022-05-16-18:51:04
They obviously have changed the interface since 4.1 and apparently have removed the warnings in the process …, because why not?

They used to be in token view, but they are removed since 4.1.

:point_up:This! That’s why I think that dual naming idea you proposed could be very useful.

What I meant is that when I open the setting window the “recommended” amount is selected as default choice before clicking drop down menu. So they are fully aware of what decimal places should be, yet they left it as manual change.

I don’t use Flight and it is not enabled in regular version as well.

1 Like

The effort they put in making those warnings could of been just spent on auto-upgrading decimal point view to token default. You can still have manual decimal change option, but I don’t see a reason for not displaying tokens the way they were registered to be viewed/used.

1 Like

Thanks!

Even if Daedalus is also capable of changing the decimal places and I was just too challenged to find the setting, it still feels wrong. And there may well be wallet apps that do not (want to) look at the token registry at all, because leanness, because no dependency to some off-chain data source, because … It’s just strange that they, then, display something else than the others.

1 Like

Problem is: Since nobody thought of it, before defining the token registry contents, we already have a lot of tokens that are minted assuming the current system. So, it will not be easy to change. Or it will at least be unnecessary complicated.

The asset name will probably stay at “SUNDAE” and the registry metadata would then have to state that the asset minted as “SUNDAE” are really “SCOOP” and 1 million “SCOOP” are 1 “SUNDAE”.

Would have been somehow cleaner to just mint with the asset name “SCOOP”. Wallet apps ignoring the metadata would display something totally correct. And the metadata would just say “1 million SCOOP=1 SUNDAE” and wallet apps reading that could display an equally correct easier to grasp number.

Dealing with legacy …

This sounds like the start of a CIP for a fungible token standard that likely has at least the following elements:

  • Overall goal of recommending all fungible tokens minting to the smallest possible integer unit for divisibility of up to 6 decimal places. i.e. follow the best practice set forth by lovelace and other tokens.
  • The ability to register meta data for denominations and universal identification. This should allow for base16 encoded byte string or English ASCII string labels interchangeably or impose one over the other perhaps? This should have the implication the asset name refers to the unit of measure (1) unless otherwise aliased to another value in denominations via a matching label. Might also need some kind of meta label to identify the standard? e.g.
{
  "<policy id>": {
    "<asset name>": {
      "denoms": [
        "<label>": <value>,
        ... etc ...
      ]
    }
  }
}
  • The notion of backwards compatibility to allow denomination meta data to be submitted to registry or ledger for existing tokens so long as transaction is signed by policy holder would also be required. That would allow SundaeSwap to use this to re-brand their token denominations as they see fit. Using the proposed JSON nonsense above maybe something like this:
{
  "9a9693a9a37912a5097918f97918d15240c92ab729a0b7c4aa144d77": {
    "53554e444145": {
      "denoms": [
        "SCOOP": 1, // 53434f4f50 is the alternate base16 label
        "434f4e45": 1000, // CONE is the alternate ASCII label
        "SUNDAE": 1000000, // alias override of asset name 53554e444145
      ]
    }
  }
}

edit The main problem would be needing to link in the policy id of the new “SCOOP” tokens for backwards compatibility for subsequent minting. That might be as easy just a reference though. Similar to alias of asset name if the reference was omitted perhaps it is safe to assume this is a new type of asset that does not need legacy reference or there will never be anymore tokens minted so it doesn’t matter.

I don’t have time to write this up in any official capacity but would love for someone else to take the initiative (cough @HeptaSean cough)

1 Like

Could be just as easy as an add on in metadata that will let those rendering tokens know what to look up.
For example:
Let say “731.6” could mean- read this asset with 6 decimal places. If it’s just “731” assume no decimal places, for backwards compatibility. Only 16 bits of data added to the format. :grin:

For what it’s worth: I opened a Github issue with Daedalus and their response is that they did not respect the token registry information on decimal places for “legal” reasons, but will re-evaluate:
https://github.com/input-output-hk/daedalus/issues/2987#issuecomment-1137283405

2 Likes