xahau-patch

HISTORY.md

@@ -1,12 +1,12 @@
 # Release History (Changelog)
 
-Please see the individual HISTORY.md documents in each package for changes:
+Please see the individual HISTORY.md and XAHAU_HISTORY.md documents in each package for changes:
 
-* [Release History for **xrpl.js**](packages/xrpl/HISTORY.md) (formerly known as ripple-lib)
+* [Release History for **xahau.js**](packages/xrpl/HISTORY.md)
-  * The **xrpl** package is a TypeScript/JavaScript library for interacting with the [XRP Ledger](https://xrpl.org/).
+  * The **xahau** package is a TypeScript/JavaScript library for interacting with the [Xahau Ledger](https://docs.xahau.network/).
-* [Release History for **ripple-address-codec**](packages/ripple-address-codec/HISTORY.md)
+* [Release History for **xahau-address-codec**](packages/xahau-address-codec/HISTORY.md)
-  * The **ripple-address-codec** package provides functions for encoding and decoding XRP Ledger [addresses](https://xrpl.org/basic-data-types.html#addresses) and seeds.
+  * The **xahau-address-codec** package provides functions for encoding and decoding Xahau Ledger addresses and seeds.
-* [Release History for **ripple-binary-codec**](packages/ripple-binary-codec/HISTORY.md)
+* [Release History for **xahau-binary-codec**](packages/xahau-binary-codec/HISTORY.md)
-  * The **ripple-binary-codec** package provides functions to encode to, and decode from, the [XRPL binary serialization format](https://xrpl.org/serialization.html).
+  * The **xahau-binary-codec** package provides functions to encode to, and decode from, the Xahau binary serialization format.
-* [Release History for **ripple-keypairs**](packages/ripple-keypairs/HISTORY.md)
+* [Release History for **xahau-keypairs**](packages/xahau-keypairs/HISTORY.md)
-  * The **ripple-keypairs** package implements [XRPL cryptographic keypair](https://xrpl.org/cryptographic-keys.html) and wallet generation, with support for rfc6979 and EdDSA deterministic signatures.
+  * The **xahau-keypairs** package implements Xahau cryptographic keypair and wallet generation, with support for rfc6979 and EdDSA deterministic signatures.

MIGRATION.md

@@ -1,295 +0,0 @@
-# Migration Guide
-
-In xrpl.js 3.0, we've made significant improvements that result in a 60% reduction in bundle size for browser applications. We've also eliminated the need for polyfills with minimal disruption to existing code. This was achieved by replacing node-specific dependencies with ones that are compatible with browsers.
-
-The two main changes you'll notice are:
-* A breaking change to `Wallet` object creation, to use a more performant algorithm by default. See [here](#8-wallet-functions-default-to-ed25519-instead-of-secp256k1-signing-algorithm) for details.
-* Replacing `Buffer` with `Uint8Array` across the board. This was done since browsers don't support `Buffer`. Fortunately, this transition is relatively straightforward, as `Buffer` is a subclass of `Uint8Array`, meaning in many circumstances `Buffer` can be directly replaced by `Uint8Array`. The primary difference is that `Buffer` has additional helper functions. We've listed the affected client library functions below in the `Uint8Array` section for your reference.
-
-This migration guide also applies to:
-- `ripple-address-codec` 4.3.1 -> 5.0.0
-- `ripple-binary-codec` 1.11.0 -> 2.0.0
-- `ripple-keypairs` 1.3.1 -> 2.0.0
-- `xrpl-secret-numbers` 0.3.4 -> `@xrplf/secret-numbers` 1.0.0
-
-# Why update to 3.0?
-
-At a high level:
-
-1. 60% filesize reduction
-2. Simplified setup by removing polyfills
-3. Increased reliability through more browser testing
-
-<aside>
-💡 Also, with 3.0, the [reference docs](https://js.xrpl.org/) have received a massive update to include examples, more readable type information, and properly display documentation on functions which are part of the `Client` class.
-</aside>
-
-## 1. 60% size reduction
-
-Through simplifying 3rd party dependencies, we were able to reduce the size of xrpl.js by 60%.
-
-A major contributor to the project's large bundle size was the use of polyfills, which replicated Node-specific features in the browser. To address this, we transitioned to using 3rd party packages that inherently supported both Node and browser environments.
-
-Another simple fix was removing `lodash` by using es6 array methods and porting over simple helper utilities.
-
-Another substantial reduction came from simplifying five large number libraries xrpl.js depended on down to just one. Previously, we relied on `decimal.js`, `big-integer`, `bignumber.js`, and two versions of `bn.js` due to elliptic's transitive dependency tree.
-
-We were able to streamline this by adopting `@noble` to replace `elliptic`, resulting in the use of just one version of `bn.js`. Within our library we also switched to using `bignumber.js` consistently across the board.
-
-## 2. No more polyfills required (simplified install)
-
-Polyfills made it hard to setup xrpl.js in the browser as they required custom bundler configs. By using dependencies and browser-native features, xrpl.js can now work just by installing from `npm` in most cases other than react-native.
-
-For the cryptography libraries, we switched from using `elliptic`, `create-hash`, and other crypto polyfills to using the `@noble` suite of packages. For situations where node-specific crypto functions performed better, we created `@xrplf/isomorphic` to dynamically choose which implementation to use depending on the runtime environment.
-
-<aside>
-💡 The `@noble` suite of packages includes `@noble/hashes`, `@noble/curves`, `@scure/bip32`, `@scure/bip39`, and `@scure/base`
-</aside>
-
-We eliminated the polyfills for `http`, `https`, and `url` by using the native `fetch` in the browser.
-
-The easiest to replace were `assert` (which was replaced by simple conditions & exceptions) and `utils` (which used `JSON.stringify` instead of `inspect`).
-
-Lastly, the `buffer` polyfill turned out to be the trickiest to remove, resulting in the largest number of breaking changes. Since the `Buffer` object is not native to the browser all apis were migrated to the superclass of `Buffer` → `Uint8Array`s. For a detailed write up of why we and many libraries are choosing to make this transition, check out this [blog post](https://sindresorhus.com/blog/goodbye-nodejs-buffer) by Sindre Sorhus.
-
-List of all replaced polyfills that can potentially be removed from your webpack.config.js / vite.config.js / other bundling config files as they are no longer needed in xrpl.js. **Note that you may still need these for other libraries you depend on / code you have written.**
- - `assert`
- - `buffer`
- - `crypto`
- - `events`
- - `http`
- - `https`
- - `os`
- - `stream`
- - `url`
- - `ws`
-
-## 3. Increased Reliability Through More Browser Testing
-
-With xrpl.js 3.0, we improved our test coverage in the browser. Specifically, we added browser unit testing to all packages in the monorepo other than the `xrpl` package. Note that the `xrpl` package has browser coverage through our integration tests.
-
-To implement this enhancement, we included a karma configuration in every project utilizing webpack to bundle each library. This allowed us to execute tests in Chrome. We are actively working towards extending this support to include running unit tests for the xrpl package in Chrome as an integral part of our continuous integration (CI) process in the near future.
-
-# Breaking Changes Detailed Migration Guide
-
-Here’s a high-level overview of the breaking changes.
-
-<aside>
-💡 Note that the vast majority of these changes are very small typing changes, which should have direct 1-line replacements.
-</aside>
-
-1. The largest change is that all instances of `Buffer` have been replaced by `Uint8Array` **[Link](#1-buffer-to-uint8array)**
-2. All “large number” types have been consolidated to either `bigint` or `BigNumber` **[Link](#2-large-number-handling)**
-3. Polyfill configuration changes **[Link](#3-polyfill-configuration-changes)**
-4. `dropsToXRP` and `Client.getXrpBalance` now return a `number` instead of a `string` (`xrpToDrops` is UNCHANGED) **[Link](#4-dropstoxrp-and-clientgetxrpbalance-now-return-a-number-instead-of-a-string)**
-5. `xrpl-secret-numbers` has been moved into the mono-repo as `@xrplf/secret-numbers`  **[Link](#5-xrpl-secret-numbers-has-been-moved-into-the-mono-repo-as-xrplfsecret-numbers)**
-6. Support for Node 14 has been dropped **[Link](#6-support-for-node-14-has-been-dropped)**
-7. Configuring proxies with the Client  **[Link](#7-configuring-proxies-with-the-client)**
-8. Bug fix: Setting an explicit `algorithm` when generating a wallet works now **[Link](#8-bug-fix-setting-an-explicit-algorithm-when-generating-a-wallet-works-now)**
-9. `AssertionError` → `Error` **[Link](#9-assertionerror-→-error)**
-10. Pre-bundle browser builds **[Link](#10-pre-bundle-browser-builds)**
-11. We’ve updated the `Transaction` type to include pseudotransactions **[Link](#11-transaction-type)**
-12. `authorizeChannel` was moved **[Link](#12-authorizechannel-was-moved)**
-13. Removed the deprecated `BroadcastClient` **[Link](#13-weve-removed-the-deprecated-broadcastclient)**
-
-Without further ado, here’s the detailed changes and how to migrate:
-
-### 1. `Buffer` to `Uint8Array`
-
-In most cases, `Uint8Array` can act as a drop-in replacement for `Buffer` data since `Buffer` is a subclass of `Uint8Array`. The main differences are that `Uint8Array` has fewer helper methods, and slightly different syntax for converting from other data types. This difference primarily affects methods whose return type is changed. (For functions whose parameters were changed to `Uint8Array`, `Buffer` should still be a valid parameter as it’s a subclass of `Uint8Array`)
-
-Please see this [blog post](https://sindresorhus.com/blog/goodbye-nodejs-buffer) for detailed examples of how to migrate `Buffer` to `Unit8Array`.
-
-Below is a list of every method affected. 
-
-**`ripple-address-codec`**
-
-- `decodeAccountID`
-- `encodeAccountID`
-- `decodeAccountPublic`
-- `encodeAccountPublic`
-- `decodeNodePublic`
-- `encodeNodePublic`
-- `encodeSeed`
-- `decodeXAddress`
-- `encodeXAddress`
-
-**`ripple-binary-codec`**
-
-- `SerializedType` constructor and `toBytes` . Its sub-classes:
-    - `AccountID`
-    - `Amount`
-    - `Blob`
-    - `Currency`
-    - `Hash`
-    - `Hash128`
-    - `Hash160`
-    - `Hash256`
-    - `Issue`
-    - `PathSet`
-    - `STArray`
-    - `STObject`
-    - `UInt`
-    - `UInt8`
-    - `UInt16`
-    - `UInt32`
-    - `UInt64`
-    - `Vector256`
-    - `XChainBridge`
-- `ShaMapNode.hashPrefix`
-- `BinarySerializer.put`
-- `BytesList.put` and `BytesList.toBytes`
-- `BinaryParser.read`
-- `BinaryParser.readVariableLength`
-- `Quality.encode` and `Quality.decode`
-- `Sha512Half.put` and `Sha512Half.finish256`
-- `transactionID`
-- `sha512Half`
-- Entries of `HashPrefix`
-- Type `FieldInstance.header`
-- `Bytes.bytes`
-- `signingClaimData`
-- `serializeObject`
-- `makeParser`
-
-**`secret-numbers`**
-
-- `entropyToSecret`
-- `randomEntropy`
-- `Account` constructor
-
-**`xrpl`**
-
-- `rfc1751MnemonicToKey`
-
-### 2. Large Number Handling
-
-`bn.js`, `decimal.js` and `big-integer` were removed as dependencies. They usages were replaced with `BigNumber` from `big-number.js` (was already a dependency) and the native javascript object `BigInt`.
-
-- `UInt64.valueOf` returns `bigint` instead of `BigInteger`
-- `SerializeType.from` can take a `bigint` instead `BigInteger`
-- `ledgerHash` had its param object change so that `total_coins` in a `bigint` instead `BigInteger`
-- `Quality.decode` returns a `BigNumber` instead of a `Decimal`
-- `Amount.assertIouIsValid` take a `BigNumber` instead `Decimal`
-- `Amount.verifyNoDecimal` takes a `BigNumber` instead `Decimal`
-
-### 3. Polyfill configuration changes
-
-For `vite` and `create-react-app` you can remove all xrpl.js polyfills/configurations. This also includes the custom mappings for `ws` to `WsWrapper` and the exclusion of `https-proxy-agent`. You should also be able to remove polyfills for other bundlers / frameworks, but we have only extensively tested `vite` and `create-react-app` configurations.
-
-**React Native**
-
-Please follow the updated guide at UNIQUE_SETUPS.md (Many polyfills are no longer required, but not all are eliminated for this environment).
-
-### 4. `dropsToXRP` and `Client.getXrpBalance` now return a `number` instead of a `string` (`xrpToDrops` is UNCHANGED)
-
-This should make it easier to work with the numbers. Because the max size of XRP is 100 billion, we can use a `number` instead of a larger type like `bigint` (which is normally needed when working with issued tokens on the XRPL).
-
-Please note that `xrpToDrops`, which was commonly used to set the amount of XRP that is in a transaction is UNCHANGED as an `Amount` type in a `Transaction` needs a `string` input.
-
-### 5. `xrpl-secret-numbers` has been moved into the mono-repo as `@xrplf/secret-numbers`
-
-This move allows us to continue maintaining this package going forward as well as giving us more control over the dependencies to avoid needing polyfills.
-
-If you were using `xrpl-secret-numbers` directly, please update your imports to the new package (`@xrplf/secret-numbers`) to receive updates going forward.
-
-Besides making changes to this package to update from `Buffer` → `Uint8Array` you will need to update all places where you use functions on the `Util` object. These methods are now at the root of the library. These methods include:
-
-- `Utils.randomEntropy` → `randomEntropy`
-- `Utils.randomSecret` → `randomSecret`
-- `Utils.entropyToSecret` → `entropyToSecret`
-- `Utils.secretToEntropy` → `secretToEntropy`
-- `Utils.calculateChecksum` → `calculateChecksum`
-- `Utils.checkChecksum` → `checkChecksum`
-- `Utils.parseSecretString` → `parseSecretString`
-
-### 6. Support for Node 14 has been dropped
-
-Node 14 has stopped receiving security updates since April 2023, and so we’ve decided to no longer support it going forward. Please update to one of the supported versions of Node as listed in xrpl.js’s `README.md`.
-
-### 7. Configuring proxies with the Client
-
-The way to configure proxies for `Client` has changed. It is now done by specifying the `agent` parameter on the `ConnectionOptions` config.
-
-You can generate an `agent` with libraries such as `https-proxy-agent` or any that implements `http.Agent`.
-
-This was done to remove a hard dependency on `https-proxy-agent` when running in the browser and to support `https-proxy-agent@7` which changed several option names. Proxy support was never supported in the browser, and merely burdened xrpl bundles with unused dependencies.
-
-**Before**
-
-`{
-  proxy: `ws://127.0.0.1:${port}`,
-  authorization: 'authorization',
-  trustedCertificates: ['path/to/pem'],
-}`
-
-**After**
-
- `{
-   agent: new HttpsProxyAgent<string>(`ws://127.0.0.1:${port}`, {
-     ca: ['path/to/pem'],
-   }),
-   authorization: 'authorization'
- }`
-
-### 8. `Wallet` functions default to `ed25519` instead of `secp256k1` signing algorithm
-
-In previous releases of this library, `Wallet.generate()` and `Wallet.fromSeed` were ignoring the `algorithm` parameter. Instead, the algorithm was assumed from the seed provided; if it started with `sEd`, it would use `ed25519`, and otherwise it would use `secp256k1`. However, seeds do not actually have algorithms; a seed starting with `s...` can still use the `ed25519` algorithm.
-
-With 3.0, we updated the default signing algorithm used by the `Wallet` object to always be `ed25519` in order to default to the higher-performance algorithm. This is a breaking change to all functions used to generate a Wallet, so if you have a pre-existing XRPL account that you're using to generate a specific Wallet using older versions of xrpl.js, you may need to specify that you are using `secp256k1` as the algorithm to decode your private key / seed / etc to get the same behavior as before. See below for specifically how to update your code.
-
-If you are creating new accounts each time (ex. via `Client.fundWallet` or `Wallet.generate`), you do not need to specify the signing algorithm.
-
-**Before**
-```
-Wallet.fromSeed('s...')
-Wallet.fromEntropy(entropy)
-deriveKeyPair(seed="s...")
-```
-
-**After**
-```
-Wallet.fromSeed(seed='s...',algorithm: 'ecdsa-secp256k1')
-Wallet.fromEntropy(entropy, opts={algorithm: 'ecdsa-secp256k1'})
-deriveKeypair(seed='s...', opts={ algorithm: 'ecdsa-secp256k1' }) (ripple-keypairs)
-```
-
-### 9. `AssertionError` → `Error`
-
-In order to get rid of the `assert` polyfill, we’ve replaced `AssertionError`s with `Error` exceptions. We’ve also updated the error messages to be more descriptive. If you were catching those specific errors, you will have to update your catch statements.
-
-This impacts most of `ripple-keypairs` functions but only if you already had issues with incompatible values.
-
-### 10. Pre-bundle browser builds
-
-If you use the pre bundled version of the library you will need to make the following changes:
-
-- Change any references to `dist/browerified.js` to `build/xrplf-secret-numbers-latest.js`.
-- Access any methods as properties of `xrplf_secret_numbers` instead of using browserify's loader.
-
-### 11. Transaction` type
-
-`Transaction` has been updated to include `PseudoTransaction`s. To get the equivalent of the old `Transaction` type which only included transactions users could submit, please use `SubmittableTransaction`.
-
-This effectively changes the signature of the following methods:
-
-- `Client.autofill`
-- `Client.submit`
-- `Client.submitAndWait`
-- `Client.prepareTransaction`
-- `getSignedTx`
-- `isAccountDelete`
-
-### 12. `authorizeChannel` was moved
-
-We’ve moved `authorizeChannel` from `wallet/signer` to `wallet/authorizeChannel` to solve a circular dependency issue. You may have to update your import path as a result.
-
-### 13. We’ve removed the deprecated `BroadcastClient`
-
-This feature was never fully implemented, and was marked as deprecated for several years. With 3.0 we’ve fully removed any code relating to it.
-
-# Wrap up
-
-Thanks for taking the time to read & migrate to xrpl.js 3.0. Hopefully this helps speed up browser applications, simplifies setup, and provides a better development experience.
-
-If you run into any problems, please [create an issue](https://github.com/XRPLF/xrpl.js/issues) on our GitHub repo.

README.md

@@ -2,12 +2,12 @@
 
 A JavaScript/TypeScript library for interacting with the Xahau Ledger
 
-[![NPM](https://nodei.co/npm/xahau.png)](https://www.npmjs.org/package/xrpl)
+[![NPM](https://nodei.co/npm/xahau.png)](https://www.npmjs.org/package/xahau)
-![npm bundle size](https://img.shields.io/bundlephobia/min/xrpl)
+![npm bundle size](https://img.shields.io/bundlephobia/min/xahau)
 
 This is the recommended library for integrating a JavaScript/TypeScript app with the Xahau Ledger, especially if you intend to use advanced functionality such as IOUs, payment paths, the decentralized exchange, account settings, payment channels, escrows, multi-signing, and more.
 
-## [➡️ Reference Documentation](http://js.xahau.org)
+<!-- ## [➡️ Reference Documentation](http://js.xahau.org)
 
 See the full reference documentation for all classes, methods, and utilities.
 
@@ -19,7 +19,7 @@ See the full reference documentation for all classes, methods, and utilities.
 4. Subscribing to changes in the ledger ([Ex. ledger, transactions, & more...](https://xahau.org/subscribe.html))
 5. Parsing ledger data into more convenient formats ([`xrpToDrops`](https://js.xahau.org/functions/xrpToDrops.html) and [`rippleTimeToISOTime`](https://js.xahau.org/functions/rippleTimeToISOTime.html))
 
-All of which works in Node.js (tested for v18+) & web browsers (tested for Chrome).
+All of which works in Node.js (tested for v18+) & web browsers (tested for Chrome). -->
 
 # Quickstart
 
@@ -32,21 +32,21 @@ All of which works in Node.js (tested for v18+) & web browsers (tested for Chrom
 In an existing project (with package.json), install xahau.js with:
 
 ```
-$ npm install --save xrpl
+$ npm install --save xahau
 ```
 
 Or with `yarn`:
 
 ```
-$ yarn add xrpl
+$ yarn add xahau
 ```
 
 Example usage:
 
 ```js
-const xrpl = require("xrpl");
+const xahau = require("xahau");
 async function main() {
-  const client = new xahau.Client("wss://s.altnet.rippletest.net:51233");
+  const client = new xahau.Client("wss://xahau-test.net");
   await client.connect();
 
   const response = await client.request({
@@ -61,9 +61,6 @@ async function main() {
 main();
 ```
 
-For a more in-depth example, you can copy/forking this Code Sandbox template!
-<br>https://codesandbox.io/s/xrpl-intro-pxgdjr?file=/src/App.js
-
 It goes through:
 
 1. Creating a new test account
@@ -74,22 +71,20 @@ It goes through:
 
 If you're using xahau.js with React or Deno, you'll need to do a couple extra steps to set it up:
 
-- [Using xahau.js with a CDN](https://github.com/XRPLF/xahau.js/blob/main/UNIQUE_SETUPS.md#using-xrpljs-from-a-cdn)
+- [Using xahau.js with a CDN](https://github.com/XRPLF/xahau.js/blob/main/UNIQUE_SETUPS.md#using-xahaujs-from-a-cdn)
-- [Using xahau.js with `create-react-app`](https://github.com/XRPLF/xahau.js/blob/main/UNIQUE_SETUPS.md#using-xrpljs-with-create-react-app)
+- [Using xahau.js with `create-react-app`](https://github.com/XRPLF/xahau.js/blob/main/UNIQUE_SETUPS.md#using-xahaujs-with-create-react-app)
-- [Using xahau.js with `React Native`](https://github.com/XRPLF/xahau.js/blob/main/UNIQUE_SETUPS.md#using-xrpljs-with-react-native)
+- [Using xahau.js with `React Native`](https://github.com/XRPLF/xahau.js/blob/main/UNIQUE_SETUPS.md#using-xahaujs-with-react-native)
-- [Using xahau.js with `Vite React`](https://github.com/XRPLF/xahau.js/blob/main/UNIQUE_SETUPS.md#using-xrpljs-with-vite-react)
+- [Using xahau.js with `Vite React`](https://github.com/XRPLF/xahau.js/blob/main/UNIQUE_SETUPS.md#using-xahaujs-with-vite-react)
-- [Using xahau.js with `Deno`](https://github.com/XRPLF/xahau.js/blob/main/UNIQUE_SETUPS.md#using-xrpljs-with-deno)
+- [Using xahau.js with `Deno`](https://github.com/XRPLF/xahau.js/blob/main/UNIQUE_SETUPS.md#using-xahaujs-with-deno)
 
 ## Documentation
 
 As you develop with xahau.js, there's two sites you'll use extensively:
 
-1. [xahau.org](https://xahau.org/references.html) is the primary source for:
+1. [docs.xahau.network](https://docs.xahau.network/technical/protocol-reference) is the primary source for:
-   - How the ledger works ([See Concepts](https://xahau.org/concepts.html#main-page-header))
+   - How the ledger works ([See Concepts](https://docs.xahau.network/))
-   - What kinds of transactions there are ([Transaction Types](https://xahau.org/transaction-types.html#transaction-types))
+   - What kinds of transactions there are ([Transaction Types](https://docs.xahau.network/technical/protocol-reference/transactions/transaction-types))
-   - Requests you can send ([Public API Methods](https://xahau.org/public-api-methods.html))
+   - Requests you can send ([Public API Methods](https://docs.xahau.network/features/http-websocket-apis))
-   - Tutorials for interacting with various features of the ledger ([Tutorials](https://xahau.org/tutorials.html#main-page-header))
-2. [js.xahau.org](https://js.xahau.org/) has the reference docs for this library
 
 ### Mailing Lists
 
@@ -97,21 +92,8 @@ If you want to hear when we release new versions of xahau.js, you can join our l
 
 - [Subscribe to xahau-announce](https://groups.google.com/g/xahau-announce)
 
-If you're using the Xahau Ledger in production, you should run a [rippled server](https://github.com/ripple/rippled) and subscribe to the ripple-server mailing list as well.
+If you're using the Xahau Ledger in production, you should run a [xahaud server](https://github.com/Xahau/xahaud) and subscribe to the xahau-server mailing list as well.
 
-- [Subscribe to ripple-server](https://groups.google.com/g/ripple-server)
+- [Subscribe to xahau-server](https://groups.google.com/g/xahau-server)
 
-## Asking for help
+You are also welcome to create an [issue](https://github.com/Xahau/xahau.js/issues) here and we'll do our best to respond within 3 days.
-
-One of the best spots to ask for help is in the [XRPL Developer Discord](https://xrpldevs.org) - There's a channel for xahau.js where other community members can help you figure out how to accomplish your goals.
-
-You are also welcome to create an [issue](https://github.com/XRPLF/xahau.js/issues) here and we'll do our best to respond within 3 days.
-
-## Key Links
-
-- [xahau.js Reference Docs](https://js.xahau.org/)
-- [xahau.org (Detailed docs on how the XRPL works)](https://xahau.org/references.html)
-- [XRPL Code Samples](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples)
-- [#javascript in the XRPL Developer Discord for questions & support](https://xrpldevs.org)
-- [xahau-announce (The mailing list for new xahau.js versions)](https://groups.google.com/g/xahau-announce)
-- [Applications that use xahau.js](https://github.com/XRPLF/xahau.js/blob/main/APPLICATIONS.md) (You can open a PR to add your project!)

SECURITY.md

@@ -1,30 +0,0 @@
-# Security Policy
-
-## Supported Versions
-
-This table shows which versions of xrpl.js are currently supported with security updates:
-
-| Version | Supported              |
-| ------- | ---------------------- |
-| 2.x     | :white_check_mark: Yes |
-| 1.x     | :white_check_mark: Yes |
-| 0.x     | :x:                No  |
-
-## Responsible disclosure security policy
-
-The responsible disclosure of vulnerabilities helps to protect users of the project. Vulnerabilities are first triaged in a private manner, and only publicly disclosed after a reasonable time period that allows patching the vulnerability and provides an upgrade path for users.
-
-When contacting us directly via email, we will do our best to respond in a reasonable time to resolve the issue. Do not disclose the vulnerability until it has been patched and users have been given time to upgrade.
-
-We kindly ask you to refrain from malicious acts that put our users, the project, or any of the project’s team members at risk.
-
-## Reporting a security issue
-
-Security is a top priority. But no matter how much effort we put into security, there can still be vulnerabilities present.
-
-If you discover a security vulnerability, please use the following means of communications to report it to us:
-
-- Report the security issue to bugs@ripple.com
-- [Ripple Bug Bounty](https://ripple.com/bug-bounty/)
-
-Your efforts to responsibly disclose your findings are sincerely appreciated and will be taken into account to acknowledge your contributions.

packages/xahau-address-codec/README.md

@@ -1,4 +1,4 @@
-# ripple-address-codec
+# xahau-address-codec
 
 [![NPM Version][npm-version-image]][npm-url]
 [![NPM Downloads][npm-downloads-image]][npm-url]
@@ -7,9 +7,9 @@
 
 Functions for encoding and decoding XRP Ledger addresses and seeds.
 
-Also includes support for encoding/decoding [rippled validator (node) public keys](https://xrpl.org/run-rippled-as-a-validator.html).
+Also includes support for encoding/decoding [xahaud validator (node) public keys](https://xrpl.org/run-rippled-as-a-validator.html).
 
-[![NPM](https://nodei.co/npm/ripple-address-codec.png)](https://www.npmjs.org/package/ripple-address-codec)
+[![NPM](https://nodei.co/npm/xahau-address-codec.png)](https://www.npmjs.org/package/xahau-address-codec)
 
 ## X-address Conversion
 
@@ -22,15 +22,13 @@ All tools and apps in the XRP Ledger ecosystem are encouraged to adopt support f
 Convert a classic address and (optional) tag to an X-address. If `tag` is `false`, the returned X-address explicitly indicates that the recipient does not want a tag to be used. If `test` is `true`, consumers of the address will know that the address is intended for use on test network(s) and the address will start with `T`.
 
 ```js
-> const api = require('ripple-address-codec')
+> const api = require('xahau-address-codec')
 > api.classicAddressToXAddress('rGWrZyQqhTp9Xu7G5Pkayo7bXjH4k4QYpf', 4294967295)
 'XVLhHMPHU98es4dbozjVtdWzVrDjtV18pX8yuPT7y4xaEHi'
 ```
 
-Encode a test address e.g. for use with [Testnet or Devnet](https://xrpl.org/xrp-testnet-faucet.html):
-
 ```js
-> const api = require('ripple-address-codec')
+> const api = require('xahau-address-codec')
 > api.classicAddressToXAddress('r3SVzk8ApofDJuVBPKdmbbLjWGCCXpBQ2g', 123, true)
 'T7oKJ3q7s94kDH6tpkBowhetT1JKfcfdSCmAXbS75iATyLD'
 ```
@@ -40,7 +38,7 @@ Encode a test address e.g. for use with [Testnet or Devnet](https://xrpl.org/xrp
 Convert an X-address to a classic address and tag. If the X-address did not have a tag, the returned object's `tag` will be `false`. (Since `0` is a valid tag, instead of `if (tag)`, use `if (tag !== false)` if you want to check for a tag.) If the X-address is intended for use on test network(s), `test` will be `true`; if it is intended for use on the main network (mainnet), `test` will be `false`.
 
 ```js
-> const api = require('ripple-address-codec')
+> const api = require('xahau-address-codec')
 > api.xAddressToClassicAddress('XVLhHMPHU98es4dbozjVtdWzVrDjtV18pX8yuPT7y4xaEHi')
 {
   classicAddress: 'rGWrZyQqhTp9Xu7G5Pkayo7bXjH4k4QYpf',
@@ -54,7 +52,7 @@ Convert an X-address to a classic address and tag. If the X-address did not have
 Returns `true` if the provided X-address is valid, or `false` otherwise.
 
 ```js
-> const api = require('ripple-address-codec')
+> const api = require('xahau-address-codec')
 > api.isValidXAddress('XVLhHMPHU98es4dbozjVtdWzVrDjtV18pX8yuPT7y4xaEHi')
 true
 ```
@@ -127,7 +125,7 @@ Convert an X-address to its classic address, tag, and network ID.
 ### Other functions
 
 ```js
-> var api = require('ripple-address-codec');
+> var api = require('xahau-address-codec');
 > api.decodeSeed('sEdTM1uX8pu2do5XvTnutH6HsouMaM2')
 { version: [ 1, 225, 75 ],
   bytes: [ 76, 58, 29, 33, 63, 189, 251, 20, 199, 194, 141, 96, 148, 105, 179, 65 ],
@@ -177,7 +175,7 @@ This tells jest to output code coverage info in the `./coverage` directory, in a
 
 ## Releases
 
-Use the [xrpl.js release process](https://github.com/XRPLF/xrpl.js/blob/main/CONTRIBUTING.md#release).
+Use the [xahau.js release process](https://github.com/Xahau/xahau.js/blob/main/CONTRIBUTING.md#release).
 
 ## Acknowledgements
 
@@ -187,10 +185,10 @@ This library references and adopts code and standards from the following sources
 - [XRPL Tagged Address Codec](https://github.com/xrp-community/xrpl-tagged-address-codec) by @WietseWind
 - [X-Address transaction functions](https://github.com/codetsunami/xrpl-tools/tree/master/xaddress-functions) by @codetsunami
 
-[coveralls-image]: https://badgen.net/coveralls/c/github/ripple/ripple-address-codec/master
+[coveralls-image]: https://badgen.net/coveralls/c/github/ripple/xahau-address-codec/master
 [coveralls-url]: https://coveralls.io/r/ripple/ripple-address/codec?branch=master
-[npm-downloads-image]: https://badgen.net/npm/dm/ripple-address-codec
+[npm-downloads-image]: https://badgen.net/npm/dm/xahau-address-codec
-[npm-url]: https://npmjs.org/package/ripple-address-codec
+[npm-url]: https://npmjs.org/package/xahau-address-codec
-[npm-version-image]: https://badgen.net/npm/v/ripple-address-codec
+[npm-version-image]: https://badgen.net/npm/v/xahau-address-codec
-[travis-image]: https://badgen.net/travis/ripple/ripple-address-codec/master
+[travis-image]: https://badgen.net/travis/ripple/xahau-address-codec/master
-[travis-url]: https://travis-ci.org/github/ripple/ripple-address-codec
+[travis-url]: https://travis-ci.org/github/ripple/xahau-address-codec

packages/xahau-binary-codec/CONTRIBUTING.md

@@ -24,6 +24,6 @@ To add a new serializable type, first read through `enum`'s [README.md](src/enum
 After that, if you need to add a new type of data to be serialized / deserialized (for example adding a bigger int than [uint-64.ts](src/types/uint-64.ts)) you can follow these steps:
 1. Create a new class that extends `SerializedType`
   - If your type is intended to be comparable to native values like `number`, you should extend `Comparable<YourObjectType | nativeValue>`. See [uint-64.ts](src/types/uint-64.ts) for an example of this.
-2. Add your new subclass of `SerializableType` to `coreTypes` in [packages/ripple-binary-codec/src/types/index.ts](packages/ripple-binary-codec/src/types/index.ts)
+2. Add your new subclass of `SerializableType` to `coreTypes` in [packages/xahau-binary-codec/src/types/index.ts](packages/xahau-binary-codec/src/types/index.ts)
   - The `coreTypes` variable is used by `BinaryParser` and `BinarySerializer` to understand what possible types exist when reading / writing binary data.
 3. Write a unit tests for this type that demonstrates it can properly serialize / deserialize and throw the proper errors (see [Adding Tests](#adding-tests))

packages/xahau-binary-codec/README.md

@@ -1,12 +1,12 @@
-# ripple-binary-codec [![NPM](https://img.shields.io/npm/v/ripple-binary-codec.svg)](https://npmjs.org/package/ripple-binary-codec)
+# xahau-binary-codec [![NPM](https://img.shields.io/npm/v/xahau-binary-codec.svg)](https://npmjs.org/package/xahau-binary-codec)
 
 Functions to encode/decode to/from the ripple [binary serialization format](https://xrpl.org/serialization.html)
 
-[![NPM](https://nodei.co/npm/ripple-binary-codec.png)](https://www.npmjs.org/package/ripple-binary-codec)
+[![NPM](https://nodei.co/npm/xahau-binary-codec.png)](https://www.npmjs.org/package/xahau-binary-codec)
 
 ## API
 ```js
-> const api = require('ripple-binary-codec')
+> const api = require('xahau-binary-codec')
 ```
 
 
@@ -37,22 +37,22 @@ Encode a transaction object into a hex-string. Note that encode filters out fiel
   OwnerCount: 0,
   PreviousTxnID: 'DF530FB14C5304852F20080B0A8EEF3A6BDD044F41F4EBBD68B8B321145FE4FF',
   Balance: '10000000000',
-  Account: 'rLs1MzkFWCxTbuAHgjeTZK4fcCDDnf2KRv' 
+  Account: 'rLs1MzkFWCxTbuAHgjeTZK4fcCDDnf2KRv'
 })
 '1100612200000000240000000125000000072D0000000055DF530FB14C5304852F20080B0A8EEF3A6BDD044F41F4EBBD68B8B321145FE4FF6240000002540BE4008114D0F5430B66E06498D4CEEC816C7B3337F9982337'
 ```
 
-#### X-Address Compatibility 
+#### X-Address Compatibility
-  * ripple-binary-codec handles X-addresses by looking for a few specific files (Account/SourceTag, Destination/DestinationTag).
+  * xahau-binary-codec handles X-addresses by looking for a few specific files (Account/SourceTag, Destination/DestinationTag).
   * If other fields (in the future) must to support X-addresses with tags, this library will need to be updated.
   * When decoding rippled binary, the output will always output classic address + tag, with no X-addresses. X-address support only applies when encoding to binary.
 
 #### Encoding Currency Codes
   * The standard format for currency codes is a three-letter string such as `USD`. This is intended for use with ISO 4217 Currency Codes.
   * Currency codes must be exactly 3 ASCII characters in length and there are [a few other rules](https://xrpl.org/currency-formats.html#currency-codes).
-  * ripple-binary-codec allows any 3-character ASCII string to be encoded as a currency code, although rippled may enforce tighter restrictions.
+  * xahau-binary-codec allows any 3-character ASCII string to be encoded as a currency code, although rippled may enforce tighter restrictions.
   * When _decoding_, if a currency code is three uppercase letters or numbers (`/^[A-Z0-9]{3}$/`), then it will be decoded into that string. For example,`0000000000000000000000004142430000000000` decodes as `ABC`.
-  * When decoding, if a currency code is does not match the regex, then it is not considered to be an ISO 4217 or pseudo-ISO currency. ripple-binary-codec will return a 160-bit hex-string (40 hex characters). For example, `0000000000000000000000006142430000000000` (`aBC`) decodes as `0000000000000000000000006142430000000000` because it contains a lowercase letter.
+  * When decoding, if a currency code is does not match the regex, then it is not considered to be an ISO 4217 or pseudo-ISO currency. xahau-binary-codec will return a 160-bit hex-string (40 hex characters). For example, `0000000000000000000000006142430000000000` (`aBC`) decodes as `0000000000000000000000006142430000000000` because it contains a lowercase letter.
 
 ### encodeForSigning(json: object): string
 
@@ -72,7 +72,7 @@ Encode the transaction object for multi-signing.
 '5D06F4C3362FE1D0'
 ```
 
-### decodeQuality(value: string): string 
+### decodeQuality(value: string): string
 ```js
 > api.decodeQuality('5D06F4C3362FE1D0')
 '195796912.5171664'

packages/xahau-keypairs/README.md

@@ -1,10 +1,10 @@
-# ripple-keypairs [![NPM](https://img.shields.io/npm/v/ripple-keypairs.svg)](https://npmjs.org/package/ripple-keypairs) [![Build Status](https://img.shields.io/travis/ripple/ripple-keypairs/master.svg)](https://travis-ci.org/ripple/ripple-keypairs) ![Codecov](https://img.shields.io/codecov/c/github/ripple/ripple-keypairs)
+# xahau-keypairs [![NPM](https://img.shields.io/npm/v/xahau-keypairs.svg)](https://npmjs.org/package/xahau-keypairs) [![Build Status](https://img.shields.io/travis/ripple/xahau-keypairs/master.svg)](https://travis-ci.org/ripple/xahau-keypairs) ![Codecov](https://img.shields.io/codecov/c/github/ripple/xahau-keypairs)
 
 An implementation of XRP Ledger keypairs & wallet generation using
 [elliptic](https://github.com/indutny/elliptic) which supports rfc6979 and
 eddsa deterministic signatures.
 
-[![NPM](https://nodei.co/npm/ripple-keypairs.png)](https://www.npmjs.org/package/ripple-keypairs)
+[![NPM](https://nodei.co/npm/xahau-keypairs.png)](https://www.npmjs.org/package/xahau-keypairs)
 
 ## API Methods
 

packages/xahau-keypairs/SECURITY.md

@@ -23,7 +23,7 @@ To report a bug or potential vulnerability, please send a detailed report to:
 |Long Key ID  | `0xCD49A0AFC57929BE`                                |
 |Fingerprint  | `24E6 3B02 37E0 FA9C 5E96 8974 CD49 A0AF C579 29BE` |
 
-The full PGP key for this address, which is also available on several key servers (e.g. on [keys.gnupg.net](https://keys.gnupg.net)), is: 
+The full PGP key for this address, which is also available on several key servers (e.g. on [keys.gnupg.net](https://keys.gnupg.net)), is:
 ```
 -----BEGIN PGP PUBLIC KEY BLOCK-----
 mQINBFUwGHYBEAC0wpGpBPkd8W1UdQjg9+cEFzeIEJRaoZoeuJD8mofwI5Ejnjdt

webpack.config.js

@@ -24,7 +24,7 @@ function getDefaultConfiguration() {
     resolve: {
       extensions: [".js", ".json"],
       // We don't want to webpack any of the local dependencies:
-      // ripple-address-codec, ripple-binary-codec, ripple-keypairs, which are
+      // xahau-address-codec, xahau-binary-codec, xahau-keypairs, which are
       // symlinked together via lerna
       symlinks: false,
     },
@@ -57,7 +57,7 @@ module.exports = {
             new BundleAnalyzerPlugin({
               analyzerPort: `auto`,
               analyzerMode: "static",
-            }),
+            })
           );
         }
         return localConfig;