Yes indeed.
To add some more info, not for a particular purpose just so we can better understand a similar situation of bitcoin/lightning, the division to 8dp in bitcoin is not considered enough for lightning network use cases.
Lightning network uses millisatoshi is the base unit (type uint64). But this adds edge cases when closing a channel on the blockchain.
Firstly, there’s a limit on the smallest transaction amount in bitcoin which is known as ‘bitcoin dust’. It means a very low-value channel may not be relayed or mined and thus can’t be used to open or close a lightning network channel. So a 1 satoshi channel isn’t possible in the current design of bitcoin.
Secondly, when closing a channel, the balance may contain some millisatoshis which cannot be settled on the blockchain. These are all rounded down to the nearest satoshi when closing channels.
So that’s 21*(10^6)(10^8)(10^3) total millisatoshis, or 2^60.86, well within a u64 but outside the safe range for double precision floating point numbers.
Key takeaways from this
- Very fine resolution is anticipated to be necessary, hence millisatoshis as the base unit of the lightning network and not satoshis
- Fitting the total units into a double precision float (the only number type offered for many systems such as javascript) is violated in lightning network but it hasn’t blown up because of it
- There may be 10^9 subunits of safecoin (nanosafecoin) but it may be convention (set by vaults) to only accept transactions that are in multiples of 1000, effectively setting the number of transactable units to 10^6 (millisafecoin). If needed later this can be relaxed. It’s primarily meant as an antispam measure but it does have other benefits too.
Another thing to state (which I don’t find very convincing but let’s see what it provokes) is lightning channels will mostly be dealing with relatively small amounts. So the amount of millisatoshis in a channel would almost certainly always safely fit within a double precision value. Arithemtic on channels shouldn’t have problems with overflows etc. But the calculations that do have problems are unfortunately also the most valuable ones.
Thinking in a similar way, vaults and sections and traders and end-users will be unlikely to be dealing with the total nanosafecoin amount, only with smaller amounts that would fit within the safe range of a double precision float. So I think in probably 99.9%+ of cases using nanosafecoin won’t result in issues.
2^53 nanosafecoins is about 9,007,200 safecoins. Doing calculations with quantities more than that could become unsafe if the user isn’t aware of the details of their language / floating point safety.