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.

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.

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.