Modeling assets with non-natural numbers in ERTP

[DavidBruant]

I think that all examples i have seen of ERTP either use natural numbers (1, 10, 1000, 32) or use objects to represent rights

Euros, dollars, bitcoins all use non-natural numbers in their usual representation

But JavaScript is notoriously inadequate for non-natural numbers (0.1 + 0.2 !== 0.3)

What is the approach recommanded by Agoric to model non-natural number assets?

(Attn @erights)

[katelynsills]

Currencies should always be represented in code in natural numbers (i.e. in cents for US dollars). In UI, those natural numbers are converted to the usual representation (i.e. dollars) by moving the decimal point. If you look at Ethereum's ERC20 tokens, they all have a field called decimal which describes how many places the decimal should be moved over for display purposes.

In ERTP, the extents are the smallest denomination of digital asset such that it is always a natural number. We don't currently have a place to put information about how it should be represented to the user, like decimal but we do need it.

[DavidBruant]

Currencies should always be represented in code in natural numbers (i.e. in cents for US dollars)

In Satoshis for bitcoins, then. There are 2100000000000000 (2.1*(10**15)) satoshis max. In JS, Number.MAX_SAFE_INTEGER is 9007199254740991 (~9*(10**15))
So, JS numbers work to represent bitcoins in ERTP. But if satoshis had been 10**-9 BTC instead of 10**-8 BTC, JS numbers would not have worked and it would have been necessary to use BigInt to represent them
I feel this is reasonable to prepare for this case. Related: Agoric/nat#10

[erights]

Yes, we should switch to BigInt soon and stop worrying about exceeding the SAFE_INTEGER range of floats.

[tyg]

Discussion about something that should be done in ERTP. Not relevant to Documentation until it's implemented in ERTP and we'll be told of that via other means than this issue.