1. Change the "value" key (which stores satoshis as a number) to "sats", which stores satoshis as bigint
The "value" does not really make sense; this is always "satoshis". It's extra confusing as satoshis can look quite close to XEC from a visual check, but in reality a factor of 100 is quite a difference indeed. Although the type "number" is ok, since the supply of satoshis is below JS max safe number, it is nice to use bigint since we then know it should always be an int.
2. Change the "amount" key (which stores base tokens as a string) to "atoms", which stores base tokens as bigint
"amount" is also an ambiguous key. Is it the decimalized amount of a token? or base tokens? what are base tokens anyway? We introduce the term "atoms" to describe the smallest unit of a token. Store as a bigint as this is always an int and also can be larger than JS safest integer. Decimalized amounts are usually a string, so keeping this bigint further distinguishes it from decimalized amounts.
We also update tokenBurnAmount -> tokenBurnAtoms, intentionalBurn -> intentionalBurnAtoms and change their type from string to bigint. We update error msgs to replace "base tokens" with "atoms"
The ecash-agora library uses the term "Token" in many places when instead what is meant is "atoms." We correct this.
We combine the changes here since
- These changes are related
- Any part of the changes here would itself be a breaking change
- CI allows us to confirm a proper implementation
It is not possible to do this incrementally as we need CI to confirm a correct implementation, and breaking changes to the libs must be implemented in the same diff. The diff history here loosely follows "one place at a time" implementation.
Goal here is to improve speed of development going forward. This ambiguity is something I have tripped over often in building apps, esp implementing ecash-agora in Cashtab (token vs base tokens, satoshis, nanosatoshis per token actually is nanosatoshis per atom, etc).
Looking to get this in before getting a strongly typed wallet library into the monorepo, which will be implemented in Cashtab to get rid of...a lot of spaghetti supporting tx building and wallet mgmt / migrations.
Note: not implemented in the Rust analogue to chronik-client. It should be implemented there as well. I'm not sure what our progress is like on getting that lib into the monorepo.