Change Details

Implementing lessons learned from years of using and working in these libraries to remove ambiguity and improve speed / reduce bugs in future building. **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 1. They are all related 2. Any part of it would be a breaking change 3. CI allows us to confirm a proper implementation 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.

**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 1. They are all related 2. Any part of it would be a breaking change 3. CI allows us to confirm a proper 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.

Implementing lessons learned from years of using and working in these libraries to remove ambiguity and improve speed / reduce bugs in future building. **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 1. They are all related 2. Any part of it would be a breaking change 3. CI allows us to confirm a proper 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.