diff --git a/doc/JSON-RPC-interface.md b/doc/JSON-RPC-interface.md
--- 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 `ecashd` has the JSON-RPC API enabled by default, the GUI
+`ecash-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.
 
@@ -62,7 +62,7 @@
   withstand arbitrary Internet traffic, so changing the above settings
   to expose it to the Internet (even using something like a Tor hidden
   service) could expose you to unconsidered vulnerabilities.  See
-  `bitcoind -help` for more information about these settings and other
+  `ecashd -help` for more information about these settings and other
   settings described in this document.
 
     Related, if you use Bitcoin ABC inside a Docker container, you may
diff --git a/doc/README.md b/doc/README.md
--- a/doc/README.md
+++ b/doc/README.md
@@ -50,12 +50,12 @@
 
 Unpack the files into a directory and run:
 
-- `bin/bitcoin-qt` (GUI) or
-- `bin/bitcoind` (headless)
+- `bin/ecash-qt` (GUI) or
+- `bin/ecashd` (headless)
 
 ### Windows
 
-Unpack the files into a directory, and then run bitcoin-qt.exe.
+Unpack the files into a directory, and then run ecash-qt.exe.
 
 ### macOS
 
@@ -97,7 +97,7 @@
 
 ### Miscellaneous
 - [Assets Attribution](assets-attribution.md)
-- [bitcoin.conf Configuration File](bitcoin-conf.md)
+- [ecash.conf Configuration File](ecash-conf.md)
 - [Files](files.md)
 - [Fuzz-testing](fuzzing.md)
 - [Reduce Memory](reduce-memory.md)
diff --git a/doc/README_windows.txt b/doc/README_windows.txt
--- a/doc/README_windows.txt
+++ b/doc/README_windows.txt
@@ -3,7 +3,7 @@
 
 Intro
 -----
-Bitcoin is a free open source peer-to-peer electronic cash system that is
+ECash is a free open source peer-to-peer electronic cash system that is
 completely decentralized, without the need for a central server or trusted
 parties.  Users hold the crypto keys to their own money and transact directly
 with each other, with the help of a P2P network to check for double-spending.
@@ -11,11 +11,11 @@
 
 Setup
 -----
-Unpack the files into a directory and run bitcoin-qt.exe.
+Unpack the files into a directory and run ecash-qt.exe.
 
 Bitcoin ABC is based on Bitcoin Core, which is the original Bitcoin client and
 builds the backbone of the network. It downloads and stores the entire history
-of Bitcoin transactions; depending on the speed of your computer and network
+of eCash transactions; depending on the speed of your computer and network
 connection, the synchronization process can take anywhere from a few hours to
 a day or more.
 
diff --git a/doc/REST-interface.md b/doc/REST-interface.md
--- a/doc/REST-interface.md
+++ b/doc/REST-interface.md
@@ -110,4 +110,4 @@
 
 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:8332/rest/tx/1234567890.json">` which might break the nodes privacy.
+Running a web browser on the same node with a REST enabled ecashd 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:8332/rest/tx/1234567890.json">` which might break the nodes privacy.
diff --git a/doc/assets-attribution.md b/doc/assets-attribution.md
--- a/doc/assets-attribution.md
+++ b/doc/assets-attribution.md
@@ -1 +1 @@
-The list of assets used in the bitcoin source and their attribution can now be found in [contrib/debian/copyright](../contrib/debian/copyright).
+The list of assets used in the ecash source and their attribution can now be found in [contrib/debian/copyright](../contrib/debian/copyright).
diff --git a/doc/benchmarking.md b/doc/benchmarking.md
--- a/doc/benchmarking.md
+++ b/doc/benchmarking.md
@@ -10,7 +10,7 @@
 ---------------------
 The benchmarks can be run with:
 
-    ninja bench-bitcoin
+    ninja ecash-bench
 
 The output will look similar to:
 ```
@@ -25,7 +25,7 @@
 ---------------------
 `-?` will print a list of options and exit:
 
-    src/bench/bitcoin-bench -?
+    src/bench/ecash-bench -?
 
 Notes
 ---------------------
diff --git a/doc/build-osx.md b/doc/build-osx.md
--- a/doc/build-osx.md
+++ b/doc/build-osx.md
@@ -72,15 +72,15 @@
 Running
 -------
 
-Bitcoin ABC is now available at `./src/bitcoind`
+Bitcoin ABC is now available at `./src/ecashd`
 
 Before running, it's recommended that you create an RPC configuration file:
 
-    echo -e "rpcuser=bitcoinrpc\nrpcpassword=$(xxd -l 16 -p /dev/urandom)" > "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
+    echo -e "rpcuser=bitcoinrpc\nrpcpassword=$(xxd -l 16 -p /dev/urandom)" > "/Users/${USER}/Library/Application Support/eCash/ecash.conf"
 
-    chmod 600 "/Users/${USER}/Library/Application Support/Bitcoin/bitcoin.conf"
+    chmod 600 "/Users/${USER}/Library/Application Support/eCash/ecash.conf"
 
-The first time you run bitcoind, it will start downloading the blockchain. This process could take many hours, or even days on slower than average systems.
+The first time you run ecashd, it will start downloading the blockchain. This process could take many hours, or even days on slower than average systems.
 
 You can monitor the download process by looking at the debug.log file:
 
@@ -89,9 +89,9 @@
 Other commands:
 -------
 
-    ./src/bitcoind -daemon # Starts the bitcoin daemon.
-    ./src/bitcoin-cli --help # Outputs a list of command-line options.
-    ./src/bitcoin-cli help # Outputs a list of RPC commands when the daemon is running.
+    ./src/ecashd -daemon # Starts the ecash daemon.
+    ./src/ecash-cli --help # Outputs a list of command-line options.
+    ./src/ecash-cli help # Outputs a list of RPC commands when the daemon is running.
 
 Notes
 -----
diff --git a/doc/build-unix.md b/doc/build-unix.md
--- a/doc/build-unix.md
+++ b/doc/build-unix.md
@@ -17,7 +17,7 @@
 ninja install # optional
 ```
 
-This will build bitcoin-qt as well.
+This will build ecash-qt as well.
 
 Dependencies
 ---------------------
@@ -124,7 +124,7 @@
 Dependencies for the GUI: Ubuntu & Debian
 -----------------------------------------
 
-If you want to build bitcoin-qt, make sure that the required packages for Qt development
+If you want to build ecash-qt, make sure that the required packages for Qt development
 are installed. Qt 5 is necessary to build the GUI.
 To build without GUI pass `-DBUILD_BITCOIN_QT=OFF` on the cmake command line.
 
@@ -160,7 +160,7 @@
 
 Notes
 -----
-The release is built with GCC and then "strip bitcoind" to strip the debug
+The release is built with GCC and then "strip ecashd" to strip the debug
 symbols, which reduces the executable size by about 90%.
 
 
@@ -196,7 +196,7 @@
 
     To test that you have built PIE executable, install scanelf, part of paxutils, and use:
 
-      scanelf -e ./bitcoin
+      scanelf -e ./ecash
 
     The output should contain:
 
@@ -211,7 +211,7 @@
 
     To verify that the stack is non-executable after compiling use:
 
-      scanelf -e ./bitcoin
+      scanelf -e ./ecash
 
     The output should contain:
 
diff --git a/doc/build-windows.md b/doc/build-windows.md
--- a/doc/build-windows.md
+++ b/doc/build-windows.md
@@ -142,7 +142,7 @@
 ---------
 
 <a name="footnote1">1</a>: There is currently a bug in the 64 bit Mingw-w64 cross compiler packaged for WSL/Ubuntu Xenial 16.04 that
-causes two of the bitcoin executables to crash shortly after start up. The bug is related to the
+causes two of the ecash executables to crash shortly after start up. The bug is related to the
 -fstack-protector-all g++ compiler flag which is used to mitigate buffer overflows.
 Installing the Mingw-w64 packages from the Ubuntu 17.10 distribution solves the issue, however, this is not
 an officially supported approach and it's only recommended if you are prepared to reinstall WSL/Ubuntu should
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -312,10 +312,10 @@
 in-tree. Example use:
 
 ```shell
-$ valgrind --suppressions=contrib/valgrind.supp src/test/test_bitcoin
+$ valgrind --suppressions=contrib/valgrind.supp src/test/test_ecash
 $ valgrind --suppressions=contrib/valgrind.supp --leak-check=full \
-      --show-leak-kinds=all src/test/test_bitcoin --log_level=test_suite
-$ valgrind -v --leak-check=full src/bitcoind -printtoconsole
+      --show-leak-kinds=all src/test/test_ecash --log_level=test_suite
+$ valgrind -v --leak-check=full src/ecashd -printtoconsole
 ```
 
 ### Compiling for test coverage
@@ -367,13 +367,13 @@
 trade-offs](https://lwn.net/Articles/420403/) of setting these kernel
 parameters.
 
-To profile a running bitcoind process for 60 seconds, you could use an
+To profile a running ecashd process for 60 seconds, you could use an
 invocation of `perf record` like this:
 
 ```sh
 $ perf record \
     -g --call-graph dwarf --per-thread -F 140 \
-    -p `pgrep bitcoind` -- sleep 60
+    -p `pgrep ecashd` -- sleep 60
 ```
 
 You could then analyze the results by running
@@ -508,8 +508,8 @@
 Threads
 -------
 
-- [Main thread (`bitcoind`)](https://www.bitcoinabc.org/doc/dev/bitcoind_8cpp.html#a0ddf1224851353fc92bfbff6f499fa97)
-  : Started from `main()` in `bitcoind.cpp`. Responsible for starting up and
+- [Main thread (`ecashd`)](https://www.bitcoinabc.org/doc/dev/bitcoind_8cpp.html#a0ddf1224851353fc92bfbff6f499fa97)
+  : Started from `main()` in `ecashd.cpp`. Responsible for starting up and
   shutting down the application.
 
 - [ThreadImport (`b-loadblk`)](https://www.bitcoinabc.org/doc/dev/init_8cpp.html#ae9e290a0e829ec0198518de2eda579d1)
@@ -1002,7 +1002,7 @@
 - Try not to overload methods on argument type. E.g. don't make `getblock(true)` and `getblock("hash")`
   do different things.
 
-  - *Rationale*: This is impossible to use with `bitcoin-cli`, and can be surprising to users.
+  - *Rationale*: This is impossible to use with `ecash-cli`, and can be surprising to users.
 
   - *Exception*: Some RPC calls can take both an `int` and `bool`, most notably when a bool was switched
     to a multi-value, or due to other historical reasons. **Always** have false map to 0 and
@@ -1021,7 +1021,7 @@
 
 - Add every non-string RPC argument `(method, idx, name)` to the table `vRPCConvertParams` in `rpc/client.cpp`.
 
-  - *Rationale*: `bitcoin-cli` and the GUI debug console use this table to determine how to
+  - *Rationale*: `ecash-cli` and the GUI debug console use this table to determine how to
     convert a plaintext command line to JSON. If the types don't match, the method can be unusable
     from there.
 
diff --git a/doc/bitcoin-conf.md b/doc/ecash-conf.md
rename from doc/bitcoin-conf.md
rename to doc/ecash-conf.md
--- a/doc/bitcoin-conf.md
+++ b/doc/ecash-conf.md
@@ -1,6 +1,6 @@
-# `bitcoin.conf` Configuration File
+# `ecash.conf` Configuration File
 
-The configuration file is used by `bitcoind`, `bitcoin-qt` and `bitcoin-cli`.
+The configuration file is used by `ecashd`, `ecash-qt` and `ecash-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.
 
@@ -47,16 +47,16 @@
 
 ## 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 `ecash.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 `includeconf=<file>` option in the `bitcoin.conf` file can be used to include additional configuration files.
+The `includeconf=<file>` option in the `ecash.conf` file can be used to include additional configuration files.
 
 ### Default configuration file locations
 
 Operating System | Data Directory | Example Path
 -- | -- | --
-Windows | `%APPDATA%\Bitcoin\` | `C:\Users\username\AppData\Roaming\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 | `%APPDATA%\eCash\` | `C:\Users\username\AppData\Roaming\eCash\ecash.conf`
+Linux | `$HOME/.ecash/` | `/home/username/.ecash/ecash.conf`
+macOS | `$HOME/Library/Application Support/eCash/` | `/Users/username/Library/Application Support/eCash/eCash.conf`
 
-You can find an example bitcoin.conf file in [contrib/debian/examples/bitcoin.conf](../contrib/debian/examples/bitcoin.conf).
+You can find an example ecash.conf file in [contrib/debian/examples/ecash.conf](../contrib/debian/examples/ecash.conf).
diff --git a/doc/files.md b/doc/files.md
--- a/doc/files.md
+++ b/doc/files.md
@@ -22,13 +22,13 @@
 
 Platform | Data directory path
 ---------|--------------------
-Linux    | `$HOME/.bitcoin/`
-macOS    | `$HOME/Library/Application Support/Bitcoin/`
-Windows  | `%APPDATA%\Bitcoin\` <sup>[\[1\]](#note1)</sup>
+Linux    | `$HOME/.ecash/`
+macOS    | `$HOME/Library/Application Support/eCash/`
+Windows  | `%APPDATA%\eCash\` <sup>[\[1\]](#note1)</sup>
 
 2. The non-default data directory path can be specified by `-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 `ecash.conf` file, is chain-specific. This means the actual data directory paths for non-mainnet cases differ:
 
 Chain option        | Data directory path
 --------------------|--------------------
@@ -50,14 +50,14 @@
 `indexes/blockfilter/basic/`    | `fltrNNNNN.dat`<sup>[\[2\]](#note2)</sup> | Blockfilter index filters for the basic filtertype; *optional*, used if `-blockfilterindex=basic`
 `wallets/`         |                       | [Contains wallets](#multi-wallet-environment); can be specified by `-walletdir` option; if `wallets/` subdirectory does not exist, a wallet resides in the data directory
 `./`               | `banlist.dat`         | Stores the IPs/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
+`./`               | `ecash.conf`          | User-defined [configuration settings](ecash-conf.md) for `ecashd` or `ecash-qt`. File is not written to by the software and must be created manually. Path can be specified by `-conf` option
+`./`               | `ecashd.pid`          | Stores the process ID (PID) of `ecashd` or `ecash-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 `ecashd` or `ecash-qt`; can be specified by `-debuglogfile` option
 `./`               | `guisettings.ini.bak` | Backup of former [GUI settings](#gui-settings) after `-resetguisettings` option is used
 `./`               | `mempool.dat`         | Dump of the mempool's transactions
 `./`               | `onion_v3_private_key` | Cached Tor onion service private key for `-listenonion` option
 `./`               | `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 [ecash.conf](ecash-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
 
@@ -84,7 +84,7 @@
 
 ## GUI settings
 
-`bitcoin-qt` uses [`QSettings`](https://doc.qt.io/qt-5/qsettings.html) class; this implies platform-specific [locations where application settings are stored](https://doc.qt.io/qt-5/qsettings.html#locations-where-application-settings-are-stored).
+`ecash-qt` uses [`QSettings`](https://doc.qt.io/qt-5/qsettings.html) class; this implies platform-specific [locations where application settings are stored](https://doc.qt.io/qt-5/qsettings.html#locations-where-application-settings-are-stored).
 
 ## Legacy subdirectories and files
 
diff --git a/doc/functional-tests.md b/doc/functional-tests.md
--- a/doc/functional-tests.md
+++ b/doc/functional-tests.md
@@ -1,6 +1,6 @@
 # Functional tests
 
-The [/test/](/test/) directory contains integration tests that test bitcoind
+The [/test/](/test/) directory contains integration tests that test ecashd
 and its utilities in their entirety. It does not contain unit tests, which
 can be found in [/src/test](/src/test), [/src/wallet/test](/src/wallet/test),
 etc.
@@ -8,10 +8,10 @@
 There are currently two sets of tests in the [/test/](/test/) directory:
 
 - [functional](/test/functional) which test the functionality of
-bitcoind and bitcoin-qt by interacting with them through the RPC and P2P
+ecashd and ecash-qt by interacting with them through the RPC and P2P
 interfaces.
-- [util](/test/util) which tests the bitcoin utilities, currently only
-bitcoin-tx.
+- [util](/test/util) which tests the ecash utilities, currently only
+ecash-tx.
 
 The util tests are run as part of `make check` target. The functional
 tests are run by the Teamcity continuous build process whenever a diff is
@@ -72,29 +72,29 @@
 
 ##### Resource contention
 
-The P2P and RPC ports used by the bitcoind nodes-under-test are chosen to make
-conflicts with other processes unlikely. However, if there is another bitcoind
+The P2P and RPC ports used by the ecashd nodes-under-test are chosen to make
+conflicts with other processes unlikely. However, if there is another ecashd
 process running on the system (perhaps from a previous test which hasn't successfully
-killed all its bitcoind nodes), then there may be a port conflict which will
+killed all its ecashd nodes), then there may be a port conflict which will
 cause the test to fail. It is recommended that you run the tests on a system
-where no other bitcoind processes are running.
+where no other ecashd processes are running.
 
 On linux, the test_framework will warn if there is another
-bitcoind process running when the tests are started.
+ecashd process running when the tests are started.
 
-If there are zombie bitcoind processes after test failure, you can kill them
+If there are zombie ecashd processes after test failure, you can kill them
 by running the following commands. **Note that these commands will kill all
-bitcoind processes running on the system, so should not be used if any non-test
-bitcoind processes are being run.**
+ecashd processes running on the system, so should not be used if any non-test
+ecashd processes are being run.**
 
 ```bash
-killall bitcoind
+killall ecashd
 ```
 
 or
 
 ```bash
-pkill -9 bitcoind
+pkill -9 ecashd
 ```
 
 ##### Data directory cache
@@ -104,11 +104,11 @@
 test startup times since new blockchains don't need to be generated for
 each test. However, the cache may get into a bad state, in which case
 tests will fail. If this happens, remove the cache directory (and make
-sure bitcoind processes are stopped as above):
+sure ecashd processes are stopped as above):
 
 ```bash
 rm -rf cache
-killall bitcoind
+killall ecashd
 ```
 
 ##### Test logging
@@ -121,13 +121,13 @@
 - When run directly, *all* logs are written to `test_framework.log` and INFO
   level and above are output to the console.
 - When run on Travis, no logs are output to the console. However, if a test
-  fails, the `test_framework.log` and bitcoind `debug.log`s will all be dumped
+  fails, the `test_framework.log` and ecashd `debug.log`s will all be dumped
   to the console to help troubleshooting.
 
 To change the level of logs output to the console, use the `-l` command line
 argument.
 
-`test_framework.log` and bitcoind `debug.log`s can be combined into a single
+`test_framework.log` and ecashd `debug.log`s can be combined into a single
 aggregate log by running the `combine_logs.py` script. The output can be plain
 text, colorized text or html. For example:
 
@@ -154,9 +154,9 @@
 ```
 
 anywhere in the test. You will then be able to inspect variables, as well as
-call methods that interact with the bitcoind nodes-under-test.
+call methods that interact with the ecashd nodes-under-test.
 
-If further introspection of the bitcoind instances themselves becomes
+If further introspection of the ecashd instances themselves becomes
 necessary, this can be accomplished by first setting a pdb breakpoint
 at an appropriate location, running the test to that point, then using
 `gdb` (or `lldb` on macOS) to attach to the process and debug.
@@ -179,13 +179,13 @@
 Use the path to find the pid file in the temp folder:
 
 ```bash
-cat /tmp/user/1000/testo9vsdjo3/node1/regtest/bitcoind.pid
+cat /tmp/user/1000/testo9vsdjo3/node1/regtest/ecashd.pid
 ```
 
 Then you can use the pid to start `gdb`:
 
 ```bash
-gdb /home/example/bitcoind <pid>
+gdb /home/example/ecashd <pid>
 ```
 
 Note: gdb attach step may require `sudo`. To get rid of this, you can run:
@@ -330,10 +330,10 @@
 wrappers for them, `msg_block`, `msg_tx`, etc).
 
 - P2P tests have two threads. One thread handles all network communication
-with the bitcoind(s) being tested in a callback-based event loop; the other
+with the ecashd(s) being tested in a callback-based event loop; the other
 implements the test logic.
 
-- `P2PConnection` is the class used to connect to a bitcoind.  `P2PInterface`
+- `P2PConnection` is the class used to connect to a ecashd.  `P2PInterface`
 contains the higher level logic for processing P2P payloads and connecting to
 the Bitcoin Core node application logic. For custom behaviour, subclass the
 P2PInterface object and override the callback methods.
@@ -363,7 +363,7 @@
 Generally useful functions.
 
 #### [test_framework/p2p.py](/test/functional/test_framework/p2p.py)
-Test objects for interacting with a bitcoind node over the p2p interface.
+Test objects for interacting with a ecashd node over the p2p interface.
 
 #### [test_framework/script.py](/test/functional/test_framework/script.py)
 Utilities for manipulating transaction scripts (originally from python-bitcoinlib)
diff --git a/doc/gitian-building/gitian-building-manual.md b/doc/gitian-building/gitian-building-manual.md
--- a/doc/gitian-building/gitian-building-manual.md
+++ b/doc/gitian-building/gitian-building-manual.md
@@ -5,7 +5,7 @@
 If you are using the automated script, then run it with the `--setup` command. Afterwards, run it with the `--build` command (example: `contrib/gitian-build.py -b signer 0.15.0`). Otherwise ignore this.
 
 Follow the instructions in [https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#fetch-and-create-inputs-first-time-or-when-dependency-versions-change)
-in the bitcoin repository under 'Fetch and create inputs' to install sources which require
+in the ecash repository under 'Fetch and create inputs' to install sources which require
 manual intervention. Also optionally follow the next step: 'Seed the Gitian sources cache
 and offline git repositories' which will fetch the remaining files required for building
 offline.
@@ -14,7 +14,7 @@
 --------------------
 
 To build Bitcoin ABC (for Linux, OS X and Windows) just follow the steps under 'perform
-Gitian builds' in [https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#setup-and-perform-gitian-builds) in the bitcoin repository.
+Gitian builds' in [https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#setup-and-perform-gitian-builds) in the ecash repository.
 
 This may take some time as it will build all the dependencies needed for each descriptor.
 These dependencies will be cached after a successful build to avoid rebuilding them when possible.
@@ -70,7 +70,7 @@
 ----------------------
 
 For building fully offline including attaching signatures to unsigned builds, the detached-sigs repository
-and the bitcoin git repository with the desired tag must both be available locally, and then gbuild must be
+and the ecash git repository with the desired tag must both be available locally, and then gbuild must be
 told where to find them. It also requires an apt-cacher-ng which is fully-populated but set to offline mode, or
 manually disabling gitian-builder's use of apt-get to update the VM build environment.
 
diff --git a/doc/init.md b/doc/init.md
--- 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 ecashd
+========================================================
 
 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/ecashd.service:    systemd service unit configuration
+    contrib/init/ecashd.openrc:     OpenRC compatible SysV style init script
+    contrib/init/ecashd.openrcconf: OpenRC conf.d file
+    contrib/init/ecashd.conf:       Upstart service configuration file
+    contrib/init/ecashd.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 a "ecash" 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 ecashd 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 ecashd as a daemon does not require any manual configuration. You may
+set the `rpcauth` setting in the `ecash.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 ecashd 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 ecashd 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.
@@ -38,13 +38,13 @@
 By default the cookie is stored in the data directory, but it's location can be overridden
 with the option '-rpccookiefile'.
 
-This allows for running bitcoind without having to do any manual configuration.
+This allows for running ecashd 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.
 
 For an example configuration file that describes the configuration settings,
-see `contrib/debian/examples/bitcoin.conf`.
+see `contrib/debian/examples/ecash.conf`.
 
 Paths
 ---------------------------------
@@ -53,24 +53,24 @@
 
 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 `/var/lib/bitcoind/bitcoind.pid` (systemd)\
-Lock file:           `/var/lock/subsys/bitcoind` (CentOS)
+Binary:              `/usr/bin/ecashd`\
+Configuration file:  `/etc/ecash/ecash.conf`\
+Data directory:      `/var/lib/ecashd`\
+PID file:            `/var/run/ecashd/ecashd.pid` (OpenRC and Upstart) or `/var/lib/ecashd/ecashd.pid` (systemd)\
+Lock file:           `/var/lock/subsys/ecashd` (CentOS)
 
 The configuration file, PID directory (if applicable) and data directory
-should all be owned by the bitcoin user and group.  It is advised for security
+should all be owned by the ecash 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
+ecash user and group.  Access to ecash-cli and other ecashd rpc clients
 can then be controlled by group membership.
 
 ### Mac OS X
 
-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/ecashd`\
+Configuration file:  `~/Library/Application Support/eCash/ecash.conf`\
+Data directory:      `~/Library/Application Support/eCash`\
+Lock file:           `~/Library/Application Support/eCash/.lock`
 
 Installing Service Configuration
 -----------------------------------
@@ -81,23 +81,23 @@
 /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 ecashd` and to enable for system startup run
+`systemctl enable ecashd`
 
 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 ecashd.openrc to ecashd 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/ecashd start` and configure it to run on startup with
+`rc-update add ecashd`
 
 ### 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 ecashd.conf in /etc/init.  Test by running `service ecashd start`
 it will automatically start on reboot.
 
 NOTE: This script is incompatible with CentOS 5 and Amazon Linux 2014 as they
@@ -105,22 +105,22 @@
 
 ### CentOS
 
-Copy bitcoind.init to /etc/init.d/bitcoind. Test by running `service bitcoind start`.
+Copy ecashd.init to /etc/init.d/ecashd. Test by running `service ecashd 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 ecashd program by
+setting the ECASHD and FLAGS environment variables in the file
+/etc/sysconfig/ecashd. You can also use the DAEMONOPTS environment variable here.
 
 ### Mac OS X
 
-Copy org.bitcoin.bitcoind.plist into ~/Library/LaunchAgents. Load the launch agent by
-running `launchctl load ~/Library/LaunchAgents/org.bitcoin.bitcoind.plist`.
+Copy org.ecash.ecashd.plist into ~/Library/LaunchAgents. Load the launch agent by
+running `launchctl load ~/Library/LaunchAgents/org.ecash.ecashd.plist`.
 
-This Launch Agent will cause bitcoind to start whenever the user logs in.
+This Launch Agent will cause ecashd 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 ecashd as the current user.
+You will need to modify org.ecash.ecashd.plist if you intend to use it as a
+Launch Daemon with a dedicated ecash user.
 
 Auto-respawn
 -----------------------------------
diff --git a/doc/man/gen-manpages.sh b/doc/man/gen-manpages.sh
--- a/doc/man/gen-manpages.sh
+++ b/doc/man/gen-manpages.sh
@@ -46,8 +46,8 @@
 read -r -a VERSION <<< "$(${BITCOIND} --version | awk -F'[ -]' 'NR == 1 { print $4, $5 }')"
 
 # Create a footer file with copyright content.
-# This gets autodetected fine for bitcoind if --version-string is not set,
-# but has different outcomes for bitcoin-qt and bitcoin-cli.
+# This gets autodetected fine for ecashd if --version-string is not set,
+# but has different outcomes for ecash-qt and ecash-cli.
 FOOTER="$(basename ${BIN})_footer.h2m"
 cleanup() {
   rm -f "${FOOTER}"
diff --git a/doc/psbt.md b/doc/psbt.md
--- a/doc/psbt.md
+++ b/doc/psbt.md
@@ -96,7 +96,7 @@
 Bitcoin ABC. We assume their wallets only contain the multisig funds. In case
 they also have a personal wallet, this can be accomplished through the
 multiwallet feature - possibly resulting in a need to add `-rpcwallet=name` to
-the command line in case `bitcoin-cli` is used.
+the command line in case `ecash-cli` is used.
 
 Setup:
 - All three call `getnewaddress` to create a new address; call these addresses
diff --git a/doc/release-process.md b/doc/release-process.md
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -18,8 +18,8 @@
 
 3. Verify tests passed
     - Run `arc lint --everything` and check there is no linter error
-    - Ensure that bitcoind and bitcoin-qt run with no issue on all supported platforms.
-      Manually test bitcoin-qt by sending some transactions and navigating through the menus.
+    - Ensure that ecashd and ecash-qt run with no issue on all supported platforms.
+      Manually test ecash-qt by sending some transactions and navigating through the menus.
 
 4. Add git tag for release
     a. Create the tag: `git tag vM.m.r` (M = major version, m = minor version, r = revision)
diff --git a/doc/test-shell.md b/doc/test-shell.md
--- a/doc/test-shell.md
+++ b/doc/test-shell.md
@@ -8,7 +8,7 @@
 external interactive environments for prototyping and educational purposes. Just
 like `BitcoinTestFramework`, the `TestShell` allows the user to:
 
-* Manage regtest bitcoind subprocesses.
+* Manage regtest ecashd subprocesses.
 * Access RPC interfaces of the underlying bitcoind instances.
 * Log events to the functional test logging utility.
 
@@ -155,7 +155,7 @@
 underlying `BitcoinTestFramework`:
 
 * `/path/to/bitcoin-abc/test/functional/combine_logs.py
-  '/path/to/bitcoin_func_test_XXXXXXX'`
+  '/path/to/ecash_func_test_XXXXXXX'`
 
 ## 6. Custom `TestShell` parameters
 
@@ -181,7 +181,7 @@
 | `rpc_timeout` | `60` | Sets the RPC server timeout for the underlying bitcoind processes. |
 | `setup_clean_chain` | `False` | Initializes a 200-block-long chain by default. If set to `True`, initialize an empty chain. |
 | `randomseed` | Random Integer | `TestShell.options.randomseed` is a member of `TestShell` which can be accessed during a test to seed a random generator. User can override default with a constant value for reproducible test runs. |
-| `supports_cli` | `False` | Whether the bitcoin-cli utility is compiled and available for the test. |
+| `supports_cli` | `False` | Whether the ecash-cli utility is compiled and available for the test. |
 | `tmpdir` | `"/var/folders/.../"` | Sets directory for test logs. Will be deleted upon a successful test run unless `nocleanup` is set to `True` |
 | `trace_rpc` | `False` | Logs all RPC calls if set to `True`. |
-| `usecli` | `False` | Uses the bitcoin-cli interface for all bitcoind commands instead of directly calling the RPC server. Requires `supports_cli`. |
+| `usecli` | `False` | Uses the ecash-cli interface for all bitcoind commands instead of directly calling the RPC server. Requires `supports_cli`. |
diff --git a/doc/tor.md b/doc/tor.md
--- a/doc/tor.md
+++ b/doc/tor.md
@@ -34,7 +34,7 @@
 
 In a typical situation, this suffices to run behind a Tor proxy:
 
-	./bitcoind -proxy=127.0.0.1:9050
+	./ecashd -proxy=127.0.0.1:9050
 
 
 ## 2. Run a Bitcoin ABC hidden server
@@ -49,9 +49,9 @@
 	HiddenServicePort 18333 127.0.0.1:18333
 
 The directory can be different of course, but (both) port numbers should be equal to
-your bitcoind's P2P listen port (8333 by default).
+your ecashd's P2P listen port (8333 by default).
 
-	-externalip=X   You can tell bitcoin about its publicly reachable address using
+	-externalip=X   You can tell ecash about its publicly reachable address using
 	                this option, and this can be a .onion address. Given the above
 	                configuration, you can find your .onion address in
 	                /var/lib/tor/bitcoin-service/hostname. For connections
@@ -71,25 +71,25 @@
 
 In a typical situation, where you're only reachable via Tor, this should suffice:
 
-	./bitcoind -proxy=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -listen
+	./ecashd -proxy=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.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
+	./ecashd ... -bind=127.0.0.1
 
 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
+	./ecashd ... -discover
 
 and open port 8333 on your firewall (or use -upnp).
 
 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=57qr3yd1nyntf5k.onion -discover
+	./ecashd -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover
 
 ## 3. Automatically listen on Tor
 
@@ -108,13 +108,13 @@
 
 Connecting to Tor's control socket API requires one of two authentication methods to be
 configured. It also requires the control socket to be enabled, e.g. put `ControlPort 9051`
-in `torrc` config file. For cookie authentication the user running bitcoind must have read
+in `torrc` config file. For cookie authentication the user running ecashd must have read
 access to the `CookieAuthFile` specified in Tor configuration. In some cases this is
 preconfigured and the creation of a hidden service is automatic. If permission problems
 are seen with `-debug=tor` they can be resolved by adding both the user running Tor and
-the user running bitcoind to the same group and setting permissions appropriately. On
-Debian-based systems the user running bitcoind can be added to the debian-tor group,
-which has the appropriate permissions. Before starting bitcoind you will need to re-login
+the user running ecashd to the same group and setting permissions appropriately. On
+Debian-based systems the user running ecashd can be added to the debian-tor group,
+which has the appropriate permissions. Before starting ecashd you will need to re-login
 to allow debian-tor group to be applied. Otherwise you will see the following notice: "tor:
 Authentication cookie /run/tor/control.authcookie could not be opened (check permissions)"
 on debug.log.
diff --git a/doc/translation_process.md b/doc/translation_process.md
--- a/doc/translation_process.md
+++ b/doc/translation_process.md
@@ -22,7 +22,7 @@
 make translate
 ```
 
-`contrib/bitcoin-qt.pro` takes care of generating `.qm` (binary compiled) files from `.ts` (source files) files. It’s mostly automated, and you shouldn’t need to worry about it.
+`contrib/ecash-qt.pro` takes care of generating `.qm` (binary compiled) files from `.ts` (source files) files. It’s mostly automated, and you shouldn’t need to worry about it.
 
 **Example Qt translation**
 ```cpp
diff --git a/doc/unit-tests.md b/doc/unit-tests.md
--- a/doc/unit-tests.md
+++ b/doc/unit-tests.md
@@ -4,25 +4,25 @@
 
 All the unit tests can be built and run with a single command: `ninja check`.
 
-#### bitcoind unit tests
+#### ecashd unit tests
 
-The `bitcoind` unit tests can be built with `ninja test_bitcoin`.
+The `ecashd` unit tests can be built with `ninja test_ecash`.
 They can also be built and run in a single command with `ninja check-bitcoin`.
 
-To run the `bitcoind` tests manually, launch `src/test/test_bitcoin`.
+To run the `ecashd` tests manually, launch `src/test/test_ecash`.
 
-To add more `bitcoind` tests, add `BOOST_AUTO_TEST_CASE` functions to the
+To add more `ecashd` tests, add `BOOST_AUTO_TEST_CASE` functions to the
 existing .cpp files in the `src/test/` directory or add new .cpp files that
 implement new `BOOST_AUTO_TEST_SUITE` sections.
 
-#### bitcoin-qt unit tests
+#### ecash-qt unit tests
 
-The `bitcoin-qt` tests can be built with `ninja test_bitcoin-qt` or
-built and run in a single command with `ninja check-bitcoin-qt`.
+The `ecash-qt` tests can be built with `ninja test_ecash-qt` or
+built and run in a single command with `ninja check-ecash-qt`.
 
-To run the `bitcoin-qt` tests manually, launch `src/qt/test/test_bitcoin-qt`.
+To run the `ecash-qt` tests manually, launch `src/qt/test/test_ecash-qt`.
 
-To add more `bitcoin-qt` tests, add them to the `src/qt/test/` directory and
+To add more `ecash-qt` tests, add them to the `src/qt/test/` directory and
 the `src/qt/test/test_main.cpp` file.
 
 #### bitcoin-seeder unit tests
@@ -39,20 +39,20 @@
 
 ### Running individual tests
 
-`test_bitcoin` has some built-in command-line arguments; for
+`test_ecash` has some built-in command-line arguments; for
 example, to run just the `getarg_tests` verbosely:
 
-    test_bitcoin --log_level=all --run_test=getarg_tests
+    test_ecash --log_level=all --run_test=getarg_tests
 
 ... or to run just the doubledash test:
 
-    test_bitcoin --run_test=getarg_tests/doubledash
+    test_ecash --run_test=getarg_tests/doubledash
 
-Run `test_bitcoin --help` for the full list.
+Run `test_ecash --help` for the full list.
 
 ### Adding test cases
 
-The build system is setup to compile an executable called `test_bitcoin`
+The build system is setup to compile an executable called `test_ecash`
 that runs all of the unit tests. The main source file for the test library
 is found in `util/setup_common.cpp`. To add a new unit test file to our
 test suite you need to add the file to `src/test/CMakeLists.txt`.
@@ -72,13 +72,13 @@
 To write to logs from unit tests you need to use specific message methods
 provided by Boost. The simplest is `BOOST_TEST_MESSAGE`.
 
-For debugging you can launch the test_bitcoin executable with `gdb`or `lldb` and
-start debugging, just like you would with bitcoind.
+For debugging you can launch the test_ecash executable with `gdb`or `lldb` and
+start debugging, just like you would with ecashd.
 
 This is a simple example of debugging unit tests with GDB on Linux:
 ```
 cd /build/src/test
-gdb test_bitcoin
+gdb test_ecash
 break interpreter.cpp:295  # No path is necessary, just the file name and line number
 run
 # GDB hits the breakpoint
@@ -89,7 +89,7 @@
 This is a simple example of debugging unit tests with LLDB (OSX or Linux):
 ```
 cd /build/src/test
-lldb -- test_bitcoin
+lldb -- test_ecash
 break set --file interpreter.cpp --line 295
 run
 ```
diff --git a/doc/zmq.md b/doc/zmq.md
--- a/doc/zmq.md
+++ b/doc/zmq.md
@@ -6,7 +6,7 @@
 request/reply, and push/pull.
 
 The Bitcoin ABC daemon can be configured to act as a trusted "border
-router", implementing the bitcoin wire protocol and relay, making
+router", implementing the ecash wire protocol and relay, making
 consensus decisions, maintaining the local blockchain database,
 broadcasting locally generated transactions into the network, and
 providing a queryable RPC interface to interact on a polled basis for
@@ -46,7 +46,7 @@
 ## Enabling
 
 By default, the ZeroMQ feature is automatically compiled.
-To disable, use -DBUILD_BITCOIN_ZMQ=OFF to `cmake` when building bitcoind:
+To disable, use -DBUILD_BITCOIN_ZMQ=OFF to `cmake` when building ecashd:
 
     $ cmake -GNinja .. -DBUILD_BITCOIN_ZMQ=OFF [...]
 
@@ -77,9 +77,9 @@
 
 For instance:
 
-    $ bitcoind -zmqpubhashtx=tcp://127.0.0.1:28332 \
-               -zmqpubrawtx=ipc:///tmp/bitcoind.tx.raw \
-               -zmqpubhashtxhwm=10000
+    $ ecashd -zmqpubhashtx=tcp://127.0.0.1:28332 \
+             -zmqpubrawtx=ipc:///tmp/ecashd.tx.raw \
+             -zmqpubhashtxhwm=10000
 
 Each PUB notification has a topic and body, where the header
 corresponds to the notification type. For instance, for the
@@ -87,7 +87,7 @@
 terminator) and the body is the transaction hash (32
 bytes).
 
-These options can also be provided in bitcoin.conf.
+These options can also be provided in ecash.conf.
 
 ZeroMQ endpoint specifiers for TCP (and others) are documented in the
 [ZeroMQ API](http://api.zeromq.org/4-0:_start).
@@ -99,9 +99,9 @@
 
 ## Remarks
 
-From the perspective of bitcoind, the ZeroMQ socket is write-only; PUB
+From the perspective of ecashd, 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 ecashd 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
@@ -116,5 +116,5 @@
 
 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. ecashd appends an up-counting sequence number to each
 notification which allows listeners to detect lost notifications.