Change Details

Implementing some more lessons learned from years of using and working in these libraries. - "value" does not really make sense; this is always "satoshis". Extra confusing as satoshis can be quite close to XEC. 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. - "amount" also ambiguous. Is it the decimalized amount? or base tokens? what are base tokens anyway? We introduce "atoms" to describe the smallest unit of a token. Implement, also bigint instead of string (string is confusing as decimalized amounts are usually a string). We combine the change here since it is a breaking change and it is nice to do it all at once.

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 some more 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, Extra confusing as satoshis can bebut in reality a factor of 100 is quite close to XECa 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 - "amount" also ambiguous. Is it the decimalized amount? or base tokens? what are base tokens anyway? We introduce "atoms" to describe the smallest unit of a token. Implement,3. also bigint instead of string (string isCI allows us to confusing as decimalized amounts are usually a string).irm a proper implementation We combine the change here since it is a breaking change and it is nice to do it all at onceNote: 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.