Letâs take this rate for example (ex: Bitcoin / very low-value coin)

0.000000000000000000000000000000000000000000123456789123456789123456789123456789

IEEE 754 float will be 1.234567891234568e-43

It will fit in 64 bits.

The Nat representation (amount : nat, decimals:nat8) will be something like

(12345678912345678912345678912345678900000000000000000000000000000000000000000000000000000000000000000, 100) - 100 or something else, we have to eventually limit the precision.

if our rate is 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000123456789123456789123456789123456789

IEEE 754 float will be 1.234567891234568e-231 still 64bits

The Nat representation (amount : nat, decimals:nat8) will be something like

(123456789123456789123456789123456789000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, 231)

Redux - the most common and best IMO library for web state management states:

A BigInt is not a serializable value with JSON ( @lastmjs maybe has some thoughts on this) - the most common serialization format in JavaScript. A float is serializable.

If we use BigInt and casual libraries most devs would use, we will end up storing strings, or even worse for js - arrays.

In cases where our web app has to store tens of thousands of rates in the browserâs memory and we use common libraries. Our memory using Natâs will be a lot bigger. Not to mention calculations will be slower and we will have to convert things back and forth. Our contracts memory storing these numbers will also suffer - a lot less than js, but still enough to be noticeable.

Another solution would be to return (123456789123456789123456789123456789, 450) - adaptive decimals for every number. But there are no libraries right now that make these calculations easier. Still a js problem.

Third one - return the amounts without dividing them (Amount, Decimals, Amount, Decimals) Still has a bigger footprint and will require additional calculations.

So worst case scenario, we will be using 50 times more browser memory and things will be -my guess is- 20 times slower when doing calculations.

When the whole crypto is based on probabilities with a small chance of failing and the most stable coin prices - Bitcoin moves Â±10% a day and all exchanges report Â± 0.05% difference. Do we really need to make it hard for web developers and Motoko developers - to gain precision after 17 digits when even after 4 digits it is irrelevant?

I thought we were building the web3 not accounting3. Feel free to change my mind!

That said if we are wrong and you point us in the right direction. I think the whole DeFi community of builders will be eternally grateful. It doesnât seem like anyone has figured it out.