diff --git a/doc/JSON-RPC-interface.md b/doc/JSON-RPC-interface.md
index 65dea7c5c..21bd5e765 100644
--- a/doc/JSON-RPC-interface.md
+++ b/doc/JSON-RPC-interface.md
@@ -1,7 +1,7 @@
 # JSON-RPC Interface
 
-The headless daemon `bitcoind` has the JSON-RPC API enabled by default, the GUI
-`bitcoin-qt` has it disabled by default. This can be changed with the `-server`
+The headless daemon `aviand` has the JSON-RPC API enabled by default, the GUI
+`avian-qt` has it disabled by default. This can be changed with the `-server`
 option. In the GUI it is possible to execute RPC methods in the Debug Console
 Dialog.
 
@@ -24,7 +24,7 @@ This endpoint is only activated when the wallet component has been compiled in.
 It can service both wallet and non-wallet requests.
 It MUST be used for wallet requests when two or more wallets are loaded.
 
-This is the endpoint used by bitcoin-cli when a `-rpcwallet=` parameter is passed in.
+This is the endpoint used by avian-cli when a `-rpcwallet=` parameter is passed in.
 
 Best practice would dictate using the `/wallet/<walletname>/` endpoint for ALL
 requests when multiple wallets are in use.
@@ -53,16 +53,16 @@ Examples:
 
 ```sh
 # "params": ["mywallet", false, false, "", false, false, true]
-bitcoin-cli createwallet mywallet false false "" false false true
+avian-cli createwallet mywallet false false "" false false true
 
 # "params": {"wallet_name": "mywallet", "load_on_startup": true}
-bitcoin-cli -named createwallet wallet_name=mywallet load_on_startup=true
+avian-cli -named createwallet wallet_name=mywallet load_on_startup=true
 
 # "params": {"args": ["mywallet"], "load_on_startup": true}
-bitcoin-cli -named createwallet mywallet load_on_startup=true
+avian-cli -named createwallet mywallet load_on_startup=true
 ```
 
-`bitcoin rpc` can also be substituted for `bitcoin-cli -named`, and is a newer alternative.
+`avian rpc` can also be substituted for `avian-cli -named`, and is a newer alternative.
 
 ## Versioning
 
@@ -137,7 +137,7 @@ RPC interface will be abused.
   withstand arbitrary Internet traffic, so changing the above settings
   to expose it to the Internet (even using something like a Tor onion
   service) could expose you to unconsidered vulnerabilities.  See
-  `bitcoind -help` for more information about these settings and other
+  `aviand -help` for more information about these settings and other
   settings described in this document.
 
     Related, if you use Bitcoin Core inside a Docker container, you may
diff --git a/doc/README.md b/doc/README.md
index 0959c6c7f..39e58b05f 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -1,11 +1,11 @@
-Bitcoin Core
+Avian Core
 =============
 
 Setup
 ---------------------
-Bitcoin Core is the original Bitcoin client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Bitcoin transactions, which requires several hundred gigabytes or more of disk space. Depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to several days or more.
+Avian Core is the Avian Network client and it builds the backbone of the network. It downloads and, by default, stores the entire history of Avian transactions, which requires several hundred gigabytes or more of disk space. Depending on the speed of your computer and network connection, the synchronization process can take anywhere from a few hours to several days or more.
 
-To download Bitcoin Core, visit [bitcoincore.org](https://bitcoincore.org/en/download/).
+To download Avian Core, visit [github.com/AvianNetwork/Avian](https://github.com/AvianNetwork/Avian/releases).
 
 Running
 ---------------------
@@ -15,31 +15,28 @@ The following are some helpful notes on how to run Bitcoin Core on your native p
 
 Unpack the files into a directory and run:
 
-- `bin/bitcoin-qt` (GUI) or
-- `bin/bitcoind` (headless)
-- `bin/bitcoin` (wrapper command)
+- `bin/avian-qt` (GUI) or
+- `bin/aviand` (headless)
+- `bin/avian` (wrapper command)
 
-The `bitcoin` command supports subcommands like `bitcoin gui`, `bitcoin node`, and `bitcoin rpc` exposing different functionality. Subcommands can be listed with `bitcoin help`.
+The `avian` command supports subcommands like `avian gui`, `avian node`, and `avian rpc` exposing different functionality. Subcommands can be listed with `avian help`.
 
 ### Windows
 
-Unpack the files into a directory, and then run bitcoin-qt.exe.
+Unpack the files into a directory, and then run avian-qt.exe.
 
 ### macOS
 
-Drag Bitcoin Core to your applications folder, and then run Bitcoin Core.
+Drag Avian Core to your applications folder, and then run Avian Core.
 
 ### Need Help?
 
-* See the documentation at the [Bitcoin Wiki](https://en.bitcoin.it/wiki/Main_Page)
-for help and more information.
-* Ask for help on [Bitcoin StackExchange](https://bitcoin.stackexchange.com).
-* Ask for help on #bitcoin on Libera Chat. If you don't have an IRC client, you can use [web.libera.chat](https://web.libera.chat/#bitcoin).
-* Ask for help on the [BitcoinTalk](https://bitcointalk.org/) forums, in the [Technical Support board](https://bitcointalk.org/index.php?board=4.0).
+* See the documentation on [GitHub](https://github.com/AvianNetwork/Avian) for help and more information.
+* Ask for help on the [Avian Network Discord](https://discord.gg/aviannetwork).
 
 Building
 ---------------------
-The following are developer notes on how to build Bitcoin Core on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
+The following are developer notes on how to build Avian Core on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
 
 - [Dependencies](dependencies.md)
 - [macOS Build Notes](build-osx.md)
@@ -51,12 +48,12 @@ The following are developer notes on how to build Bitcoin Core on your native pl
 
 Development
 ---------------------
-The Bitcoin repo's [root README](/README.md) contains relevant information on the development process and automated testing.
+The Avian repo's [root README](/README.md) contains relevant information on the development process and automated testing.
 
 - [Developer Notes](developer-notes.md)
 - [Productivity Notes](productivity.md)
 - [Release Process](release-process.md)
-- [Source Code Documentation (External Link)](https://doxygen.bitcoincore.org/)
+- [Source Code Documentation (External Link)](https://doxygen.bitcoincore.org/) (upstream Bitcoin Core)
 - [Translation Process](translation_process.md)
 - [Translation Strings Policy](translation_strings_policy.md)
 - [JSON-RPC Interface](JSON-RPC-interface.md)
@@ -67,12 +64,12 @@ The Bitcoin repo's [root README](/README.md) contains relevant information on th
 - [Internal Design Docs](design/)
 
 ### Resources
-* Discuss on the [BitcoinTalk](https://bitcointalk.org/) forums, in the [Development & Technical Discussion board](https://bitcointalk.org/index.php?board=6.0).
-* Discuss project-specific development on #bitcoin-core-dev on Libera Chat. If you don't have an IRC client, you can use [web.libera.chat](https://web.libera.chat/#bitcoin-core-dev).
+* Discuss on the [Avian Network Discord](https://discord.gg/aviannetwork).
+* Open issues on [GitHub](https://github.com/AvianNetwork/Avian/issues).
 
 ### Miscellaneous
 - [Assets Attribution](assets-attribution.md)
-- [bitcoin.conf Configuration File](bitcoin-conf.md)
+- [avian.conf Configuration File](bitcoin-conf.md)
 - [CJDNS Support](cjdns.md)
 - [Files](files.md)
 - [Fuzz-testing](fuzzing.md)
diff --git a/doc/REST-interface.md b/doc/REST-interface.md
index f10b8e990..f7d23b4ae 100644
--- a/doc/REST-interface.md
+++ b/doc/REST-interface.md
@@ -153,4 +153,4 @@ Refer to the `getrawmempool` RPC help for details. Defaults to setting
 
 Risks
 -------------
-Running a web browser on the same node with a REST enabled bitcoind can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like `<script src="http://127.0.0.1:7896/rest/tx/1234567890.json">` which might break the nodes privacy.
+Running a web browser on the same node with a REST enabled aviand can be a risk. Accessing prepared XSS websites could read out tx/block data of your node by placing links like `<script src="http://127.0.0.1:7896/rest/tx/1234567890.json">` which might break the nodes privacy.
diff --git a/doc/assumeutxo.md b/doc/assumeutxo.md
index 17858de54..44936513d 100644
--- a/doc/assumeutxo.md
+++ b/doc/assumeutxo.md
@@ -1,6 +1,6 @@
 # Assumeutxo Usage
 
-Assumeutxo is a feature that allows fast bootstrapping of a validating bitcoind
+Assumeutxo is a feature that allows fast bootstrapping of a validating aviand
 instance.
 
 For notes on the design of Assumeutxo, please refer to [the design doc](/doc/design/assumeutxo.md).
@@ -17,7 +17,7 @@ Once you've obtained the snapshot, you can use the RPC command `loadtxoutset` to
 load it.
 
 ```
-$ bitcoin-cli -rpcclienttimeout=0 loadtxoutset /path/to/input
+$ avian-cli -rpcclienttimeout=0 loadtxoutset /path/to/input
 ```
 
 After the snapshot has loaded, the syncing process of both the snapshot chain
@@ -69,7 +69,7 @@ comparing the hash.
 Example usage:
 
 ```
-$ bitcoin-cli -rpcclienttimeout=0 dumptxoutset /path/to/output rollback
+$ avian-cli -rpcclienttimeout=0 dumptxoutset /path/to/output rollback
 ```
 
 For most of the duration of `dumptxoutset` running the node is in a temporary
diff --git a/doc/bitcoin-conf.md b/doc/bitcoin-conf.md
index c5dca7e24..6b0d733a3 100644
--- a/doc/bitcoin-conf.md
+++ b/doc/bitcoin-conf.md
@@ -1,10 +1,10 @@
-# `bitcoin.conf` Configuration File
+# `avian.conf` Configuration File
 
-The configuration file is used by `bitcoind`, `bitcoin-qt` and `bitcoin-cli`.
+The configuration file is used by `aviand`, `avian-qt` and `avian-cli`.
 
 All command-line options (except for `-?`, `-help`, `-version` and `-conf`) may be specified in a configuration file, and all configuration file options (except for `includeconf`) may also be specified on the command line. Command-line options override values set in the configuration file and configuration file options override values set in the GUI.
 
-Changes to the configuration file while `bitcoind` or `bitcoin-qt` is running only take effect after restarting.
+Changes to the configuration file while `aviand` or `avian-qt` is running only take effect after restarting.
 
 Users should never make any configuration changes which they do not understand. Furthermore, users should always be wary of accepting any configuration changes provided to them by another source (even if they believe that they do understand them).
 
@@ -12,11 +12,11 @@ Users should never make any configuration changes which they do not understand.
 
 Options specified in the configuration file can be overridden by options in the [`settings.json` file](files.md) and by options specified on the command line.
 
-The `settings.json` file contains dynamic settings that are set by the Bitcoin Core GUI and RPCs at runtime, and augment or replace the static settings specified in the `bitcoin.conf` file.
+The `settings.json` file contains dynamic settings that are set by the Avian Core GUI and RPCs at runtime, and augment or replace the static settings specified in the `avian.conf` file.
 
-Command line options also augment or replace `bitcoin.conf` options, and can be useful for scripting and debugging.
+Command line options also augment or replace `avian.conf` options, and can be useful for scripting and debugging.
 
-It is possible to see which setting values are in use by checking `debug.log` output. Any unrecognized options that are found in `bitcoin.conf` also show up as warnings in `debug.log` output.
+It is possible to see which setting values are in use by checking `debug.log` output. Any unrecognized options that are found in `avian.conf` also show up as warnings in `debug.log` output.
 
 ## Configuration File Format
 
@@ -69,24 +69,24 @@ However, there are exceptions to this general rule. For example, it is an error
 
 ## Configuration File Path
 
-The configuration file is not automatically created; you can create it using your favorite text editor. By default, the configuration file name is `bitcoin.conf` and it is located in the Bitcoin data directory, but both the Bitcoin data directory and the configuration file path may be changed using the `-datadir` and `-conf` command-line options.
+The configuration file is not automatically created; you can create it using your favorite text editor. By default, the configuration file name is `avian.conf` and it is located in the Avian data directory, but both the Avian data directory and the configuration file path may be changed using the `-datadir` and `-conf` command-line options.
 
-The `includeconf=<file>` option in the `bitcoin.conf` file can be used to include additional configuration files.
+The `includeconf=<file>` option in the `avian.conf` file can be used to include additional configuration files.
 
 ### Default configuration file locations
 
 Operating System | Data Directory | Example Path
 -- | -- | --
-Windows | `%LOCALAPPDATA%\Bitcoin\` | `C:\Users\username\AppData\Local\Bitcoin\bitcoin.conf`
-Linux | `$HOME/.bitcoin/` | `/home/username/.bitcoin/bitcoin.conf`
-macOS | `$HOME/Library/Application Support/Bitcoin/` | `/Users/username/Library/Application Support/Bitcoin/bitcoin.conf`
+Windows | `%LOCALAPPDATA%\AvianV5\` | `C:\Users\username\AppData\Local\AvianV5\avian.conf`
+Linux | `$HOME/.avianv5/` | `/home/username/.avianv5/avian.conf`
+macOS | `$HOME/Library/Application Support/AvianV5/` | `/Users/username/Library/Application Support/AvianV5/avian.conf`
 
 An example configuration file can be generated by [contrib/devtools/gen-avian-conf.sh](../contrib/devtools/gen-avian-conf.sh).
 Run this script after compiling to generate an up-to-date configuration file.
-The output is placed under `share/examples/bitcoin.conf`.
+The output is placed under `share/examples/avian.conf`.
 To use the generated configuration file, copy the example file into your data directory and edit it there, like so:
 
 ```
 # example copy command for linux user
-cp share/examples/bitcoin.conf ~/.bitcoin
+cp share/examples/avian.conf ~/.avianv5
 ```
diff --git a/doc/build-freebsd.md b/doc/build-freebsd.md
index b5940c0f7..b4cd0d440 100644
--- a/doc/build-freebsd.md
+++ b/doc/build-freebsd.md
@@ -2,7 +2,7 @@
 
 **Updated for FreeBSD [14.3](https://www.freebsd.org/releases/14.3R/announce/)**
 
-This guide describes how to build bitcoind, command-line utilities, and GUI on FreeBSD.
+This guide describes how to build aviand, command-line utilities, and GUI on FreeBSD.
 
 ## Preparation
 
diff --git a/doc/build-netbsd.md b/doc/build-netbsd.md
index 103e62568..535010ebd 100644
--- a/doc/build-netbsd.md
+++ b/doc/build-netbsd.md
@@ -2,7 +2,7 @@
 
 **Updated for NetBSD [10.1](https://netbsd.org/releases/formal-10/NetBSD-10.1.html)**
 
-This guide describes how to build bitcoind, command-line utilities, and GUI on NetBSD.
+This guide describes how to build aviand, command-line utilities, and GUI on NetBSD.
 
 ## Preparation
 
diff --git a/doc/build-openbsd.md b/doc/build-openbsd.md
index 4ea58795a..f4021e8b1 100644
--- a/doc/build-openbsd.md
+++ b/doc/build-openbsd.md
@@ -2,7 +2,7 @@
 
 **Updated for OpenBSD [7.8](https://www.openbsd.org/78.html)**
 
-This guide describes how to build bitcoind, command-line utilities, and GUI on OpenBSD.
+This guide describes how to build aviand, command-line utilities, and GUI on OpenBSD.
 
 ## Preparation
 
diff --git a/doc/build-osx.md b/doc/build-osx.md
index 001c0188e..968a696e7 100644
--- a/doc/build-osx.md
+++ b/doc/build-osx.md
@@ -2,7 +2,7 @@
 
 **Updated for MacOS [15](https://www.apple.com/macos/macos-sequoia/)**
 
-This guide describes how to build bitcoind, command-line utilities, and GUI on macOS.
+This guide describes how to build aviand, command-line utilities, and GUI on macOS.
 
 ## Preparation
 
@@ -181,45 +181,45 @@ You can also create a  `.zip` containing the `.app` bundle by running the follow
 cmake --build build --target deploy
 ```
 
-## Running Bitcoin Core
+## Running Avian Core
 
-Bitcoin Core should now be available at `./build/bin/bitcoind`.
-If you compiled support for the GUI, it should be available at `./build/bin/bitcoin-qt`.
+Avian Core should now be available at `./build/bin/aviand`.
+If you compiled support for the GUI, it should be available at `./build/bin/avian-qt`.
 
-There is also a multifunction command line interface at `./build/bin/bitcoin`
-supporting subcommands like `bitcoin node`, `bitcoin gui`, `bitcoin rpc`, and
-others that can be listed with `bitcoin help`.
+There is also a multifunction command line interface at `./build/bin/avian`
+supporting subcommands like `avian node`, `avian gui`, `avian rpc`, and
+others that can be listed with `avian help`.
 
-The first time you run `bitcoind` or `bitcoin-qt`, it will start downloading the blockchain.
+The first time you run `aviand` or `avian-qt`, it will start downloading the blockchain.
 This process could take many hours, or even days on slower than average systems.
 
 By default, blockchain and wallet data files will be stored in:
 
 ``` bash
-/Users/${USER}/Library/Application Support/Bitcoin/
+/Users/${USER}/Library/Application Support/AvianV5/
 ```
 
 Before running, you may create an empty configuration file:
 
 ```shell
-mkdir -p "/Users/${USER}/Library/Application Support/Bitcoin"
+mkdir -p "/Users/${USER}/Library/Application Support/AvianV5"
 
-touch "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
+touch "/Users/${USER}/Library/Application Support/AvianV5/avian.conf"
 
-chmod 600 "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
+chmod 600 "/Users/${USER}/Library/Application Support/AvianV5/avian.conf"
 ```
 
 You can monitor the download process by looking at the debug.log file:
 
 ```shell
-tail -f $HOME/Library/Application\ Support/Bitcoin/debug.log
+tail -f $HOME/Library/Application\ Support/AvianV5/debug.log
 ```
 
 ## Other commands:
 
 ```shell
-./build/bin/bitcoind -daemon      # Starts the bitcoin daemon.
-./build/bin/bitcoin-cli --help    # Outputs a list of command-line options.
-./build/bin/bitcoin-cli help      # Outputs a list of RPC commands when the daemon is running.
-./build/bin/bitcoin-qt -server # Starts the bitcoin-qt server mode, allows bitcoin-cli control
+./build/bin/aviand -daemon      # Starts the Avian daemon.
+./build/bin/avian-cli --help    # Outputs a list of command-line options.
+./build/bin/avian-cli help      # Outputs a list of RPC commands when the daemon is running.
+./build/bin/avian-qt -server    # Starts the avian-qt server mode, allows avian-cli control
 ```
diff --git a/doc/build-unix.md b/doc/build-unix.md
index 04ec788f2..612d22c4b 100644
--- a/doc/build-unix.md
+++ b/doc/build-unix.md
@@ -218,11 +218,11 @@ Setup and Build Example: Arch Linux
 This example lists the steps necessary to setup and build a command line only distribution of the latest changes on Arch Linux:
 
     pacman --sync --needed capnproto cmake boost gcc git libevent make python sqlite
-    git clone https://github.com/bitcoin/bitcoin.git
-    cd bitcoin/
+    git clone https://github.com/AvianNetwork/Avian.git
+    cd Avian/
     cmake -B build
     cmake --build build
     ctest --test-dir build
-    ./build/bin/bitcoind
-    ./build/bin/bitcoin help
+    ./build/bin/aviand
+    ./build/bin/avian help
 
diff --git a/doc/build-windows-msvc.md b/doc/build-windows-msvc.md
index 712ff8bb5..4b47148da 100644
--- a/doc/build-windows-msvc.md
+++ b/doc/build-windows-msvc.md
@@ -1,6 +1,6 @@
 # Windows / MSVC Build Guide
 
-This guide describes how to build bitcoind, command-line utilities, and GUI on Windows using Microsoft Visual Studio.
+This guide describes how to build aviand, command-line utilities, and GUI on Windows using Microsoft Visual Studio.
 
 For cross-compiling options, please see [`build-windows.md`](./build-windows.md).
 
diff --git a/doc/cjdns.md b/doc/cjdns.md
index 35fe87adf..50158edb3 100644
--- a/doc/cjdns.md
+++ b/doc/cjdns.md
@@ -94,7 +94,7 @@ connections are not affected by this option. It can be specified multiple times
 to allow multiple networks, e.g. onlynet=cjdns, onlynet=i2p, onlynet=onion.
 
 CJDNS support was added to Bitcoin Core in version 23.0 and there may be fewer
-CJDNS peers than Tor or IP ones. You can use `bitcoin-cli -addrinfo` to see the
+CJDNS peers than Tor or IP ones. You can use `avian-cli -addrinfo` to see the
 number of CJDNS addresses known to your node.
 
 In general, a node can be run with both an onion service and CJDNS (or any/all
@@ -109,9 +109,9 @@ There are several ways to see your CJDNS address in Bitcoin Core:
 - in the "Local addresses" output of CLI `-netinfo`
 - in the "localaddresses" output of RPC `getnetworkinfo`
 
-To see which CJDNS peers your node is connected to, use `bitcoin-cli -netinfo 4`
-or the `getpeerinfo` RPC (i.e. `bitcoin-cli getpeerinfo`).
+To see which CJDNS peers your node is connected to, use `avian-cli -netinfo 4`
+or the `getpeerinfo` RPC (i.e. `avian-cli getpeerinfo`).
 
-You can use the `getnodeaddresses` RPC to fetch a number of CJDNS peers known to your node; run `bitcoin-cli help getnodeaddresses` for details.
+You can use the `getnodeaddresses` RPC to fetch a number of CJDNS peers known to your node; run `avian-cli help getnodeaddresses` for details.
 
-`bitcoin rpc` can also be substituted for `bitcoin-cli`.
+`avian rpc` can also be substituted for `avian-cli`.
diff --git a/doc/external-signer.md b/doc/external-signer.md
index c1b6b20ce..adaf64712 100644
--- a/doc/external-signer.md
+++ b/doc/external-signer.md
@@ -11,10 +11,10 @@ When using a hardware wallet, consult the manufacturer website for (alternative)
 Start Bitcoin Core:
 
 ```sh
-$ bitcoind -signer=../HWI/hwi.py
+$ aviand -signer=../HWI/hwi.py
 ```
 
-`bitcoin node` can also be substituted for `bitcoind`.
+`avian node` can also be substituted for `aviand`.
 
 ### Device setup
 
@@ -25,7 +25,7 @@ Follow the hardware manufacturers instructions for the initial device setup, as
 Get a list of signing devices / services:
 
 ```
-$ bitcoin-cli enumeratesigners
+$ avian-cli enumeratesigners
 {
   "signers": [
     {
@@ -39,18 +39,18 @@ The master key fingerprint is used to identify a device.
 Create a wallet, this automatically imports the public keys:
 
 ```sh
-$ bitcoin-cli createwallet "hww" true true "" true true true
+$ avian-cli createwallet "hww" true true "" true true true
 ```
 
-`bitcoin rpc` can also be substituted for `bitcoin-cli`.
+`avian rpc` can also be substituted for `avian-cli`.
 
 ### Verify an address
 
 Display an address on the device:
 
 ```sh
-$ bitcoin-cli -rpcwallet=<wallet> getnewaddress
-$ bitcoin-cli -rpcwallet=<wallet> walletdisplayaddress <address>
+$ avian-cli -rpcwallet=<wallet> getnewaddress
+$ avian-cli -rpcwallet=<wallet> walletdisplayaddress <address>
 ```
 
 Replace `<address>` with the result of `getnewaddress`.
@@ -60,7 +60,7 @@ Replace `<address>` with the result of `getnewaddress`.
 Under the hood this uses a [Partially Signed Bitcoin Transaction](psbt.md).
 
 ```sh
-$ bitcoin-cli -rpcwallet=<wallet> sendtoaddress <address> <amount>
+$ avian-cli -rpcwallet=<wallet> sendtoaddress <address> <amount>
 ```
 
 This prompts your hardware wallet to sign, and fail if it's not connected. If successful
diff --git a/doc/files.md b/doc/files.md
index e17b6d5f1..af9a45823 100644
--- a/doc/files.md
+++ b/doc/files.md
@@ -22,19 +22,19 @@
 
 ## Data directory location
 
-The data directory is the default location where the Bitcoin Core files are stored.
+The data directory is the default location where the Avian Core files are stored.
 
 1. The default data directory paths for supported platforms are:
 
 Platform | Data directory path
 ---------|--------------------
-Linux    | `$HOME/.bitcoin/`
-macOS    | `$HOME/Library/Application Support/Bitcoin/`
-Windows  | `%LOCALAPPDATA%\Bitcoin\` <sup>[\[1\]](#note1)</sup>
+Linux    | `$HOME/.avianv5/`
+macOS    | `$HOME/Library/Application Support/AvianV5/`
+Windows  | `%LOCALAPPDATA%\AvianV5\` <sup>[\[1\]](#note1)</sup>
 
 2. A custom data directory path can be specified with the `-datadir` option.
 
-3. All content of the data directory, except for `bitcoin.conf` file, is chain-specific. This means the actual data directory paths for non-mainnet cases differ:
+3. All content of the data directory, except for `avian.conf` file, is chain-specific. This means the actual data directory paths for non-mainnet cases differ:
 
 Chain option                     | Data directory path
 ---------------------------------|------------------------------
@@ -61,9 +61,9 @@ Subdirectory       | File(s)               | Description
 `wallets/`         |                       | [Contains wallets](#multi-wallet-environment); can be specified by `-walletdir` option; if `wallets/` subdirectory does not exist, wallets reside in the [data directory](#data-directory-location)
 `./`               | `anchors.dat`         | Anchor IP address database, created on shutdown and deleted at startup. Anchors are last known outgoing block-relay-only peers that are tried to re-connect to on startup
 `./`               | `banlist.json`        | Stores the addresses/subnets of banned nodes.
-`./`               | `bitcoin.conf`        | User-defined [configuration settings](bitcoin-conf.md) for `bitcoind` or `bitcoin-qt`. File is not written to by the software and must be created manually. Path can be specified by `-conf` option
-`./`               | `bitcoind.pid`        | Stores the process ID (PID) of `bitcoind` or `bitcoin-qt` while running; created at start and deleted on shutdown; can be specified by `-pid` option
-`./`               | `debug.log`           | Contains debug information and general logging generated by `bitcoind` or `bitcoin-qt`; can be specified by `-debuglogfile` option
+`./`               | `avian.conf`          | User-defined [configuration settings](bitcoin-conf.md) for `aviand` or `avian-qt`. File is not written to by the software and must be created manually. Path can be specified by `-conf` option
+`./`               | `aviand.pid`          | Stores the process ID (PID) of `aviand` or `avian-qt` while running; created at start and deleted on shutdown; can be specified by `-pid` option
+`./`               | `debug.log`           | Contains debug information and general logging generated by `aviand` or `avian-qt`; can be specified by `-debuglogfile` option
 `./`               | `fee_estimates.dat`   | Stores statistics used to estimate minimum transaction fees required for confirmation
 `./`               | `guisettings.ini.bak` | Backup of former [GUI settings](#gui-settings) after `-resetguisettings` option is used
 `./`               | `ip_asn.map`          | IP addresses to Autonomous System Numbers (ASNs) mapping used for bucketing of the peers; path can be specified with the `-asmap` option
@@ -71,7 +71,7 @@ Subdirectory       | File(s)               | Description
 `./`               | `onion_v3_private_key` | Cached Tor onion service private key for `-listenonion` option
 `./`               | `i2p_private_key`     | Private key that corresponds to our I2P address. When `-i2psam=` is specified the contents of this file is used to identify ourselves for making outgoing connections to I2P peers and possibly accepting incoming ones. Automatically generated if it does not exist.
 `./`               | `peers.dat`           | Peer IP address database (custom format)
-`./`               | `settings.json`       | Read-write settings set through GUI or RPC interfaces, augmenting manual settings from [bitcoin.conf](bitcoin-conf.md). File is created automatically if read-write settings storage is not disabled with `-nosettings` option. Path can be specified with `-settings` option
+`./`               | `settings.json`       | Read-write settings set through GUI or RPC interfaces, augmenting manual settings from [avian.conf](bitcoin-conf.md). File is created automatically if read-write settings storage is not disabled with `-nosettings` option. Path can be specified with `-settings` option
 `./`               | `.cookie`             | Session RPC authentication cookie; if used, created at start and deleted on shutdown; can be specified by `-rpccookiefile` option
 `./`               | `.lock`               | Data directory lock file
 
@@ -100,7 +100,7 @@ Subdirectory | File                 | Description
 
 ## GUI settings
 
-`bitcoin-qt` uses [`QSettings`](https://doc.qt.io/qt-6/qsettings.html) class; this implies platform-specific [locations where application settings are stored](https://doc.qt.io/qt-6/qsettings.html#locations-where-application-settings-are-stored).
+`avian-qt` uses [`QSettings`](https://doc.qt.io/qt-6/qsettings.html) class; this implies platform-specific [locations where application settings are stored](https://doc.qt.io/qt-6/qsettings.html#locations-where-application-settings-are-stored).
 
 ## Legacy subdirectories and files
 
@@ -133,37 +133,36 @@ Subdirectory | File(s)           | Description
 
 ## Installed Files
 
-This table describes the files installed by Bitcoin Core across different platforms.
+This table describes the files installed by Avian Core across different platforms.
 
 | **Path**                                                   | **Description**                                                             |
 |------------------------------------------------------------|-----------------------------------------------------------------------------|
 | [README.md](README.md) or [readme.txt](README_windows.txt) | Project information and instructions                                        |
-| bitcoin.conf                                               | [Generated](../contrib/devtools/gen-avian-conf.sh) configuration file     |
-| bin/bitcoin                                                | Command-line tool for interacting with Bitcoin. Calls other binaries below. |
-| bin/bitcoin-cli                                            | Tool for making node and wallet RPC calls.                                  |
-| bin/bitcoin-qt                                             | Bitcoin node and wallet GUI                                                 |
-| bin/bitcoin-tx                                             | Tool for creating and modifying transactions                                |
-| bin/bitcoin-util                                           | Miscellaneous utilities                                                     |
-| bin/bitcoin-wallet                                         | Bitcoin wallet tool                                                         |
-| bin/bitcoind                                               | Bitcoin node and wallet daemon                                              |
+| avian.conf                                                 | [Generated](../contrib/devtools/gen-avian-conf.sh) configuration file       |
+| bin/avian                                                  | Command-line tool for interacting with Avian. Calls other binaries below.   |
+| bin/avian-cli                                              | Tool for making node and wallet RPC calls.                                  |
+| bin/avian-util                                             | Miscellaneous utilities                                                     |
+| bin/avian-wallet                                           | Avian wallet tool                                                           |
+| bin/aviand                                                 | Avian node and wallet daemon                                                |
 | *lib/libbitcoinkernel.so*                                  | Shared library containing core consensus and validation code                |
 | *lib/pkgconfig/libbitcoinkernel.pc*                        | Pkg-config metadata for linking to `libbitcoinkernel`                       |
-| *libexec/bench_bitcoin*                                    | Benchmarking tool for measuring node performance                            |
-| *libexec/bitcoin-chainstate*                               | Tool to validate and connect blocks                                         |
-| libexec/bitcoin-gui                                        | IPC-enabled alternative to `bitcoin-qt`                                     |
-| libexec/bitcoin-node                                       | IPC-enabled alternative to `bitcoind`                                       |
-| libexec/test_bitcoin                                       | Unit test binary                                                            |
-| *libexec/test_bitcoin-qt*                                  | GUI-specific unit tests                                                     |
-| share/man/man1/                                            | Man pages for command-line tools like `bitcoin-cli`, `bitcoind`, and others |
+| *libexec/bench_avian*                                      | Benchmarking tool for measuring node performance                            |
+| *libexec/avian-chainstate*                                 | Tool to validate and connect blocks                                         |
+| libexec/avian-gui                                          | IPC-enabled alternative to `avian-qt`                                       |
+| libexec/avian-node                                         | IPC-enabled alternative to `aviand`                                         |
+| libexec/test_avian                                         | Unit test binary                                                            |
+| *libexec/test_avian-qt*                                    | GUI-specific unit tests                                                     |
+| share/man/man1/                                            | Man pages for command-line tools like `avian-cli`, `aviand`, and others     |
 | share/rpcauth/                                             | Documentation and scripts for RPC authentication setup                      |
 
 ### Notes
 
 - *Italicized* files are only installed in source builds if relevant CMake options are enabled. They are not included in binary releases.
-- README and bitcoin.conf files are included in binary releases but not installed in source builds.
-- On Windows, binaries have a `.exe` suffix (e.g., `bitcoin-cli.exe`).
+- README and avian.conf files are included in binary releases but not installed in source builds.
+- On Windows, binaries have a `.exe` suffix (e.g., `avian-cli.exe`).
 
 ## Filesystem recommendations
 
 When choosing a filesystem for the data directory (`datadir`) or blocks directory (`blocksdir`) on **macOS**,the `exFAT` filesystem should be avoided.
 There have been multiple reports of database corruption and data loss when using this filesystem with Bitcoin Core, see [Issue #31454](https://github.com/bitcoin/bitcoin/issues/31454) for more details.
+
diff --git a/doc/i2p.md b/doc/i2p.md
index b769a74df..947065b0d 100644
--- a/doc/i2p.md
+++ b/doc/i2p.md
@@ -41,7 +41,7 @@ Core configuration options:
 In a typical situation, this suffices:
 
 ```
-bitcoind -i2psam=127.0.0.1:7656
+aviand -i2psam=127.0.0.1:7656
 ```
 
 ## Additional configuration options related to I2P
@@ -51,7 +51,7 @@ bitcoind -i2psam=127.0.0.1:7656
 ```
 
 Set the `debug=i2p` config logging option to see additional information in the
-debug log about your I2P configuration and connections. Run `bitcoin-cli help
+debug log about your I2P configuration and connections. Run `avian-cli help
 logging` for more information.
 
 ```
@@ -66,7 +66,7 @@ I2P support was added to Bitcoin Core in version 22.0 and there may be fewer I2P
 peers than Tor or IP ones. Therefore, using I2P alone without other networks may
 make a node more susceptible to [Sybil
 attacks](https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack). You can use
-`bitcoin-cli -addrinfo` to see the number of I2P addresses known to your node.
+`avian-cli -addrinfo` to see the number of I2P addresses known to your node.
 
 Another consideration with `onlynet=i2p` is that the initial blocks download
 phase when syncing up a new node can be very slow. This phase can be sped up by
@@ -106,10 +106,10 @@ incoming I2P connections (`-i2pacceptincoming`):
 - in the "localaddresses" output of RPC `getnetworkinfo`
 - in the debug log (grep for `AddLocal`; the I2P address ends in `.b32.i2p`)
 
-To see which I2P peers your node is connected to, use `bitcoin-cli -netinfo 4`
-or the `getpeerinfo` RPC (e.g. `bitcoin-cli getpeerinfo`).
+To see which I2P peers your node is connected to, use `avian-cli -netinfo 4`
+or the `getpeerinfo` RPC (e.g. `avian-cli getpeerinfo`).
 
-You can use the `getnodeaddresses` RPC to fetch a number of I2P peers known to your node; run `bitcoin-cli help getnodeaddresses` for details.
+You can use the `getnodeaddresses` RPC to fetch a number of I2P peers known to your node; run `avian-cli help getnodeaddresses` for details.
 
 ## Compatibility
 
diff --git a/doc/init.md b/doc/init.md
index 09aedf188..4aee26f50 100644
--- a/doc/init.md
+++ b/doc/init.md
@@ -1,36 +1,36 @@
-Sample init scripts and service configuration for bitcoind
+Sample init scripts and service configuration for aviand
 ==========================================================
 
 Sample scripts and configuration files for systemd, Upstart and OpenRC
 can be found in the contrib/init folder.
 
-    contrib/init/bitcoind.service:    systemd service unit configuration
-    contrib/init/bitcoind.openrc:     OpenRC compatible SysV style init script
-    contrib/init/bitcoind.openrcconf: OpenRC conf.d file
-    contrib/init/bitcoind.conf:       Upstart service configuration file
-    contrib/init/bitcoind.init:       CentOS compatible SysV style init script
+    contrib/init/aviand.service:    systemd service unit configuration
+    contrib/init/aviand.openrc:     OpenRC compatible SysV style init script
+    contrib/init/aviand.openrcconf: OpenRC conf.d file
+    contrib/init/aviand.conf:       Upstart service configuration file
+    contrib/init/aviand.init:       CentOS compatible SysV style init script
 
 Service User
 ---------------------------------
 
-All three Linux startup configurations assume the existence of a "bitcoin" user
+All three Linux startup configurations assume the existence of an "avian" user
 and group.  They must be created before attempting to use these scripts.
-The macOS configuration assumes bitcoind will be set up for the current user.
+The macOS configuration assumes aviand will be set up for the current user.
 
 Configuration
 ---------------------------------
 
-Running bitcoind as a daemon does not require any manual configuration. You may
-set the `rpcauth` setting in the `bitcoin.conf` configuration file to override
+Running aviand as a daemon does not require any manual configuration. You may
+set the `rpcauth` setting in the `avian.conf` configuration file to override
 the default behaviour of using a special cookie for authentication.
 
 This password does not have to be remembered or typed as it is mostly used
-as a fixed token that bitcoind and client programs read from the configuration
+as a fixed token that aviand and client programs read from the configuration
 file, however it is recommended that a strong and secure password be used
 as this password is security critical to securing the wallet should the
 wallet be enabled.
 
-If bitcoind is run with the "-server" flag (set by default), and no rpcpassword is set,
+If aviand is run with the "-server" flag (set by default), and no rpcpassword is set,
 it will use a special cookie file for authentication. The cookie is generated with random
 content when the daemon starts, and deleted when it exits. Read access to this file
 controls who can access it through RPC.
@@ -40,7 +40,7 @@ overridden with the option `-rpccookiefile`. Default file permissions for the
 cookie are "owner" (i.e. user read/writeable) via default application-wide file
 umask of `0077`, but these can be overridden with the `-rpccookieperms` option.
 
-This allows for running bitcoind without having to do any manual configuration.
+This allows for running aviand without having to do any manual configuration.
 
 `conf`, `pid`, and `wallet` accept relative paths which are interpreted as
 relative to the data directory. `wallet` *only* supports relative paths.
@@ -55,17 +55,17 @@ Paths
 
 All three configurations assume several paths that might need to be adjusted.
 
-    Binary:              /usr/bin/bitcoind
-    Configuration file:  /etc/bitcoin/bitcoin.conf
-    Data directory:      /var/lib/bitcoind
-    PID file:            /var/run/bitcoind/bitcoind.pid (OpenRC and Upstart) or
-                         /run/bitcoind/bitcoind.pid (systemd)
-    Lock file:           /var/lock/subsys/bitcoind (CentOS)
+    Binary:              /usr/bin/aviand
+    Configuration file:  /etc/avian/avian.conf
+    Data directory:      /var/lib/aviand
+    PID file:            /var/run/aviand/aviand.pid (OpenRC and Upstart) or
+                         /run/aviand/aviand.pid (systemd)
+    Lock file:           /var/lock/subsys/aviand (CentOS)
 
 The PID directory (if applicable) and data directory should both be owned by the
-bitcoin user and group. It is advised for security reasons to make the
-configuration file and data directory only readable by the bitcoin user and
-group. Access to bitcoin-cli and other bitcoind rpc clients can then be
+avian user and group. It is advised for security reasons to make the
+configuration file and data directory only readable by the avian user and
+group. Access to avian-cli and other aviand rpc clients can then be
 controlled by group membership.
 
 NOTE: When using the systemd .service file, the creation of the aforementioned
@@ -76,20 +76,20 @@ bitcoin group to do so. This does not allow
 for the listing of files under the directory.
 
 NOTE: It is not currently possible to override `datadir` in
-`/etc/bitcoin/bitcoin.conf` with the current systemd, OpenRC, and Upstart init
+`/etc/avian/avian.conf` with the current systemd, OpenRC, and Upstart init
 files out-of-the-box. This is because the command line options specified in the
 init files take precedence over the configurations in
-`/etc/bitcoin/bitcoin.conf`. However, some init systems have their own
+`/etc/avian/avian.conf`. However, some init systems have their own
 configuration mechanisms that would allow for overriding the command line
-options specified in the init files (e.g. setting `BITCOIND_DATADIR` for
+options specified in the init files (e.g. setting `AVIAND_DATADIR` for
 OpenRC).
 
 ### macOS
 
-    Binary:              /usr/local/bin/bitcoind
-    Configuration file:  ~/Library/Application Support/Bitcoin/bitcoin.conf
-    Data directory:      ~/Library/Application Support/Bitcoin
-    Lock file:           ~/Library/Application Support/Bitcoin/.lock
+    Binary:              /usr/local/bin/aviand
+    Configuration file:  ~/Library/Application Support/AvianV5/avian.conf
+    Data directory:      ~/Library/Application Support/AvianV5
+    Lock file:           ~/Library/Application Support/AvianV5/.lock
 
 Installing Service Configuration
 -----------------------------------
@@ -100,23 +100,23 @@ Installing this .service file consists of just copying it to
 /usr/lib/systemd/system directory, followed by the command
 `systemctl daemon-reload` in order to update running systemd configuration.
 
-To test, run `systemctl start bitcoind` and to enable for system startup run
-`systemctl enable bitcoind`
+To test, run `systemctl start aviand` and to enable for system startup run
+`systemctl enable aviand`
 
 NOTE: When installing for systemd in Debian/Ubuntu the .service file needs to be copied to the /lib/systemd/system directory instead.
 
 ### OpenRC
 
-Rename bitcoind.openrc to bitcoind and drop it in /etc/init.d.  Double
+Rename aviand.openrc to aviand and drop it in /etc/init.d.  Double
 check ownership and permissions and make it executable.  Test it with
-`/etc/init.d/bitcoind start` and configure it to run on startup with
-`rc-update add bitcoind`
+`/etc/init.d/aviand start` and configure it to run on startup with
+`rc-update add aviand`
 
 ### Upstart (for Debian/Ubuntu based distributions)
 
 Upstart is the default init system for Debian/Ubuntu versions older than 15.04. If you are using version 15.04 or newer and haven't manually configured upstart you should follow the systemd instructions instead.
 
-Drop bitcoind.conf in /etc/init.  Test by running `service bitcoind start`
+Drop aviand.conf in /etc/init.  Test by running `service aviand start`
 it will automatically start on reboot.
 
 NOTE: This script is incompatible with CentOS 5 and Amazon Linux 2014 as they
@@ -124,22 +124,22 @@ use old versions of Upstart and do not supply the start-stop-daemon utility.
 
 ### CentOS
 
-Copy bitcoind.init to /etc/init.d/bitcoind. Test by running `service bitcoind start`.
+Copy aviand.init to /etc/init.d/aviand. Test by running `service aviand start`.
 
-Using this script, you can adjust the path and flags to the bitcoind program by
-setting the BITCOIND and FLAGS environment variables in the file
-/etc/sysconfig/bitcoind. You can also use the DAEMONOPTS environment variable here.
+Using this script, you can adjust the path and flags to the aviand program by
+setting the AVIAND and FLAGS environment variables in the file
+/etc/sysconfig/aviand. You can also use the DAEMONOPTS environment variable here.
 
 ### macOS
 
-Copy org.bitcoin.bitcoind.plist into ~/Library/LaunchAgents. Load the launch agent by
-running `launchctl load ~/Library/LaunchAgents/org.bitcoin.bitcoind.plist`.
+Copy org.avian.aviand.plist into ~/Library/LaunchAgents. Load the launch agent by
+running `launchctl load ~/Library/LaunchAgents/org.avian.aviand.plist`.
 
-This Launch Agent will cause bitcoind to start whenever the user logs in.
+This Launch Agent will cause aviand to start whenever the user logs in.
 
-NOTE: This approach is intended for those wanting to run bitcoind as the current user.
-You will need to modify org.bitcoin.bitcoind.plist if you intend to use it as a
-Launch Daemon with a dedicated bitcoin user.
+NOTE: This approach is intended for those wanting to run aviand as the current user.
+You will need to modify org.avian.aviand.plist if you intend to use it as a
+Launch Daemon with a dedicated avian user.
 
 Auto-respawn
 -----------------------------------
diff --git a/doc/managing-wallets.md b/doc/managing-wallets.md
index 3ff983450..782709a92 100644
--- a/doc/managing-wallets.md
+++ b/doc/managing-wallets.md
@@ -9,21 +9,21 @@ Wallets can be created with the `createwallet` RPC or with the `Create wallet` G
 
 In the GUI, the `Create a new wallet` button is displayed on the main screen when there is no wallet loaded. Alternatively, there is the option `File` ->`Create wallet`.
 
-The following command, for example, creates a descriptor wallet. More information about this command may be found by running `bitcoin-cli help createwallet`.
+The following command, for example, creates a descriptor wallet. More information about this command may be found by running `avian-cli help createwallet`.
 
 ```
-$ bitcoin-cli createwallet "wallet-01"
+$ avian-cli createwallet "wallet-01"
 ```
 
-`bitcoin rpc` can also be substituted for `bitcoin-cli`.
+`avian rpc` can also be substituted for `avian-cli`.
 
 By default, wallets are created in the `wallets` folder of the data directory, which varies by operating system, as shown below. The user can change the default by using the `-datadir` or `-walletdir` initialization parameters.
 
 | Operating System | Default wallet directory                                    |
 | -----------------|:------------------------------------------------------------|
-| Linux            | `/home/<user>/.bitcoin/wallets`                             |
-| Windows          | `C:\Users\<user>\AppData\Local\Bitcoin\wallets`             |
-| macOS            | `/Users/<user>/Library/Application Support/Bitcoin/wallets` |
+| Linux            | `/home/<user>/.avianv5/wallets`                              |
+| Windows          | `C:\Users\<user>\AppData\Local\AvianV5\wallets`            |
+| macOS            | `/Users/<user>/Library/Application Support/AvianV5/wallets` |
 
 ### 1.2 Encrypting the Wallet
 
@@ -38,13 +38,13 @@ After encrypting the wallet or changing the passphrase, a new backup needs to be
 The wallet's private key may be encrypted with the following command:
 
 ```
-$ bitcoin-cli -rpcwallet="wallet-01" encryptwallet "passphrase"
+$ avian-cli -rpcwallet="wallet-01" encryptwallet "passphrase"
 ```
 
 Once encrypted, the passphrase can be changed with the `walletpassphrasechange` command.
 
 ```
-$ bitcoin-cli -rpcwallet="wallet-01" walletpassphrasechange "oldpassphrase" "newpassphrase"
+$ avian-cli -rpcwallet="wallet-01" walletpassphrasechange "oldpassphrase" "newpassphrase"
 ```
 
 The argument passed to `-rpcwallet` is the name of the wallet to be encrypted.
@@ -54,7 +54,7 @@ Only the wallet's private key is encrypted. All other wallet information, such a
 The wallet's private key can also be encrypted in the `createwallet` command via the `passphrase` argument:
 
 ```
-$ bitcoin-cli -named createwallet wallet_name="wallet-01" passphrase="passphrase"
+$ avian-cli -named createwallet wallet_name="wallet-01" passphrase="passphrase"
 ```
 
 Note that if the passphrase is lost, all the coins in the wallet will also be lost forever.
@@ -64,7 +64,7 @@ Note that if the passphrase is lost, all the coins in the wallet will also be lo
 If the wallet is encrypted and the user tries any operation related to private keys, such as sending bitcoins, an error message will be displayed.
 
 ```
-$ bitcoin-cli -rpcwallet="wallet-01" sendtoaddress "tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx" 0.01
+$ avian-cli -rpcwallet="wallet-01" sendtoaddress "tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx" 0.01
 error code: -13
 error message:
 Error: Please enter the wallet passphrase with walletpassphrase first.
@@ -75,7 +75,7 @@ To unlock the wallet and allow it to run these operations, the `walletpassphrase
 This command takes the passphrase and an argument called `timeout`, which specifies the time in seconds that the wallet decryption key is stored in memory. After this period expires, the user needs to execute this RPC again.
 
 ```
-$ bitcoin-cli -rpcwallet="wallet-01" walletpassphrase "passphrase" 120
+$ avian-cli -rpcwallet="wallet-01" walletpassphrase "passphrase" 120
 ```
 
 In the GUI, there is no specific menu item to unlock the wallet. When the user sends bitcoins, the passphrase will be prompted automatically.
@@ -87,7 +87,7 @@ To backup the wallet, the `backupwallet` RPC or the `Backup Wallet` GUI menu ite
 In the RPC, the destination parameter must include the name of the file. Otherwise, the command will return an error message like "Error: Wallet backup failed!".
 
 ```
-$ bitcoin-cli -rpcwallet="wallet-01" backupwallet /home/node01/Backups/backup-01.dat
+$ avian-cli -rpcwallet="wallet-01" backupwallet /home/node01/Backups/backup-01.dat
 ```
 
 In the GUI, the wallet is selected in the `Wallet` drop-down list in the upper right corner. If this list is not present, the wallet can be loaded in `File` ->`Open Wallet` if necessary. Then, the backup can be done in `File` -> `Backup Wallet…`.
@@ -113,13 +113,13 @@ Wallets created before version 0.13 are not HD and must be backed up every 100 k
 To restore a wallet, the `restorewallet` RPC or the `Restore Wallet` GUI menu item (`File` -> `Restore Wallet…`) must be used.
 
 ```
-$ bitcoin-cli restorewallet "restored-wallet" /home/node01/Backups/backup-01.dat
+$ avian-cli restorewallet "restored-wallet" /home/node01/Backups/backup-01.dat
 ```
 
 After that, `getwalletinfo` can be used to check if the wallet has been fully restored.
 
 ```
-$ bitcoin-cli -rpcwallet="restored-wallet" getwalletinfo
+$ avian-cli -rpcwallet="restored-wallet" getwalletinfo
 ```
 
 The restored wallet can also be loaded in the GUI via `File` ->`Open wallet`.
diff --git a/doc/multisig-tutorial.md b/doc/multisig-tutorial.md
index 0c39bc6c9..d4f0ce2e8 100644
--- a/doc/multisig-tutorial.md
+++ b/doc/multisig-tutorial.md
@@ -9,7 +9,7 @@ This tutorial uses [jq](https://github.com/stedolan/jq) JSON processor to proces
 Before starting this tutorial, start the bitcoin node on the signet network.
 
 ```bash
-./build/bin/bitcoind -signet -daemon
+./build/bin/aviand -signet -daemon
 ```
 
 This tutorial also uses the default WPKH derivation path to get the xpubs and does not conform to [BIP 45](https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki) or [BIP 87](https://github.com/bitcoin/bips/blob/master/bip-0087.mediawiki).
@@ -27,11 +27,11 @@ These three wallets should not be used directly for privacy reasons (public key
 ```bash
 for ((n=1;n<=3;n++))
 do
- ./build/bin/bitcoin-cli -signet createwallet "participant_${n}"
+ ./build/bin/avian-cli -signet createwallet "participant_${n}"
 done
 ```
 
-`bitcoin rpc` can also be substituted for `bitcoin-cli`.
+`avian rpc` can also be substituted for `avian-cli`.
 
 Extract the xpub of each wallet. To do this, the `listdescriptors` RPC is used. By default, Bitcoin Core single-sig wallets are created using path `m/44'/1'/0'` for PKH, `m/84'/1'/0'` for WPKH, `m/49'/1'/0'` for P2WPKH-nested-in-P2SH and `m/86'/1'/0'` for P2TR based accounts. Each of them uses the chain 0 for external addresses and chain 1 for internal ones, as shown in the example below.
 
@@ -49,9 +49,9 @@ declare -A xpubs
 
 for ((n=1;n<=3;n++))
 do
- xpubs["internal_xpub_${n}"]=$(./build/bin/bitcoin-cli -signet -rpcwallet="participant_${n}" listdescriptors | jq '.descriptors | [.[] | select(.desc | startswith("wpkh") and contains("/1/*"))][0] | .desc' | grep -Po '(?<=\().*(?=\))')
+ xpubs["internal_xpub_${n}"]=$(./build/bin/avian-cli -signet -rpcwallet="participant_${n}" listdescriptors | jq '.descriptors | [.[] | select(.desc | startswith("wpkh") and contains("/1/*"))][0] | .desc' | grep -Po '(?<=\().*(?=\))')
 
- xpubs["external_xpub_${n}"]=$(./build/bin/bitcoin-cli -signet -rpcwallet="participant_${n}" listdescriptors | jq '.descriptors | [.[] | select(.desc | startswith("wpkh") and contains("/0/*") )][0] | .desc' | grep -Po '(?<=\().*(?=\))')
+ xpubs["external_xpub_${n}"]=$(./build/bin/avian-cli -signet -rpcwallet="participant_${n}" listdescriptors | jq '.descriptors | [.[] | select(.desc | startswith("wpkh") and contains("/0/*") )][0] | .desc' | grep -Po '(?<=\().*(?=\))')
 done
 ```
 
@@ -73,8 +73,8 @@ Define the external and internal multisig descriptors, add the checksum and then
 external_desc="wsh(sortedmulti(2,${xpubs["external_xpub_1"]},${xpubs["external_xpub_2"]},${xpubs["external_xpub_3"]}))"
 internal_desc="wsh(sortedmulti(2,${xpubs["internal_xpub_1"]},${xpubs["internal_xpub_2"]},${xpubs["internal_xpub_3"]}))"
 
-external_desc_sum=$(./build/bin/bitcoin-cli -signet getdescriptorinfo $external_desc | jq '.descriptor')
-internal_desc_sum=$(./build/bin/bitcoin-cli -signet getdescriptorinfo $internal_desc | jq '.descriptor')
+external_desc_sum=$(./build/bin/avian-cli -signet getdescriptorinfo $external_desc | jq '.descriptor')
+internal_desc_sum=$(./build/bin/avian-cli -signet getdescriptorinfo $internal_desc | jq '.descriptor')
 
 multisig_ext_desc="{\"desc\": $external_desc_sum, \"active\": true, \"internal\": false, \"timestamp\": \"now\"}"
 multisig_int_desc="{\"desc\": $internal_desc_sum, \"active\": true, \"internal\": true, \"timestamp\": \"now\"}"
@@ -96,7 +96,7 @@ There are other fields that can be added to the descriptors:
 * `internal`: Indicates whether matching outputs should be treated as something other than incoming payments (e.g. change).
 * `timestamp`: Sets the time from which to start rescanning the blockchain for the descriptor, in UNIX epoch time.
 
-Documentation for these and other parameters can be found by typing `./build/bin/bitcoin-cli help importdescriptors`.
+Documentation for these and other parameters can be found by typing `./build/bin/avian-cli help importdescriptors`.
 
 `multisig_desc` concatenates external and internal descriptors in a JSON array and then it will be used to create the multisig wallet.
 
@@ -109,17 +109,17 @@ Then import the descriptors created in the previous step using the `importdescri
 After that, `getwalletinfo` can be used to check if the wallet was created successfully.
 
 ```bash
-./build/bin/bitcoin-cli -signet -named createwallet wallet_name="multisig_wallet_01" disable_private_keys=true blank=true
+./build/bin/avian-cli -signet -named createwallet wallet_name="multisig_wallet_01" disable_private_keys=true blank=true
 
-./build/bin/bitcoin-cli  -signet -rpcwallet="multisig_wallet_01" importdescriptors "$multisig_desc"
+./build/bin/avian-cli  -signet -rpcwallet="multisig_wallet_01" importdescriptors "$multisig_desc"
 
-./build/bin/bitcoin-cli  -signet -rpcwallet="multisig_wallet_01" getwalletinfo
+./build/bin/avian-cli  -signet -rpcwallet="multisig_wallet_01" getwalletinfo
 ```
 
 Once the wallets have already been created and this tutorial needs to be repeated or resumed, it is not necessary to recreate them, just load them with the command below:
 
 ```bash
-for ((n=1;n<=3;n++)); do ./build/bin/bitcoin-cli -signet loadwallet "participant_${n}"; done
+for ((n=1;n<=3;n++)); do ./build/bin/avian-cli -signet loadwallet "participant_${n}"; done
 ```
 
 ### 1.4 Fund the wallet
@@ -133,9 +133,9 @@ The url used by the script can also be accessed directly. At time of writing, th
 Coins received by the wallet must have at least 1 confirmation before they can be spent. It is necessary to wait for a new block to be mined before continuing.
 
 ```bash
-receiving_address=$(./build/bin/bitcoin-cli -signet -rpcwallet="multisig_wallet_01" getnewaddress)
+receiving_address=$(./build/bin/avian-cli -signet -rpcwallet="multisig_wallet_01" getnewaddress)
 
-./contrib/signet/getcoins.py -c ./build/bin/bitcoin-cli -a $receiving_address
+./contrib/signet/getcoins.py -c ./build/bin/avian-cli -a $receiving_address
 ```
 
 To copy the receiving address onto the clipboard, use the following command. This can be useful when getting coins via the signet faucet mentioned above.
@@ -147,7 +147,7 @@ echo -n "$receiving_address" | xclip -sel clip
 The `getbalances` RPC may be used to check the balance. Coins with `trusted` status can be spent.
 
 ```bash
-./build/bin/bitcoin-cli -signet -rpcwallet="multisig_wallet_01" getbalances
+./build/bin/avian-cli -signet -rpcwallet="multisig_wallet_01" getbalances
 ```
 
 ### 1.5 Create a PSBT
@@ -163,13 +163,13 @@ For simplicity, the destination address is taken from the `participant_1` wallet
 The `walletcreatefundedpsbt` RPC is used to create and fund a transaction in the PSBT format. It is the first step in creating the PSBT.
 
 ```bash
-balance=$(./build/bin/bitcoin-cli -signet -rpcwallet="multisig_wallet_01" getbalance)
+balance=$(./build/bin/avian-cli -signet -rpcwallet="multisig_wallet_01" getbalance)
 
 amount=$(echo "$balance * 0.8" | bc -l | sed -e 's/^\./0./' -e 's/^-\./-0./')
 
-destination_addr=$(./build/bin/bitcoin-cli -signet -rpcwallet="participant_1" getnewaddress)
+destination_addr=$(./build/bin/avian-cli -signet -rpcwallet="participant_1" getnewaddress)
 
-funded_psbt=$(./build/bin/bitcoin-cli -signet -named -rpcwallet="multisig_wallet_01" walletcreatefundedpsbt outputs="{\"$destination_addr\": $amount}" | jq -r '.psbt')
+funded_psbt=$(./build/bin/avian-cli -signet -named -rpcwallet="multisig_wallet_01" walletcreatefundedpsbt outputs="{\"$destination_addr\": $amount}" | jq -r '.psbt')
 ```
 
 There is also the `createpsbt` RPC, which serves the same purpose, but it has no access to the wallet or to the UTXO set. It is functionally the same as `createrawtransaction` and just drops the raw transaction into an otherwise blank PSBT. [[source](https://bitcointalk.org/index.php?topic=5131043.msg50573609#msg50573609)] In most cases, `walletcreatefundedpsbt` solves the problem.
@@ -183,9 +183,9 @@ Optionally, the PSBT can be decoded to a JSON format using `decodepsbt` RPC.
 The `analyzepsbt` RPC analyzes and provides information about the current status of a PSBT and its inputs, e.g. missing signatures.
 
 ```bash
-./build/bin/bitcoin-cli -signet decodepsbt $funded_psbt
+./build/bin/avian-cli -signet decodepsbt $funded_psbt
 
-./build/bin/bitcoin-cli -signet analyzepsbt $funded_psbt
+./build/bin/avian-cli -signet analyzepsbt $funded_psbt
 ```
 
 ### 1.7 Update the PSBT
@@ -195,9 +195,9 @@ In the code above, two PSBTs are created. One signed by `participant_1` wallet a
 The `walletprocesspsbt` is used by the wallet to sign a PSBT.
 
 ```bash
-psbt_1=$(./build/bin/bitcoin-cli -signet -rpcwallet="participant_1" walletprocesspsbt $funded_psbt | jq '.psbt')
+psbt_1=$(./build/bin/avian-cli -signet -rpcwallet="participant_1" walletprocesspsbt $funded_psbt | jq '.psbt')
 
-psbt_2=$(./build/bin/bitcoin-cli -signet -rpcwallet="participant_2" walletprocesspsbt $funded_psbt | jq '.psbt')
+psbt_2=$(./build/bin/avian-cli -signet -rpcwallet="participant_2" walletprocesspsbt $funded_psbt | jq '.psbt')
 ```
 
 ### 1.8 Combine the PSBT
@@ -205,7 +205,7 @@ psbt_2=$(./build/bin/bitcoin-cli -signet -rpcwallet="participant_2" walletproces
 The PSBT, if signed separately by the co-signers, must be combined into one transaction before being finalized. This is done by `combinepsbt` RPC.
 
 ```bash
-combined_psbt=$(./build/bin/bitcoin-cli -signet combinepsbt "[$psbt_1, $psbt_2]")
+combined_psbt=$(./build/bin/avian-cli -signet combinepsbt "[$psbt_1, $psbt_2]")
 ```
 
 There is an RPC called `joinpsbts`, but it has a different purpose than `combinepsbt`. `joinpsbts` joins the inputs from multiple distinct PSBTs into one PSBT.
@@ -219,9 +219,9 @@ The `finalizepsbt` RPC is used to produce a network serialized transaction which
 It checks that all inputs have complete scriptSigs and scriptWitnesses and, if so, encodes them into network serialized transactions.
 
 ```bash
-finalized_psbt_hex=$(./build/bin/bitcoin-cli -signet finalizepsbt $combined_psbt | jq -r '.hex')
+finalized_psbt_hex=$(./build/bin/avian-cli -signet finalizepsbt $combined_psbt | jq -r '.hex')
 
-./build/bin/bitcoin-cli -signet sendrawtransaction $finalized_psbt_hex
+./build/bin/avian-cli -signet sendrawtransaction $finalized_psbt_hex
 ```
 
 ### 1.10 Alternative Workflow (PSBT sequential signatures)
@@ -231,11 +231,11 @@ Instead of each wallet signing the original PSBT and combining them later, the w
 After that, the rest of the process is the same: the PSBT is finalized and transmitted to the network.
 
 ```bash
-psbt_1=$(./build/bin/bitcoin-cli -signet -rpcwallet="participant_1" walletprocesspsbt $funded_psbt | jq -r '.psbt')
+psbt_1=$(./build/bin/avian-cli -signet -rpcwallet="participant_1" walletprocesspsbt $funded_psbt | jq -r '.psbt')
 
-psbt_2=$(./build/bin/bitcoin-cli -signet -rpcwallet="participant_2" walletprocesspsbt $psbt_1 | jq -r '.psbt')
+psbt_2=$(./build/bin/avian-cli -signet -rpcwallet="participant_2" walletprocesspsbt $psbt_1 | jq -r '.psbt')
 
-finalized_psbt_hex=$(./build/bin/bitcoin-cli -signet finalizepsbt $psbt_2 | jq -r '.hex')
+finalized_psbt_hex=$(./build/bin/avian-cli -signet finalizepsbt $psbt_2 | jq -r '.hex')
 
-./build/bin/bitcoin-cli -signet sendrawtransaction $finalized_psbt_hex
+./build/bin/avian-cli -signet sendrawtransaction $finalized_psbt_hex
 ```
diff --git a/doc/offline-signing-tutorial.md b/doc/offline-signing-tutorial.md
index 2b21af244..88080f6ee 100644
--- a/doc/offline-signing-tutorial.md
+++ b/doc/offline-signing-tutorial.md
@@ -25,7 +25,7 @@ We are going to first create an `offline_wallet` on the offline host. We will th
 1. On the offline machine create a wallet named `offline_wallet` secured by a wallet `passphrase`. This wallet will contain private keys and must remain unconnected to any networks at all times.
 
 ```sh
-[offline]$ ./build/bin/bitcoin-cli -signet -named createwallet \
+[offline]$ ./build/bin/avian-cli -signet -named createwallet \
                 wallet_name="offline_wallet" \
                 passphrase="** enter passphrase **"
 
@@ -34,7 +34,7 @@ We are going to first create an `offline_wallet` on the offline host. We will th
 }
 ```
 
-`bitcoin rpc` can also be substituted for `bitcoin-cli`.
+`avian rpc` can also be substituted for `avian-cli`.
 
 > [!NOTE]
 > The use of a passphrase is crucial to encrypt the wallet.dat file. This encryption ensures that even if an unauthorized individual gains access to the offline host, they won't be able to access the wallet's contents. Further details about securing your wallet can be found in  [Managing the Wallet](https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md#12-encrypting-the-wallet)
@@ -42,7 +42,7 @@ We are going to first create an `offline_wallet` on the offline host. We will th
 2. Export the public key-only descriptors from the offline host to a JSON file named `descriptors.json`. We use `jq` here to extract the `.descriptors` field from the full RPC response.
 
 ```sh
-[offline]$ ./build/bin/bitcoin-cli -signet -rpcwallet="offline_wallet" listdescriptors \
+[offline]$ ./build/bin/avian-cli -signet -rpcwallet="offline_wallet" listdescriptors \
              | jq -r '.descriptors' \
              >> /path/to/descriptors.json
 ```
@@ -60,7 +60,7 @@ The `watch_only_wallet` wallet will be used to track and validate incoming trans
 > `disable_private_keys` indicates that the wallet should refuse to import private keys, i.e. will be a dedicated watch-only wallet.
 
 ```sh
-[online]$ ./build/bin/bitcoin-cli -signet -named createwallet \
+[online]$ ./build/bin/avian-cli -signet -named createwallet \
               wallet_name="watch_only_wallet" \
               disable_private_keys=true \
               blank=true
@@ -73,7 +73,7 @@ The `watch_only_wallet` wallet will be used to track and validate incoming trans
 2. Import the `offline_wallet`s public key descriptors to the online `watch_only_wallet` using the `descriptors.json` file created on the offline wallet.
 
 ```sh
-[online]$ ./build/bin/bitcoin-cli -signet -rpcwallet="watch_only_wallet" importdescriptors "$(cat /path/to/descriptors.json)"
+[online]$ ./build/bin/avian-cli -signet -rpcwallet="watch_only_wallet" importdescriptors "$(cat /path/to/descriptors.json)"
 
 [
   {
@@ -112,7 +112,7 @@ At this point, it's important to understand that both the `offline_wallet` and o
 1. Generate an address to receive coins. You can use _either_ the `offline_wallet` or the online `watch_only_wallet` to generate this address, as they will produce the same addresses. For the sake of this guide, we'll use the online `watch_only_wallet` to generate the address.
 
 ```sh
-[online]$ ./build/bin/bitcoin-cli -signet -rpcwallet="watch_only_wallet" getnewaddress
+[online]$ ./build/bin/avian-cli -signet -rpcwallet="watch_only_wallet" getnewaddress
 
 tb1qtu5qgc6ddhmqm5yqjvhg83qgk2t4ewajg0h6yh
 ```
@@ -122,7 +122,7 @@ tb1qtu5qgc6ddhmqm5yqjvhg83qgk2t4ewajg0h6yh
 3. Confirm that coins were received using the online `watch_only_wallet`. Note that the transaction may take a few moments before being received on your local node, depending on its connectivity. Just re-run the command periodically until the transaction is received.
 
 ```sh
-[online]$ ./build/bin/bitcoin-cli -signet -rpcwallet="watch_only_wallet" listunspent
+[online]$ ./build/bin/avian-cli -signet -rpcwallet="watch_only_wallet" listunspent
 
 [
   {
@@ -151,7 +151,7 @@ tb1qtu5qgc6ddhmqm5yqjvhg83qgk2t4ewajg0h6yh
 2. Create a funded but unsigned PSBT to the destination address with the online `watch_only_wallet` by using `send [{"address":amount},...]` and export the unsigned PSBT to a file `funded_psbt.txt` for easy portability to the `offline_wallet` for signing:
 
 ```sh
-[online]$ ./build/bin/bitcoin-cli -signet -rpcwallet="watch_only_wallet" send \
+[online]$ ./build/bin/avian-cli -signet -rpcwallet="watch_only_wallet" send \
               '{"tb1q9k5w0nhnhyeh78snpxh0t5t7c3lxdeg3erez32": 0.009}' \
               | jq -r '.psbt' \
               >> /path/to/funded_psbt.txt
@@ -168,13 +168,13 @@ cHNidP8BAHECAAAAAWLHKR9/xAjetzL/FCmZU5lbfINRMWPRPHWO68PfUzkPAQAAAAD9////AoA4AQAA
 Decode and analyze the unsigned PSBT on the `offline_wallet` using the `funded_psbt.txt` file:
 
 ```sh
-[offline]$ ./build/bin/bitcoin-cli -signet decodepsbt $(cat /path/to/funded_psbt.txt)
+[offline]$ ./build/bin/avian-cli -signet decodepsbt $(cat /path/to/funded_psbt.txt)
 
 {
     ...
 }
 
-[offline]$ ./build/bin/bitcoin-cli -signet analyzepsbt $(cat /path/to/funded_psbt.txt)
+[offline]$ ./build/bin/avian-cli -signet analyzepsbt $(cat /path/to/funded_psbt.txt)
 
 {
   "inputs": [
@@ -205,13 +205,13 @@ Notice that the analysis of the PSBT shows that "signatures" are missing and sho
 Use the walletpassphrase command to unlock the `offline_wallet` with the passphrase. You should specify the passphrase and a timeout (in seconds) for how long you want the wallet to remain unlocked.
 
 ```sh
-[offline]$ ./build/bin/bitcoin-cli -signet -rpcwallet="offline_wallet" walletpassphrase "** enter passphrase **" 60
+[offline]$ ./build/bin/avian-cli -signet -rpcwallet="offline_wallet" walletpassphrase "** enter passphrase **" 60
 ```
 
 2. Process, sign and finalize the PSBT on the `offline_wallet` using the `walletprocesspsbt` command, saving the output to a file `final_psbt.txt`.
 
  ```sh
-[offline]$ ./build/bin/bitcoin-cli -signet -rpcwallet="offline_wallet" walletprocesspsbt \
+[offline]$ ./build/bin/avian-cli -signet -rpcwallet="offline_wallet" walletprocesspsbt \
                 $(cat /path/to/funded_psbt.txt) \
                 | jq -r .hex \
                 >> /path/to/final_psbt.txt
@@ -221,7 +221,7 @@ Use the walletpassphrase command to unlock the `offline_wallet` with the passphr
 Broadcast the funded, signed and finalized PSBT `final_psbt.txt` using `sendrawtransaction` with an online node:
 
 ```sh
-[online]$ ./build/bin/bitcoin-cli -signet sendrawtransaction $(cat /path/to/final_psbt.txt)
+[online]$ ./build/bin/avian-cli -signet sendrawtransaction $(cat /path/to/final_psbt.txt)
 
 c2430a0e46df472b04b0ca887bbcd5c4abf7b2ce2eb71de981444a80e2b96d52
 ```
@@ -231,7 +231,7 @@ c2430a0e46df472b04b0ca887bbcd5c4abf7b2ce2eb71de981444a80e2b96d52
 Confirm the updated balance of the offline wallet using the `watch_only_wallet`.
 
 ```sh
-[online]$ ./build/bin/bitcoin-cli -signet -rpcwallet="watch_only_wallet" getbalances
+[online]$ ./build/bin/avian-cli -signet -rpcwallet="watch_only_wallet" getbalances
 
 {
   "mine": {
@@ -250,7 +250,7 @@ Confirm the updated balance of the offline wallet using the `watch_only_wallet`.
 You can also show transactions related to the wallet using `listtransactions`
 
 ```sh
-[online]$ ./build/bin/bitcoin-cli -signet -rpcwallet="watch_only_wallet" listtransactions
+[online]$ ./build/bin/avian-cli -signet -rpcwallet="watch_only_wallet" listtransactions
 
 {
     ...
diff --git a/doc/reduce-memory.md b/doc/reduce-memory.md
index cac5dc982..27c03330e 100644
--- a/doc/reduce-memory.md
+++ b/doc/reduce-memory.md
@@ -1,6 +1,6 @@
 # Reduce Memory
 
-There are a few parameters that can be dialed down to reduce the memory usage of `bitcoind`. This can be useful on embedded systems or small VPSes.
+There are a few parameters that can be dialed down to reduce the memory usage of `aviand`. This can be useful on embedded systems or small VPSes.
 
 ## In-memory caches
 
@@ -14,7 +14,7 @@ The size of some in-memory caches can be reduced. As caches trade off memory usa
 
 - In Bitcoin Core there is a memory pool limiter which can be configured with `-maxmempool=<n>`, where `<n>` is the size in MB (1000). The default value is `300`.
   - The minimum value for `-maxmempool` is 5.
-  - A lower maximum mempool size means that transactions will be evicted sooner. This will affect any uses of `bitcoind` that process unconfirmed transactions.
+  - A lower maximum mempool size means that transactions will be evicted sooner. This will affect any uses of `aviand` that process unconfirmed transactions.
 
 - The unused memory allocated to the mempool (default: 300MB) is shared with the UTXO cache, so when trying to reduce memory usage you should limit the mempool, with the `-maxmempool` command line argument.
 
@@ -43,12 +43,12 @@ threads take up 8MiB for the thread stack on a 64-bit system, and 4MiB in a
 
 ## Linux specific
 
-By default, glibc's implementation of `malloc` may use more than one arena. This is known to cause excessive memory usage in some scenarios. To avoid this, make a script that sets `MALLOC_ARENA_MAX` before starting bitcoind:
+By default, glibc's implementation of `malloc` may use more than one arena. This is known to cause excessive memory usage in some scenarios. To avoid this, make a script that sets `MALLOC_ARENA_MAX` before starting aviand:
 
 ```bash
 #!/usr/bin/env bash
 export MALLOC_ARENA_MAX=1
-bitcoind
+aviand
 ```
 
 The behavior was introduced to increase CPU locality of allocated memory and performance with concurrent allocation, so this setting could in theory reduce performance. However, in Bitcoin Core very little parallel allocation happens, so the impact is expected to be small or absent.
diff --git a/doc/release-process.md b/doc/release-process.md
index 97fd116ca..9ad8102bb 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -7,7 +7,7 @@ Release Process
 
 * Update release candidate version in `CMakeLists.txt` (`CLIENT_VERSION_RC`).
 * Update manpages (after rebuilding the binaries), see [gen-manpages.py](/contrib/devtools/README.md#gen-manpagespy).
-* Update bitcoin.conf and commit changes if they exist, see [gen-avian-conf.sh](/contrib/devtools/README.md#gen-avian-confsh).
+* Update avian.conf and commit changes if they exist, see [gen-avian-conf.sh](/contrib/devtools/README.md#gen-avian-confsh).
 
 ### Before every major and minor release
 
@@ -44,7 +44,7 @@ Release Process
     - On mainnet, the selected value must not be orphaned, so it may be useful to set the height two blocks back from the tip.
     - Testnet should be set with a height some tens of thousands back from the tip, due to reorgs there.
   - `nMinimumChainWork` with the "chainwork" value of RPC `getblockheader` using the same height as that selected for the previous step.
-  - `m_assumeutxo_data` array should be appended to with the values returned by calling `bitcoin-cli -rpcclienttimeout=0 -named dumptxoutset utxo.dat rollback=<height or hash>`
+  - `m_assumeutxo_data` array should be appended to with the values returned by calling `avian-cli -rpcclienttimeout=0 -named dumptxoutset utxo.dat rollback=<height or hash>`
     The same height considerations for `defaultAssumeValid` apply.
 * Consider updating the headers synchronization tuning parameters to account for the chainparams updates.
   The optimal values change very slowly, so this isn't strictly necessary every release, but doing so doesn't hurt.
diff --git a/doc/tor.md b/doc/tor.md
index 839c02eea..187318bd7 100644
--- a/doc/tor.md
+++ b/doc/tor.md
@@ -25,9 +25,9 @@ CLI `-addrinfo` returns the number of addresses known to your node per
 network. This can be useful to see how many onion peers your node knows,
 e.g. for `-onlynet=onion`.
 
-You can use the `getnodeaddresses` RPC to fetch a number of onion peers known to your node; run `bitcoin-cli help getnodeaddresses` for details.
+You can use the `getnodeaddresses` RPC to fetch a number of onion peers known to your node; run `avian-cli help getnodeaddresses` for details.
 
-`bitcoin rpc` can also be substituted for `bitcoin-cli`.
+`bitcoin rpc` can also be substituted for `avian-cli`.
 
 ## 1. Run Bitcoin Core behind a Tor proxy
 
@@ -84,9 +84,9 @@ with the prefix `unix:` (e.g. `-onion=unix:/home/me/torsocket`).
 
 In a typical situation, this suffices to run behind a Tor proxy:
 
-    bitcoind -proxy=127.0.0.1:9050
+    aviand -proxy=127.0.0.1:9050
 
-`bitcoin node` or `bitcoin gui` can also be substituted for `bitcoind`.
+`avian node` or `avian gui` can also be substituted for `aviand`.
 
 ## 2. Automatically create a Bitcoin Core onion service
 
@@ -96,12 +96,12 @@ proper authentication has been configured, Bitcoin Core automatically creates an
 onion service to listen on. The goal is to increase the number of available
 onion nodes.
 
-This feature is enabled by default if Bitcoin Core is listening (`-listen`) and
+This feature is enabled by default if Avian Core is listening (`-listen`) and
 it requires a Tor connection to work. It can be explicitly disabled with
 `-listenonion=0`. If it is not disabled, it can be configured using the
 `-torcontrol` and `-torpassword` settings.
 
-To see verbose Tor information in the bitcoind debug log, pass `-debug=tor`.
+To see verbose Tor information in the aviand debug log, pass `-debug=tor`.
 
 ### Control Port
 
@@ -123,20 +123,20 @@ Debian and Ubuntu, or just restart the computer).
 ### Authentication
 
 Connecting to Tor's control socket API requires one of two authentication
-methods to be configured: cookie authentication or bitcoind's `-torpassword`
+methods to be configured: cookie authentication or aviand's `-torpassword`
 configuration option.
 
 #### Cookie authentication
 
-For cookie authentication, the user running bitcoind must have read access to
+For cookie authentication, the user running aviand must have read access to
 the `CookieAuthFile` specified in the Tor configuration. In some cases this is
 preconfigured and the creation of an onion service is automatic. Don't forget to
-use the `-debug=tor` bitcoind configuration option to enable Tor debug logging.
+use the `-debug=tor` aviand configuration option to enable Tor debug logging.
 
 If a permissions problem is seen in the debug log, e.g. `tor: Authentication
 cookie /run/tor/control.authcookie could not be opened (check permissions)`, it
 can be resolved by adding both the user running Tor and the user running
-bitcoind to the same Tor group and setting permissions appropriately.
+aviand to the same Tor group and setting permissions appropriately.
 
 On Debian-derived systems, the Tor group will likely be `debian-tor` and one way
 to verify could be to list the groups and grep for a "tor" group name:
@@ -153,14 +153,14 @@ TORGROUP=$(stat -c '%G' /run/tor/control.authcookie)
 ```
 
 Once you have determined the `${TORGROUP}` and selected the `${USER}` that will
-run bitcoind, run this as root:
+run aviand, run this as root:
 
 ```
 usermod -a -G ${TORGROUP} ${USER}
 ```
 
 Then restart the computer (or log out) and log in as the `${USER}` that will run
-bitcoind.
+aviand.
 
 #### `torpassword` authentication
 
@@ -183,7 +183,7 @@ Add these lines to your `/etc/tor/torrc` (or equivalent config file):
     HiddenServicePort 8333 127.0.0.1:8334
 
 The directory can be different of course, but virtual port numbers should be equal to
-your bitcoind's P2P listen port (8333 by default), and target addresses and ports
+your aviand's P2P listen port (8333 by default), and target addresses and ports
 should be equal to binding address and port for inbound Tor connections (127.0.0.1:8334 by default).
 
     -externalip=X   You can tell bitcoin about its publicly reachable addresses using
@@ -211,25 +211,25 @@ should be equal to binding address and port for inbound Tor connections (127.0.0
 
 In a typical situation, where you're only reachable via Tor, this should suffice:
 
-    bitcoind -proxy=127.0.0.1:9050 -externalip=7zvj7a2imdgkdbg4f2dryd5rgtrn7upivr5eeij4cicjh65pooxeshid.onion -listen
+    aviand -proxy=127.0.0.1:9050 -externalip=7zvj7a2imdgkdbg4f2dryd5rgtrn7upivr5eeij4cicjh65pooxeshid.onion -listen
 
 (obviously, replace the .onion address with your own). It should be noted that you still
 listen on all devices and another node could establish a clearnet connection, when knowing
 your address. To mitigate this, additionally bind the address of your Tor proxy:
 
-    bitcoind ... -bind=127.0.0.1:8334=onion
+    aviand ... -bind=127.0.0.1:8334=onion
 
 If you don't care too much about hiding your node, and want to be reachable on IPv4
 as well, use `discover` instead:
 
-    bitcoind ... -discover
+    aviand ... -discover
 
 and open port 8333 on your firewall (or use port mapping, i.e., `-natpmp`).
 
 If you only want to use Tor to reach .onion addresses, but not use it as a proxy
 for normal IPv4/IPv6 communication, use:
 
-    bitcoind -onion=127.0.0.1:9050 -externalip=7zvj7a2imdgkdbg4f2dryd5rgtrn7upivr5eeij4cicjh65pooxeshid.onion -discover
+    aviand -onion=127.0.0.1:9050 -externalip=7zvj7a2imdgkdbg4f2dryd5rgtrn7upivr5eeij4cicjh65pooxeshid.onion -discover
 
 ## 4. Privacy recommendations
 
diff --git a/doc/zmq.md b/doc/zmq.md
index b88c93a6b..be154a403 100644
--- a/doc/zmq.md
+++ b/doc/zmq.md
@@ -81,17 +81,17 @@ The high water mark value must be an integer greater than or equal to 0.
 
 For instance:
 
-    $ bitcoind -zmqpubhashtx=tcp://127.0.0.1:28332 \
+    $ aviand -zmqpubhashtx=tcp://127.0.0.1:28332 \
                -zmqpubhashtx=tcp://192.168.1.2:28332 \
                -zmqpubhashblock="tcp://[::1]:28333" \
-               -zmqpubrawtx=unix:/tmp/bitcoind.tx.raw \
+               -zmqpubrawtx=unix:/tmp/aviand.tx.raw \
                -zmqpubhashtxhwm=10000
 
-`bitcoin node` or `bitcoin gui` can also be substituted for `bitcoind`.
+`avian node` or `avian gui` can also be substituted for `aviand`.
 
 Notification types correspond to message topics (details in next section). For instance,
 for the notification `-zmqpubhashtx` the topic is `hashtx`. These options can also be
-provided in bitcoin.conf.
+provided in avian.conf.
 
 ### Message format
 
@@ -180,9 +180,9 @@ hosts as well. If needed, this option has to be set on the client side too.
 
 ## Remarks
 
-From the perspective of bitcoind, the ZeroMQ socket is write-only; PUB
+From the perspective of aviand, the ZeroMQ socket is write-only; PUB
 sockets don't even have a read function. Thus, there is no state
-introduced into bitcoind directly. Furthermore, no information is
+introduced into aviand directly. Furthermore, no information is
 broadcast that wasn't already received from the public P2P network.
 
 No authentication or authorization is done on connecting clients; it
@@ -199,7 +199,7 @@ disconnections.
 
 There are several possibilities that ZMQ notification can get lost
 during transmission depending on the communication type you are
-using. Bitcoind appends an up-counting sequence number to each
+using. aviand appends an up-counting sequence number to each
 notification which allows listeners to detect lost notifications.
 
 The `sequence` topic refers specifically to the mempool sequence