diff --git a/docs/CHANGES.rst b/docs/CHANGES.rst
index 4821a7915e78b7f1199957d12d5d2448d6e0eb2e..561bac2a3c7323bde9e7a20987254b1afa59e88b 100644
--- a/docs/CHANGES.rst
+++ b/docs/CHANGES.rst
@@ -275,7 +275,7 @@ Node
 
 - Added a store metric to expose the number of blocks considered as invalid.
 
-- Fixed the ``tezos-node config reset`` command which did not actually reset
+- Fixed the ``octez-node config reset`` command which did not actually reset
   the configuration file to its default values.
 
 - Added metrics to observe the bootstrapped and synchronisation status.
@@ -310,7 +310,7 @@ Node
   upgraded. To this end, a new storage version was introduced: 1.0
   (previously 0.8). Backward compatibility is preserved: upgrading
   from 0.6, 0.7 (Octez 12.x) or 0.8 (Octez 13.0) is done through the
-  ``tezos-node upgrade storage`` command. This upgrade is
+  ``octez-node upgrade storage`` command. This upgrade is
   instantaneous. However, be careful that there is no forward
   compatibility: previous versions of Octez will refuse to run on an
   upgraded data directory.
@@ -330,7 +330,7 @@ Client
 - Client now allows to simulate failing operations with ``--simulation
   --force``, and report errors without specifying limits.
 
-- Added ``--ignore-case`` option to the ``tezos-client gen vanity keys`` command
+- Added ``--ignore-case`` option to the ``octez-client gen vanity keys`` command
   to allow case-insensitive search for the given pattern.
 
 Proxy Server
@@ -353,7 +353,7 @@ Docker Images
   since version 13.0. It is recommended to write your own docker-compose file instead.
   ``scripts/docker/docker-compose-generic.yml`` is an example of such file.
 
-- ``tezos-codec`` is now included in Docker images.
+- ``octez-codec`` is now included in Docker images.
 
 Rollups
 -------
@@ -416,10 +416,10 @@ Node
   must be used for RPC requests to the node. The value can be ``json``,
   ``binary`` or ``any``. By default, the value is set to ``any``.
 
-- Added an option ``--metrics-addr <ADDR>:<PORT>`` to ``tezos-node`` to
+- Added an option ``--metrics-addr <ADDR>:<PORT>`` to ``octez-node`` to
   expose some metrics using the Prometheus format.
 
-- Added command ``tezos-node storage head-commmit`` which prints the commit hash
+- Added command ``octez-node storage head-commmit`` which prints the commit hash
   of the current context head.
 
 - Added a history mode check when importing a snapshot to ensure the consistency between the
@@ -461,7 +461,7 @@ Node
   limit, and therefore not stored. The re-computed metadata are not
   stored on disk after this call, but rather just returned by the RPC call.
 
-- Added ``--progress-display-mode`` option to the ``tezos-node`` commands
+- Added ``--progress-display-mode`` option to the ``octez-node`` commands
   that display progress animation. This option allows to redirect progress
   animation to non-TTY file descriptors.
 
@@ -494,9 +494,9 @@ Baker
 -----
 
 The following breaking changes affect the Octez v13.0~rc1 baker daemon
-for the Jakarta 2 protocol ``tezos-baker-013-PtJakart``, but **not** the
+for the Jakarta 2 protocol ``octez-baker-013-PtJakart``, but **not** the
 corresponding one for the the Ithaca 2 protocol,
-``tezos-baker-012-Psithaca``.
+``octez-baker-012-Psithaca``.
 
 - **Breaking change**:
   The ``--liquidity-baking-escape-vote`` command-line option has been renamed
@@ -654,14 +654,14 @@ Version 12.0
 Node
 ----
 
-- The tezos-node configuration file parameter
+- The octez-node configuration file parameter
   ``shell.prevalidator.limits.max_refused_operations`` is now
   deprecated and may be removed starting from version 13.0.
 
 - Fixed missing removal of replaced operation in the plugin when another better
   one takes its place (when the mempool is full).
 
-- The output of ``tezos-client get ledger high watermark for <ledger>``
+- The output of ``octez-client get ledger high watermark for <ledger>``
   now also displays the high-water mark for the round, if available.
   Rounds are introduced in Tenderbake.
 
@@ -867,13 +867,13 @@ Node
 - The prevalidator (which handles operations which have been received but not
   yet included in a block) was made more restrictive: it now accepts a single
   manager operation from a given manager for a given block. This limitation
-  was already present implicitly if you were using the ``tezos-client`` commands.
+  was already present implicitly if you were using the ``octez-client`` commands.
   Batches of operations can be used to get around this restriction, see the
   ``multiple transfers`` command to learn more. In addition, operations
   rejected because of this limitation are solely delayed to a future block.
 
 - Removed support for store versions 0.0.4 (used by Octez 9.7) or below.
-  It is no longer possible to run ``tezos-node upgrade storage`` to upgrade
+  It is no longer possible to run ``octez-node upgrade storage`` to upgrade
   from those older versions. It is also no longer possible to import
   snapshots that were exported using this version.
 
@@ -1061,7 +1061,7 @@ Node
 
    - ``shell.block_validator.limits.worker_backlog_level``
 
--  The ``tezos-admin-client show current checkpoint`` command now only
+-  The ``octez-admin-client show current checkpoint`` command now only
    outputs the current checkpoint. It no longer outputs the savepoint,
    caboose and history mode.
 
@@ -1146,9 +1146,9 @@ Node
 Client
 ------
 
--  Disabled indentation checking by default in the ``tezos-client
-   convert script`` and ``tezos-client hash script`` commands. In
-   particular, ``tezos-client convert script <script> from Michelson
+-  Disabled indentation checking by default in the ``octez-client
+   convert script`` and ``octez-client hash script`` commands. In
+   particular, ``octez-client convert script <script> from Michelson
    to Michelson`` can now be used as a Michelson script formatter. To
    force the indentation check, the new ``--enforce-indentation``
    command line switch can be used.
@@ -1166,7 +1166,7 @@ Client
 -  Fix gas simulation for operation batches for Granada, Hangzhou and Alpha
 
 -  Added timestamp display of the snapshot's block target when running
-   the ``tezos-node snapshot info`` command.
+   the ``octez-node snapshot info`` command.
 
 Baker / Endorser / Accuser
 --------------------------
@@ -1230,7 +1230,7 @@ Docker Images
 -------------
 
 -  The ``--force-history-mode-switch`` option is now available for
-   ``tezos-node`` entrypoint. It allows the user to switch the history
+   ``octez-node`` entrypoint. It allows the user to switch the history
    mode of the node's storage.
 
 Version 10.2
@@ -1268,13 +1268,13 @@ Node
    If you were previously using Octez 10.0~rc1 or 10.0~rc2, you were using
    store version 0.0.5. If you were previously using Octez 9.x, you were
    using store version 0.0.4. In both cases, use command
-   ``tezos-node upgrade storage`` to upgrade to 0.0.6.
+   ``octez-node upgrade storage`` to upgrade to 0.0.6.
 
 -  Added an upgrade procedure to upgrade from ``v0.0.5`` to ``v0.0.6``. The
-   procedure is implemented through the ``tezos-node upgrade storage``
+   procedure is implemented through the ``octez-node upgrade storage``
    command.
 
--  Added an ``integrity-check-index`` subcommand to ``tezos-node
+-  Added an ``integrity-check-index`` subcommand to ``octez-node
    storage``, which can be used to check for corruptions (missing
    entries) in the index of the store. This command also accepts an
    optional flag ``--auto-repair`` to fix those specific corruptions
@@ -1341,7 +1341,7 @@ Node
 
 -  Added an upgrade procedure to upgrade from the previous store to the
    new one. The procedure is implemented through the
-   ``tezos-node upgrade storage`` command. This command is
+   ``octez-node upgrade storage`` command. This command is
    non-destructive: the previous store is preserved at
    ``<data_dir>/lmdb_store_to_be_removed`` and needs to be manually
    removed when the user made sure the upgrade process went well.
@@ -1359,12 +1359,12 @@ Node
          suitable for IPFS sharing
 
    -  The argument ``[output_file]`` in
-      ``tezos-node export snapshot [output_file]`` becomes optional and
+      ``octez-node export snapshot [output_file]`` becomes optional and
       defaults to a file whose name follows this pattern
       ``<NETWORK>-<BLOCK_HASH>-<BLOCK_LEVEL>.<SNAPSHOT_HISTORY_MODE>``
    -  Improved the metadata of snapshots which can be displayed using
-      ``tezos-node snapshot info``
-   -  The ``tezos-node snapshot import`` command is retro-compatible
+      ``octez-node snapshot info``
+   -  The ``octez-node snapshot import`` command is retro-compatible
       with the previous snapshot format (v1) but legacy snapshots cannot
       be exported anymore
 
@@ -1378,7 +1378,7 @@ Node
    two modes were maintaining a window of ``<preserved cycles>`` cycles
    of metadata (``5`` on mainnet). These modes may now be configured to
    keep a larger window of metadata. E.g.
-   ``tezos-node run --history-mode full+2`` will maintain 2 extra cycles
+   ``octez-node run --history-mode full+2`` will maintain 2 extra cycles
    of metadata, in addition to the network’s preserved cycles. This may
    become useful for users that want to keep more data from the past:
    for instance, to compute rewards payouts. The default number of extra
@@ -1446,7 +1446,7 @@ Client
    it uses Merkle proofs to make the light mode super safe.
 
 -  Added commands to display the hash of Michelson script from files
-   (``tezos-client hash script``) and from addresses (``tezos-client
+   (``octez-client hash script``) and from addresses (``octez-client
    get contract script hash``).
 
 -  Added support for a new generic version of the multisig contract.
@@ -1477,7 +1477,7 @@ Baker / Endorser / Accuser
 Proxy server
 ------------
 
--  Added a new binary: ``tezos-proxy-server``, a read-only frontend to a node.
+-  Added a new binary: ``octez-proxy-server``, a read-only frontend to a node.
    It is designed to lower the load of nodes, by being capable
    of serving `protocol RPCs <https://tezos.gitlab.io/alpha/rpc.html>`__.
    An instance of a proxy server is protocol-specific: it automatically picks
@@ -1955,7 +1955,7 @@ Node
    significance are detailed in `the user
    documentation <http://tezos.gitlab.io/user/various.html#tezos_binaries_signals_and_exit_codes>`__.
 
--  Command ``tezos-node --version`` now exits with exit code 0 instead
+-  Command ``octez-node --version`` now exits with exit code 0 instead
    of 1.
 
 -  Fixed the synchronisation threshold which was wrongly capped with an
@@ -2031,8 +2031,8 @@ Node
 -  Fixed an issue which prevented using ports higher than 32767 in the
    client configuration file.
 
--  The ``tezos-node run`` command now automatically generates an
-   identity file as if you had run ``tezos-node identity generate`` if
+-  The ``octez-node run`` command now automatically generates an
+   identity file as if you had run ``octez-node identity generate`` if
    its data directory contains no identity file.
 
 -  Improved various log messages and errors.
@@ -2084,7 +2084,7 @@ Node
 -  Improved the performance of the progress indicator when importing
    snapshots.
 
--  Improved performance of ``tezos-node snapshot export``.
+-  Improved performance of ``octez-node snapshot export``.
 
 -  Fixed the node which sent too many “get current branch” messages to
    its peers on testchain activation.
@@ -2093,11 +2093,11 @@ Node
 Client
 ------
 
--  The ``tezos-client config show`` command now takes into account the
+-  The ``octez-client config show`` command now takes into account the
    command line arguments.
 
--  Fixed an issue which caused ``tezos-client rpc get /errors`` as well
-   as ``tezos-codec dump encodings`` to fail because of duplicate
+-  Fixed an issue which caused ``octez-client rpc get /errors`` as well
+   as ``octez-codec dump encodings`` to fail because of duplicate
    encodings. As a result, some protocol encodings whose name was not
    prefixed by the protocol name are now prefixed by it. If you have
    tools which rely on encoding names you may have to update them.
@@ -2116,8 +2116,8 @@ Client
    understand an error from the node.
 
 -  Added client commands
-   ``tezos-client convert script <script> from <input> to <output>`` and
-   ``tezos-client convert data <data> from <input> to <output>`` to
+   ``octez-client convert script <script> from <input> to <output>`` and
+   ``octez-client convert data <data> from <input> to <output>`` to
    convert to and from michelson, JSON, binary and OCaml with
    type-checking.
 
@@ -2195,7 +2195,7 @@ Protocol Compiler And Environment
 Codec
 -----
 
--  Fixed ``tezos-codec dump encodings`` which failed due to two
+-  Fixed ``octez-codec dump encodings`` which failed due to two
    encodings having the same name.
 
 Version 7.5
@@ -2295,14 +2295,14 @@ Multinetwork
 -  Node and client now come with all current and past protocols that are
    still in use on Mainnet or some active test networks.
 
--  Added option ``--network`` to ``tezos-node config init`` to select
+-  Added option ``--network`` to ``octez-node config init`` to select
    which network to connect to from a list of built-in networks (e.g.
    ``carthagenet``). If you do not run ``config init`` or run it without
    the ``--network`` option, the node will use the default network
    (Mainnet).
 
--  Added option ``--network`` to ``tezos-node run`` and
-   ``tezos-node snapshot import`` which causes the node to check that it
+-  Added option ``--network`` to ``octez-node run`` and
+   ``octez-node snapshot import`` which causes the node to check that it
    is configured to use the given network.
 
 -  Added ``network`` configuration field to select which network to
@@ -2419,7 +2419,7 @@ Client
 -  Added protocol command ``expand macros in`` to expand macros in
    Michelson code.
 
--  Added command ``tezos-admin-client protocol environment`` which
+-  Added command ``octez-admin-client protocol environment`` which
    displays the version of the environment used by a given protocol.
 
 -  Greatly reduce the time the client takes to load.
diff --git a/docs/Makefile b/docs/Makefile
index 65f5e091213d36ce7bee80fd6aab0b9ae614a2eb..c4b3c88cad261d47ef1c44b64e1edeb1d1dc3991 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -41,22 +41,22 @@ full: odoc
 	${MAKE} html
 
 # Build the manuals for a given protocol
-%/tezos-client.html:
-	@../tezos-client -protocol $($(@D)_long) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@
-%/tezos-baker.html:
-	@../tezos-baker-$($(@D)_short) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@
-%/tezos-accuser.html:
-	@../tezos-accuser-$($(@D)_short) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@
+%/octez-client.html:
+	@../octez-client -protocol $($(@D)_long) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@
+%/octez-baker.html:
+	@../octez-baker-$($(@D)_short) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@
+%/octez-accuser.html:
+	@../octez-accuser-$($(@D)_short) man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > $@
 
 manuals: \
-	 $(PROTOCOLS:%=%/tezos-client.html) \
-	 $(PROTOCOLS:%=%/tezos-baker.html) \
-	 $(PROTOCOLS:%=%/tezos-accuser.html)
+	 $(PROTOCOLS:%=%/octez-client.html) \
+	 $(PROTOCOLS:%=%/octez-baker.html) \
+	 $(PROTOCOLS:%=%/octez-accuser.html)
 	# generic
-	@../tezos-admin-client man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/tezos-admin-client.html
-	@../tezos-signer man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/tezos-signer.html
-	@../tezos-codec man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/tezos-codec.html
-	@../octez-snoop man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/tezos-snoop.html
+	@../octez-admin-client man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/octez-admin-client.html
+	@../octez-signer man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/octez-signer.html
+	@../octez-codec man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/octez-codec.html
+	@../octez-snoop man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/octez-snoop.html
 
 # artificially depend on docexes to avoid concurrent dunes
 .PHONY: odoc
@@ -120,7 +120,7 @@ docexes:
 	cd .. && dune build docs/$(DOCERRORDIR)/error_doc.exe docs/$(DOCGENDIR)/rpc_doc.exe docs/$(DOCGENDIR)/p2p_doc.exe
 
 developer/metrics.csv:
-	../tezos-node dump-metrics > developer/metrics.csv
+	../octez-node dump-metrics > developer/metrics.csv
 
 $(ERRDOCEXE): docexes
 $(RPCDOCEXE): docexes
diff --git a/docs/alpha/cli-commands.rst b/docs/alpha/cli-commands.rst
index 803e866ca0dc6d8d03a6cb6a087094093036335c..4f0763d90f68bc1ada86966b98ca6946c1202767 100644
--- a/docs/alpha/cli-commands.rst
+++ b/docs/alpha/cli-commands.rst
@@ -8,7 +8,7 @@ using shell commands such as (:ref:`indicating the appropriate protocol <tezos_c
 
 ::
 
-   tezos-client -protocol <protocol_hash> man -verbosity 3
+   octez-client -protocol <protocol_hash> man -verbosity 3
 
 The rest of this page documents the protocol-dependent tools.
 The protocol-independent tools are documented :doc:`here <../shell/cli-commands>`.
@@ -20,7 +20,7 @@ Client manual
 =============
 
 .. raw:: html
-         :file: tezos-client.html
+         :file: octez-client.html
 
 
 .. _baker_manual_alpha:
@@ -29,7 +29,7 @@ Baker manual
 ============
 
 .. raw:: html
-         :file: tezos-baker.html
+         :file: octez-baker.html
 
 
 .. _accuser_manual_alpha:
@@ -38,4 +38,4 @@ Accuser manual
 ==============
 
 .. raw:: html
-         :file: tezos-accuser.html
+         :file: octez-accuser.html
diff --git a/docs/alpha/consensus.rst b/docs/alpha/consensus.rst
index ae465af8ff855d2a9ddc052ab06a173c51248146..0ad1937e27da26f4959fdf3839718cd981f77fba 100644
--- a/docs/alpha/consensus.rst
+++ b/docs/alpha/consensus.rst
@@ -181,8 +181,8 @@ not the other way around.):
 - ``spendable balance`` is obtained with ``../context/contracts/<pkh>/balance``
 
 Delegates can set an upper limit to their frozen deposits with the
-command ``tezos-client set deposits limit for <delegate> to
-<deposit_limit>``, and unset this limit with the command ``tezos-client
+command ``octez-client set deposits limit for <delegate> to
+<deposit_limit>``, and unset this limit with the command ``octez-client
 unset deposits limit for <delegate>``. These commands are implemented
 using a new manager operation ``Set_deposits_limit``. When emitting such a
 command in cycle ``c``, it affects the active stake for cycles starting
diff --git a/docs/alpha/global_constants.rst b/docs/alpha/global_constants.rst
index 9b8286f906b59bdf722aee25834e6c6a0bbeb968..383f3e0e3fd2cb02c4edd2ad17802b5c9464427f 100644
--- a/docs/alpha/global_constants.rst
+++ b/docs/alpha/global_constants.rst
@@ -26,12 +26,12 @@ The new ``register_global_constant`` operation includes an object with a
 single key ``"value"``, the value of which is the Micheline expression
 to be registered.
 
-You can submit this operation conveniently through a new :doc:`tezos-client <cli-commands>` command.
+You can submit this operation conveniently through a new :doc:`octez-client <cli-commands>` command.
 For example, the command:
 
 .. code:: sh
 
-    tezos-client register global constant "999" from bootstrap1 --burn-cap 0.017
+    octez-client register global constant "999" from bootstrap1 --burn-cap 0.017
 
 would result in the output:
 
@@ -44,7 +44,7 @@ would result in the output:
    Operation hash is 'onsFknW5iWa6eiTYqAghY4peQZ7JYQUJg5fR8MwAQkMKjXfNqGf'
    NOT waiting for the operation to be included.
    Use command
-     tezos-client wait for onsFknW5iWa6eiTYqAghY4peQZ7JYQUJg5fR8MwAQkMKjXfNqGf to be included --confirmations 5 --branch BLockGenesisGenesisGenesisGenesisGenesisCCCCCeZiLHU
+     octez-client wait for onsFknW5iWa6eiTYqAghY4peQZ7JYQUJg5fR8MwAQkMKjXfNqGf to be included --confirmations 5 --branch BLockGenesisGenesisGenesisGenesisGenesisCCCCCeZiLHU
    and/or an external block explorer to make sure that it has been included.
    This sequence of operations was run:
      Manager signed operations:
diff --git a/docs/alpha/liquidity_baking.rst b/docs/alpha/liquidity_baking.rst
index 16784faf7a772588b8dbeb745a2b2b881dd92c84..19f4bd704f374d3a38053906bd95fc62db11512d 100644
--- a/docs/alpha/liquidity_baking.rst
+++ b/docs/alpha/liquidity_baking.rst
@@ -62,13 +62,13 @@ non-abstaining blocks, about 1386 blocks if everyone signals, 1963
 blocks if 80% do, 3583 blocks if 60% do etc. Recall for comparison
 that assuming two blocks per minute there are 2880 blocks per day.
 
-When producing blocks using Octez baking daemon ``tezos-baker``, there
+When producing blocks using Octez baking daemon ``octez-baker``, there
 are two command-line options affecting toggle vote. The
 ``--liquidity-baking-toggle-vote <on|off|pass>`` option sets a static
 value to be used in each block. Note that this option must be placed
 **after** ``run`` on the command-line. Moreover, the path of a JSON file
 can be given to the ``--votefile <path>`` option
-e.g. ``tezos-baker-<protocol codename> run with local node
+e.g. ``octez-baker-<protocol codename> run with local node
 ~/.tezos-node alice --liquidity-baking-toggle-vote on --votefile
 "per_block_votes.json"``, or placed in a default location:
 ``per_block_votes.json`` in the current working directory. The content
diff --git a/docs/alpha/plugins.rst b/docs/alpha/plugins.rst
index 4d237151a69ad956f712aeeb4981bb5cf4310db5..c103825ea0a831b6107094e20f1949454b97610c 100644
--- a/docs/alpha/plugins.rst
+++ b/docs/alpha/plugins.rst
@@ -134,11 +134,11 @@ by a factor (currently fixed to 5%). In case of successful replacement, the old
 operation is re-classified as ``Outdated``.
 
 Concretely, a user can replace a successfully prechecked manager operation in the
-mempool, with the help of ``tezos-client``, using two methods :
+mempool, with the help of ``octez-client``, using two methods :
 
 - manually provide a higher fee to bump the "fee/gas limit" ratio by at least 5% for the new
   operation,
-- via option ``--replace``: In this case, ``tezos-client`` will automatically
+- via option ``--replace``: In this case, ``octez-client`` will automatically
   compute the minimal amount of fee for the second operation to be able to
   replace the one in the mempool.
 
@@ -223,9 +223,9 @@ The following parameters can be thus inspected and modified:
 For example, each command below modifies the provided parameter and resets all
 the others to their default values::
 
-   tezos-client rpc post /chains/main/mempool/filter with '{ "minimal_fees": "42" }'
-   tezos-client rpc post /chains/main/mempool/filter with '{ "replace_by_fee_factor": [ "23", "20" ] }'
-   tezos-client rpc post /chains/main/mempool/filter with '{ "max_prechecked_manager_operations": 7500 }'
+   octez-client rpc post /chains/main/mempool/filter with '{ "minimal_fees": "42" }'
+   octez-client rpc post /chains/main/mempool/filter with '{ "replace_by_fee_factor": [ "23", "20" ] }'
+   octez-client rpc post /chains/main/mempool/filter with '{ "max_prechecked_manager_operations": 7500 }'
 
 Changing filters default configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst
index 172417808363ceb4d0ace1adec324d7da78d9bf6..b4a0f3d9b4fee992eceeb5441dea2ee2c93140d6 100644
--- a/docs/alpha/sapling.rst
+++ b/docs/alpha/sapling.rst
@@ -339,7 +339,7 @@ Client
 Wallet
 ^^^^^^
 
-tezos-client supports Sapling keys and can send
+octez-client supports Sapling keys and can send
 shielded transactions to smart contracts.
 
 The client supports two ways to generate a new Sapling spending key.
@@ -483,52 +483,52 @@ unshielding.
 ::
 
    # set up the sandbox
-   ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 0 &
-   eval `./src/bin_client/tezos-init-sandboxed-client.sh 1`
+   ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 &
+   eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
    tezos-activate-alpha
 
    # originate the contract with its initial empty sapling storage,
    # bake a block to include it.
    # { } represents an empty Sapling state.
-   tezos-client originate contract shielded-tez transferring 0 from bootstrap1 \
+   octez-client originate contract shielded-tez transferring 0 from bootstrap1 \
    running src/proto_alpha/lib_protocol/test/integration/michelson/contracts/sapling_contract.tz \
    --init '{ }' --burn-cap 3 &
-   tezos-client bake for bootstrap1
+   octez-client bake for bootstrap1
 
-   # as usual you can check the tezos-client manual
-   tezos-client sapling man
+   # as usual you can check the octez-client manual
+   octez-client sapling man
 
    # generate two shielded keys for Alice and Bob and use them for the shielded-tez contract
    # the memo size has to be indicated
-   tezos-client sapling gen key alice
-   tezos-client sapling use key alice for contract shielded-tez --memo-size 8
-   tezos-client sapling gen key bob
-   tezos-client sapling use key bob for contract shielded-tez --memo-size 8
+   octez-client sapling gen key alice
+   octez-client sapling use key alice for contract shielded-tez --memo-size 8
+   octez-client sapling gen key bob
+   octez-client sapling use key bob for contract shielded-tez --memo-size 8
 
    # generate an address for Alice to receive shielded tokens.
-   tezos-client sapling gen address alice
+   octez-client sapling gen address alice
    zet1AliceXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # Alice's address
 
 
    # shield 10 tez from bootstrap1 to alice
-   tezos-client sapling shield 10 from bootstrap1 to zet1AliceXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez --burn-cap 2 &
-   tezos-client bake for bootstrap1
-   tezos-client sapling get balance for alice in contract shielded-tez
+   octez-client sapling shield 10 from bootstrap1 to zet1AliceXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez --burn-cap 2 &
+   octez-client bake for bootstrap1
+   octez-client sapling get balance for alice in contract shielded-tez
 
    # generate an address for Bob to receive shielded tokens.
-   tezos-client sapling gen address bob
+   octez-client sapling gen address bob
    zet1BobXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # Bob's address
 
    # forge a shielded transaction from alice to bob that is saved to a file
-   tezos-client sapling forge transaction 10 from alice to zet1BobXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez
+   octez-client sapling forge transaction 10 from alice to zet1BobXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez
 
    # submit the shielded transaction from any transparent account
-   tezos-client sapling submit sapling_transaction from bootstrap2 using shielded-tez --burn-cap 1 &
-   tezos-client bake for bootstrap1
-   tezos-client sapling get balance for bob in contract shielded-tez
+   octez-client sapling submit sapling_transaction from bootstrap2 using shielded-tez --burn-cap 1 &
+   octez-client bake for bootstrap1
+   octez-client sapling get balance for bob in contract shielded-tez
 
    # unshield from bob to any transparent account
-   tezos-client sapling unshield 10 from bob to bootstrap1 using shielded-tez --burn-cap 1
+   octez-client sapling unshield 10 from bob to bootstrap1 using shielded-tez --burn-cap 1
    ctrl+z # to put the process in background
-   tezos-client bake for bootstrap1
+   octez-client bake for bootstrap1
    fg # to put resume the transfer
diff --git a/docs/alpha/transaction_rollups.rst b/docs/alpha/transaction_rollups.rst
index 76762e7a2ddbfdbf2850c4503a0670755de007a7..3bc2278b5d0221c55b0793a8c86d6bb4d7967db9 100644
--- a/docs/alpha/transaction_rollups.rst
+++ b/docs/alpha/transaction_rollups.rst
@@ -532,12 +532,12 @@ Getting Started
 Originating a Transaction Rollup
 ********************************
 
-The ``tezos-client`` has a dedicated command that any implicit account holder
+The ``octez-client`` has a dedicated command that any implicit account holder
 can use to originate a transaction rollup.
 
 .. code:: sh
 
-    tezos-client originate tx rollup ${tx_rollup_allias} from ${implicit_account_alias}
+    octez-client originate tx rollup ${tx_rollup_allias} from ${implicit_account_alias}
 
 where ``tx`` is an abbreviation for transaction.
 
@@ -552,7 +552,7 @@ prefixed by ``txr1``. For instance,::
 
 is a valid transaction rollup address.
 
-When using the ``tezos-client`` to originate a transaction rollup, it outputs
+When using the ``octez-client`` to originate a transaction rollup, it outputs
 the newly created address.
 
 Starting a Rollup Node
@@ -748,7 +748,7 @@ the deposit.
 
 .. code:: sh
 
-    tezos-client originate contract ${contract_alias} \
+    octez-client originate contract ${contract_alias} \
                  transferring 0 \
                  from ${alias} \
                  running ${path_to_contract} \
@@ -757,23 +757,23 @@ the deposit.
 Once the contract is originated, it becomes possible to deposit
 arbitrary tickets to the layer-2.
 
-Note that the ``tezos-client`` comes with facilities to generate and
+Note that the ``octez-client`` comes with facilities to generate and
 manipulate BLS keys (that are used to authenticate users on the
 layer-2, and to generate layer-2 addresses).
 
 .. code:: sh
 
     # generate a pair of public and secret keys
-    tezos-client bls gen keys ${alias}
+    octez-client bls gen keys ${alias}
     # display the keys (including the ``tz4`` hash)
-    tezos-client bls show address ${alias}
+    octez-client bls show address ${alias}
 
 So, to mint and deposit a ``ticket string`` whose contents is
 ``foobar``, one can make the following contract call.
 
 .. code:: sh
 
-    tezos-client transfer 0 from user to deposit_contract \
+    octez-client transfer 0 from user to deposit_contract \
              --arg '(Pair "foobar" ${qty} "${tz4_address}" "${tx_rollup_address}")' \
              --burn-cap 0.068
 
@@ -845,7 +845,7 @@ The ``--endpoint`` argument can be omitted if the rollup node is using
 the default RPC server address, that is ``localhost:9999``.
 
 Here, the source has to be an alias identifying a BLS pair of keys
-generated with ``tezos-client bls gen key``, while the destination can
+generated with ``octez-client bls gen key``, while the destination can
 either be an alias, or a ``tz4`` address directly.
 
 Similarly to Tezos, a transaction rollup also has a notion of L2
@@ -873,7 +873,7 @@ implicit account address directly.
 If a rollup node is run using the mode ``operator``, then once the
 commitment related to a withdraw order is finalized, the rollup node
 will “dispatch” the ticket to the ``l1_dst`` address. Once this is
-done, the owner of ``l1_dst`` can use a dedicated ``tezos-client``
+done, the owner of ``l1_dst`` can use a dedicated ``octez-client``
 command to transfer their tickets to a smart contract.
 
 To do so, it is necessary to provide the layer-1 with the actual
@@ -881,7 +881,7 @@ contents of the ticket, not just the ticket hash.
 
 .. code:: sh
 
-    tezos-client transfer ${qty} tickets \
+    octez-client transfer ${qty} tickets \
           from ${src} to ${sc_dst} \
           with entrypoint ${ep} \
           and contents ${micheline_contents} \
diff --git a/docs/alpha/voting.rst b/docs/alpha/voting.rst
index 3d4dc8cf44af42fe2d048a2bf5ba0d1e05030a2c..888bace2e1cb92455a3c39e0f613e9bfd6472bf9 100644
--- a/docs/alpha/voting.rst
+++ b/docs/alpha/voting.rst
@@ -246,12 +246,12 @@ quorum of the next vote.
 More details on the operations can be found in
 :src:`src/proto_alpha/lib_protocol/operation_repr.ml`.
 The binary format is described by
-``tezos-client describe unsigned operation``.
+``octez-client describe unsigned operation``.
 
 Client Commands
 ---------------
 
-The Octez client, ``tezos-client``, provides commands for basic exploration and
+The Octez client, ``octez-client``, provides commands for basic exploration and
 interaction with the amendment and voting process.
 
 
@@ -262,13 +262,13 @@ Tezos' client provides a command to show the status of a voting period.
 It displays different information for different kind of periods, as
 in the following samples::
 
-  $ tezos-client show voting period
+  $ octez-client show voting period
   Current period: "proposal"
   Blocks remaining until end of period: 59
   Current proposals:
   PsNa6jTtsRfbGaNSoYXNTNM5A7c3Lji22Yf2ZhpFUjQFC17iZVp 2,400,000 ꜩ
 
-  $ tezos-client show voting period
+  $ octez-client show voting period
   Current period: "exploration"
   Blocks remaining until end of period: 63
   Current proposal: PsNa6jTtsRfbGaNSoYXNTNM5A7c3Lji22Yf2ZhpFUjQFC17iZVp
@@ -279,7 +279,7 @@ in the following samples::
   Current participation 20.00%, necessary quorum 80.00%
   Current in favor 2,400,000 ꜩ, needed supermajority 1,920,000 ꜩ
 
-  $ tezos-client show voting period
+  $ octez-client show voting period
   Current period: "cooldown"
   Blocks remaining until end of period: 64
   Current proposal: PsNa6jTtsRfbGaNSoYXNTNM5A7c3Lji22Yf2ZhpFUjQFC17iZVp
@@ -296,7 +296,7 @@ Submit proposals
 
 During a proposal period, a list of proposals can be submitted with::
 
-    tezos-client submit proposals for <delegate> <proposal1> <proposal2> ...
+    octez-client submit proposals for <delegate> <proposal1> <proposal2> ...
 
 Remember that each delegate can submit a maximum of 20 protocol
 hashes and that duplicates count towards this total.
@@ -323,7 +323,7 @@ Submit ballots
 During either of the **exploration** or **promotion** periods,
 ballots can be submitted once with::
 
-    tezos-client submit ballot for <delegate> <proposal> <yay|nay|pass>
+    octez-client submit ballot for <delegate> <proposal> <yay|nay|pass>
 
 Further External Resources
 --------------------------
diff --git a/docs/api/kathmandu-mempool-openapi.json b/docs/api/kathmandu-mempool-openapi.json
index 311b89a0dd0d8ee51e40febd9dfd18f5a37526da..371a2a0043ec561e08574df45437c900bfc55d3e 100644
--- a/docs/api/kathmandu-mempool-openapi.json
+++ b/docs/api/kathmandu-mempool-openapi.json
@@ -81,7 +81,7 @@
         }
       },
       "post": {
-        "description": "Set the configuration of the mempool filter. **If any of the fields is absent from the input JSON, then it is set to the default value for this field (i.e. its value in the default configuration), even if it previously had a different value.** If the input JSON does not describe a valid configuration, then the configuration is left unchanged. Also return the new configuration (which may differ from the input if it had omitted fields or was invalid). You may call [./tezos-client rpc get '/chains/main/mempool/filter?include_default=true'] to see an example of JSON describing a valid configuration.",
+        "description": "Set the configuration of the mempool filter. **If any of the fields is absent from the input JSON, then it is set to the default value for this field (i.e. its value in the default configuration), even if it previously had a different value.** If the input JSON does not describe a valid configuration, then the configuration is left unchanged. Also return the new configuration (which may differ from the input if it had omitted fields or was invalid). You may call [./octez-client rpc get '/chains/main/mempool/filter?include_default=true'] to see an example of JSON describing a valid configuration.",
         "requestBody": {
           "content": {
             "application/json": {
diff --git a/docs/api/rpc-openapi.json b/docs/api/rpc-openapi.json
index a013c64ca2290d53758f1d4d45d33629fca72c30..45ab378a09cdfb970ae88afba297b9959834ac47 100644
--- a/docs/api/rpc-openapi.json
+++ b/docs/api/rpc-openapi.json
@@ -1031,7 +1031,7 @@
                           ]
                         },
                         "rules": {
-                          "description": "Fine-grained logging instructions. Same format as described in `tezos-node run --help`, DEBUG section. In the example below, sections 'p2p' and all sections starting by 'client' will have their messages logged up to the debug level, whereas the rest of log sections will be logged up to the notice level.",
+                          "description": "Fine-grained logging instructions. Same format as described in `octez-node run --help`, DEBUG section. In the example below, sections 'p2p' and all sections starting by 'client' will have their messages logged up to the debug level, whereas the rest of log sections will be logged up to the notice level.",
                           "oneOf": [
                             {
                               "$ref": "#/components/schemas/unistring"
diff --git a/docs/developer/clic.rst b/docs/developer/clic.rst
index 2011cf291d5a7d308b4156e0904fed5c332b4fac..1c73377289233d4adf30e275af2ad73b3a485537 100644
--- a/docs/developer/clic.rst
+++ b/docs/developer/clic.rst
@@ -6,23 +6,23 @@ self-documenting command-line argument parsers. Clic is similar to
 `cmdliner <https://erratique.ch/software/cmdliner>`__, but (unlike cmdliner)
 ``tezos-clic`` allows to define a domain-specific
 language as a subset of a natural language, by mixing keyword and
-positional arguments. For example, in ``tezos-client``, commands look
+positional arguments. For example, in ``octez-client``, commands look
 like this, thanks to ``tezos-clic``:
 
 .. code-block::
 
-    tezos-client list understood protocols
-    tezos-client compute chain id from block hash <hash>
-    tezos-client originate contract <contract_alias> transferring <initial_balance> from <originator> running <script>
+    octez-client list understood protocols
+    octez-client compute chain id from block hash <hash>
+    octez-client originate contract <contract_alias> transferring <initial_balance> from <originator> running <script>
 
 
 ``clic`` is used for most of the binaries distributed with Octez, such
-as ``tezos-client`` and ``tezos-codec``. A notable exception is
-``tezos-node`` which uses ``cmdliner``.
+as ``octez-client`` and ``octez-codec``. A notable exception is
+``octez-node`` which uses ``cmdliner``.
 
 In this tutorial, we will give a gentle introduction to ``clic`` by
 demonstrating how to implement a wallet command inspired by those of
-``tezos-client``. Impatient readers will find the full example
+``octez-client``. Impatient readers will find the full example
 :src:`in this file<src/lib_clic/examples/clic_example.ml>`.
 
 Wallet example
@@ -30,9 +30,9 @@ Wallet example
 
 Command-line parsing in ``clic`` is centered around *commands*. A command
 roughly corresponds to one action of the command-line application. For
-instance, ``tezos-client get balance`` and ``tezos-client run script
+instance, ``octez-client get balance`` and ``octez-client run script
 <script>`` are two different commands.
-To demonstrate the use of ``clic``, we will add the following command to a dummy tezos-client: ``list
+To demonstrate the use of ``clic``, we will add the following command to a dummy octez-client: ``list
 known contracts``. As the name indicates, this command outputs
 the contracts known to the wallet.
 
@@ -85,7 +85,7 @@ Commands are defined through the ``Tezos_clic.command`` function. It has the fol
 First, commands have a group and description that are used to
 generate documentation.
 Groups are used to organize commands of related functionality. This is
-convenient for applications such as ``tezos-client`` that defines a
+convenient for applications such as ``octez-client`` that defines a
 large number of commands which are grouped on themes such as
 querying, testing, and address management. You can see the documentation
 :ref:`online <client_manual_alpha>`.
@@ -107,10 +107,10 @@ value of type ``'b``.
 The command is specified through a sequence of *params*, given as the
 fourth argument to ``Tezos_clic.command``. Params can be *prefixes*: fixed
 strings that must be given when calling the command. Above, we
-mentioned the ``get balance`` command of ``tezos-client``. The
+mentioned the ``get balance`` command of ``octez-client``. The
 sequence ``get balance`` is an example of such a prefix. A param can
 also define a *hole* to be filled by the user on the command line. An example is given by
-``tezos-client get balance for <contract>``. Here, the command
+``octez-client get balance for <contract>``. Here, the command
 consists of a sequence of prefixes ``get balance for`` followed by the
 hole ``<contract>``, filled by the user on the command-line. No matter how the params
 specification is constructed, it is terminated by the combinator ``Tezos_clic.stop``.
diff --git a/docs/developer/contributing.rst b/docs/developer/contributing.rst
index a9031db248de51b37daabb5b7abb556f8a56e1f5..d44b161690a9d8e8330fd71580d59b83ccf0f9bc 100644
--- a/docs/developer/contributing.rst
+++ b/docs/developer/contributing.rst
@@ -22,7 +22,7 @@ to search the existing issues before reporting a new one.
 Some information that are probably important to include in the description:
 the architecture (e.g. *ARM64*), the operating system (e.g. *Debian
 Stretch*), the network you are connected to (e.g. *Carthagenet*), the
-binary or component (e.g. *tezos-node crashes* or *rpc X returns Y
+binary or component (e.g. *octez-node crashes* or *rpc X returns Y
 while Z was expected*).
 
 Fixing typos
diff --git a/docs/developer/encodings.rst b/docs/developer/encodings.rst
index 94f42d65c8dd9f165d7213c61fa1d386df5c948b..e7c773d44eaa861cdde115fc024b8e76a5494b13 100644
--- a/docs/developer/encodings.rst
+++ b/docs/developer/encodings.rst
@@ -11,35 +11,35 @@ Tools
 
 For performing serialization/deserialization of data structures into binary form within OCaml code, refer to the documentation of the :doc:`data encoding library <data_encoding>`.
 
-For studying and understanding all the different encodings, the definitive source of truth is the ``tezos-codec`` tool.
+For studying and understanding all the different encodings, the definitive source of truth is the ``octez-codec`` tool.
 It is a command-line tool allowing users and developers to:
 
 - describe the binary and JSON encoding schemas for all the supported data structures (see :ref:`codec_describe`)
 - encode and decode data into/from binary or JSON form, using a specific encoding (see :ref:`codec_encode`)
 
-You may refer to the ``tezos-codec`` :ref:`online manual <codec_manual>` for more details.
+You may refer to the ``octez-codec`` :ref:`online manual <codec_manual>` for more details.
 The rest of this page gives a gentle introduction to this tool by showing on some examples how to perform the two tasks above.
 
-Note that for the particular case of Micheline expressions, the ``tezos-client`` tool can also be used to convert between several data representations, covering not only the binary and JSON representations, but also OCaml and Michelson notations (see :ref:`client_convert`).
+Note that for the particular case of Micheline expressions, the ``octez-client`` tool can also be used to convert between several data representations, covering not only the binary and JSON representations, but also OCaml and Michelson notations (see :ref:`client_convert`).
 
 .. _codec_describe:
 
-How to read the output of ``tezos-codec``
+How to read the output of ``octez-codec``
 -----------------------------------------
 
 The list of data structures that can be encoded/decoded may be obtained as follows::
 
-  $ tezos-codec list encodings
+  $ octez-codec list encodings
 
 The binary encoding of any supported data structure can be described using the following command::
 
-  $ tezos-codec describe <id> binary schema
+  $ octez-codec describe <id> binary schema
 
 Similarly, the JSON encoding of any supported data structure can be described using the following command::
 
-  $ tezos-codec describe <id> json schema
+  $ octez-codec describe <id> json schema
 
-However, the output of the above commands is rather verbose, so here is a short introduction for how to read the schemas produced by ``tezos-codec``.
+However, the output of the above commands is rather verbose, so here is a short introduction for how to read the schemas produced by ``octez-codec``.
 
 JSON schemas
 ~~~~~~~~~~~~
@@ -47,7 +47,7 @@ JSON schemas
 The descriptions of JSON schemas are rather self-explaining.
 For instance, the encoding of a Micheline expression is done according to a few simple :ref:`JSON encoding principles <micheline_json>`, that can be retrieved by doing::
 
-  $ tezos-codec describe alpha.script.expr json schema
+  $ octez-codec describe alpha.script.expr json schema
 
 The schema output by this command is as follows (slightly abbreviated and reformatted for better readability):
 
@@ -99,7 +99,7 @@ The descriptions of binary schemas are more complex to some extent, mainly for t
 
 To illustrate these differences, let us consider the same example as above, that of a Micheline expression::
 
-  $ tezos-codec describe alpha.script.expr binary schema
+  $ octez-codec describe alpha.script.expr binary schema
 
 The binary schema produced by this command is as follows (abbreviated and reformatted for better readability)::
 
@@ -197,7 +197,7 @@ For instance:
 How to encode/decode values
 ---------------------------
 
-Beyond examining the various available encodings, the ``tezos-codec`` tool can also be used to encode and decode data.
+Beyond examining the various available encodings, the ``octez-codec`` tool can also be used to encode and decode data.
 This can be useful for developers when debugging, but also for end users when trying to understand the contents of a block or transaction, for instance.
 
 Let us consider a few examples of encoding and decoding some commonly used types.
@@ -207,7 +207,7 @@ Strings
 
 To encode a string as a Micheline expression, proceed as follows::
 
-  $ tezos-codec encode alpha.script.expr from '{"string":"Hello world!"}'
+  $ octez-codec encode alpha.script.expr from '{"string":"Hello world!"}'
   010000000c48656c6c6f20776f726c6421
 
 As can be seen, strings are serialized as follows:
@@ -218,7 +218,7 @@ As can be seen, strings are serialized as follows:
 
 The same tool can be used in the other direction, to decode a byte sequence representing a serialized string expression::
 
-  $ tezos-codec decode alpha.script.expr from '010000000c48656c6c6f20776f726c6421'
+  $ octez-codec decode alpha.script.expr from '010000000c48656c6c6f20776f726c6421'
   { "string": "Hello world!" }
 
 Integers
@@ -232,7 +232,7 @@ There are various encoding for integers, including:
 
 which can be detailed by describing their schemas, e.g.::
 
-  $ tezos-codec describe ground.Z binary schema
+  $ octez-codec describe ground.Z binary schema
   ...
   A variable length sequence of bytes, encoding a Zarith number. Each byte has
   a running unary size bit: the most significant bit of each byte tells is this
@@ -243,7 +243,7 @@ which can be detailed by describing their schemas, e.g.::
 
 To illustrate the Zarith representation, let us encode the Micheline representation of the number ``1,000,000`` (one million)::
 
-  $ tezos-codec encode alpha.script.expr from '{"int":"1000000"}'
+  $ octez-codec encode alpha.script.expr from '{"int":"1000000"}'
   0080897a
 
 Here:
@@ -265,7 +265,7 @@ Pairs
 
 Let us see how an OCaml pair is encoded::
 
-  $ tezos-codec encode alpha.script.expr from '{"prim":"Pair","args":[{"int":"1"},{"int":"2"}]}'
+  $ octez-codec encode alpha.script.expr from '{"prim":"Pair","args":[{"int":"1"},{"int":"2"}]}'
   070700010002
 
 Here:
@@ -277,7 +277,7 @@ Here:
 
 Let's try another example, the encoding of the value ``Left 1`` of type ``or nat bool``::
 
-  $ tezos-codec encode alpha.script.expr from '{"prim":"Left","args":[{"int":"1"}]}'
+  $ octez-codec encode alpha.script.expr from '{"prim":"Left","args":[{"int":"1"}]}'
   05050001
 
 Here:
@@ -293,7 +293,7 @@ Finally, let us consider a more complex example.
 Assume that we try to understand an operation included in a block.
 We can decode the binary string as follows::
 
-  $ tezos-codec decode alpha.operation from '008f1d96e2783258ff663f03dacfe946c026a5d194c73d1987b3da73fadea7d46c008cb5baedee4dc3ec261dfcf57a9600bb0a8e26c0f00bdd85a0018452ac02e0a712000153957451d3cc83a71e26b65ea2391a1b16713d2d009595facf847a72b4c3fe231c0e4185e68e9b2875aa3c639382c86bcf0af23699f47fe66a6550ade936a5b59d5919ad20703885750314e0c368b277de39e7d10a'
+  $ octez-codec decode alpha.operation from '008f1d96e2783258ff663f03dacfe946c026a5d194c73d1987b3da73fadea7d46c008cb5baedee4dc3ec261dfcf57a9600bb0a8e26c0f00bdd85a0018452ac02e0a712000153957451d3cc83a71e26b65ea2391a1b16713d2d009595facf847a72b4c3fe231c0e4185e68e9b2875aa3c639382c86bcf0af23699f47fe66a6550ade936a5b59d5919ad20703885750314e0c368b277de39e7d10a'
   { "branch": "BKiXcfN1ZTXnNNbTWSRArSWzVFc6om7radWq5mTqGX6rY4P2Uhe",
     "contents":
       [ { "kind": "transaction",
@@ -306,7 +306,7 @@ We can decode the binary string as follows::
 
 In order to understand how the transaction has been decoded from the binary sequence, we have to examine the encoding schema of a block operation::
 
-  $ tezos-codec describe alpha.operation binary schema
+  $ octez-codec describe alpha.operation binary schema
   +-----------+----------+---------------------------------------------+
   | Name      | Size     | Contents                                    |
   +===========+==========+=============================================+
@@ -374,27 +374,27 @@ Using the above information, the sample binary sequence can be broken down as fo
   = 0x9595facf847a72b4c3fe231c0e4185e68e9b2875aa3c639382c86bcf0af23699f47fe66a6550ade936a5b59d5919ad20703885750314e0c368b277de39e7d10a
   = sighZMqWz5G8drK1VTsmTnQBFEQ9kxQQxL88NFh8UaqDEJ3R3mzgR3g81azadZ9saPwsWga3kEPsyfbzrXm6ueuDvx3pQ5Q9
 
-As usual, ``tezos-codec`` can be used the other way around, to encode the same transaction::
+As usual, ``octez-codec`` can be used the other way around, to encode the same transaction::
 
-  $ tezos-codec encode alpha.operation from '{ "branch": "BKiXcfN1ZTXnNNbTWSRArSWzVFc6om7radWq5mTqGX6rY4P2Uhe", "contents": [ { "kind": "transaction", "source": "tz1YU2zoyCkXPKEA4jknSpCpMs7yUndVNe3S", "fee": "1520", "counter": "2622173", "gas_limit": "10500", "storage_limit": "300", "amount": "300000", "destination": "tz2FwBnXhuXvPAUcr1aF3uX84Z6JELxrdYxD" } ], "signature": "sighZMqWz5G8drK1VTsmTnQBFEQ9kxQQxL88NFh8UaqDEJ3R3mzgR3g81azadZ9saPwsWga3kEPsyfbzrXm6ueuDvx3pQ5Q9" }'
+  $ octez-codec encode alpha.operation from '{ "branch": "BKiXcfN1ZTXnNNbTWSRArSWzVFc6om7radWq5mTqGX6rY4P2Uhe", "contents": [ { "kind": "transaction", "source": "tz1YU2zoyCkXPKEA4jknSpCpMs7yUndVNe3S", "fee": "1520", "counter": "2622173", "gas_limit": "10500", "storage_limit": "300", "amount": "300000", "destination": "tz2FwBnXhuXvPAUcr1aF3uX84Z6JELxrdYxD" } ], "signature": "sighZMqWz5G8drK1VTsmTnQBFEQ9kxQQxL88NFh8UaqDEJ3R3mzgR3g81azadZ9saPwsWga3kEPsyfbzrXm6ueuDvx3pQ5Q9" }'
 
 .. COMMENT:
   We could also very well publish encodings, as this has proved useful to guiding developers in the past.
 
 .. _client_convert:
 
-How to convert Micheline with ``tezos-client``
+How to convert Micheline with ``octez-client``
 ----------------------------------------------
 
-The ``tezos-client`` can be used to convert Micheline expressions between the following forms: binary, JSON, Michelson, and OCaml.
+The ``octez-client`` can be used to convert Micheline expressions between the following forms: binary, JSON, Michelson, and OCaml.
 
 Note that the client has to be run in conjunction to a running node for the following commands to work (unless option ``--protocol`` is specified)::
 
-  $ tezos-client convert data '(Pair 1 2)' from michelson to binary
+  $ octez-client convert data '(Pair 1 2)' from michelson to binary
   0x070700010002
-  $ tezos-client convert data 0x070700010002 from binary to michelson
+  $ octez-client convert data 0x070700010002 from binary to michelson
   (Pair 1 2)
-  $ tezos-client convert data 0x070700010002 from binary to json
+  $ octez-client convert data 0x070700010002 from binary to json
   { "prim": "Pair", "args": [ { "int": "1" }, { "int": "2" } ] }
-  $ tezos-client convert data 0x070700010002 from binary to ocaml
+  $ octez-client convert data 0x070700010002 from binary to ocaml
   Prim (0, D_Pair, [Int (1, Z.one); Int (2, Z.of_int 2)], [])
diff --git a/docs/developer/long-tezts.rst b/docs/developer/long-tezts.rst
index c4f078156a5a87d610183b15c91a2a14e3a05d57..ffe33651e6530c5b10785a4ea589101c31582f89 100644
--- a/docs/developer/long-tezts.rst
+++ b/docs/developer/long-tezts.rst
@@ -108,7 +108,7 @@ Example
 -------
 
 See :src:`tezt/long_tests/prt_client.ml`, which is a very simple test
-that measures how long it takes for ``tezos-client`` to load.  It uses
+that measures how long it takes for ``octez-client`` to load.  It uses
 ``Long_test.time_lwt`` to measure how long it takes for
 ``Client.version`` to run and to emit alerts if this time is
 significantly higher than usual. It also defines a graph of this time.
diff --git a/docs/developer/openmetrics.rst b/docs/developer/openmetrics.rst
index ee69ad4859d301080ff00832999fe7c02381c0ba..f5567f5239ce1d603ac218b7500871ebed705fe3 100644
--- a/docs/developer/openmetrics.rst
+++ b/docs/developer/openmetrics.rst
@@ -35,7 +35,7 @@ The address defaults to localhost.
 When the option is not supplied at all, no metrics are produced.
 Ex.::
 
-  tezos-node run --metrics-addr=:9091
+  octez-node run --metrics-addr=:9091
 
 To query the open metrics server the user can simply query the node.
 
diff --git a/docs/developer/profiling.rst b/docs/developer/profiling.rst
index 612377f2de12f7c4be01bb276fbe358f5e83e418..5a1fb47f57f3b623ae988e0d472d08bb0bc65a99 100644
--- a/docs/developer/profiling.rst
+++ b/docs/developer/profiling.rst
@@ -38,7 +38,7 @@ Memory profiling the OCaml heap
 ::
 
     M-x sturgeon-connect
-    tezos-nodememprof.1234.sturgeon
+    octez-nodememprof.1234.sturgeon
 
   (tab-completion works for finding the socket name)
 
@@ -49,7 +49,7 @@ Memory profiling the C heap
 
 ::
 
-    valgrind --tool=massif tezos-node run ...
+    valgrind --tool=massif octez-node run ...
 
 - Stop with `Ctrl-C` then display with
 
@@ -78,7 +78,7 @@ Performance profiling
      the ``--call-stack dwarf`` to get something more manageable, but
      interpreting the information can be harder.
 
-   - Let `perf` run ``tezos-node``: ``perf record -g -F 99 --call-graph=dwarf -- ./tezos-node run ...``
+   - Let `perf` run ``octez-node``: ``perf record -g -F 99 --call-graph=dwarf -- ./octez-node run ...``
 
      This will write ``perf.data`` after having stopped the node with ``Ctrl-C``.
 
@@ -91,8 +91,8 @@ Performance profiling
 
    - `flamegraph <https://github.com/brendangregg/FlameGraph>`_: command-line
      tool for generating flamegraphs
-     (`example <https://gitlab.com/tezos/tezos/uploads/f8f8cece73da52b54fd9c79364e656e1/flame.svg>`__ for tezos-node)
+     (`example <https://gitlab.com/tezos/tezos/uploads/f8f8cece73da52b54fd9c79364e656e1/flame.svg>`__ for octez-node)
    - `gprof2dot <https://github.com/jrfonseca/gprof2dot>`_: command-line
      tool for generating callgraphs
-     (`example <https://gitlab.com/tezos/tezos/uploads/8640f489ad8002271fe41bbd0c34dfdc/callgraph.svg>`__ for tezos-node)
+     (`example <https://gitlab.com/tezos/tezos/uploads/8640f489ad8002271fe41bbd0c34dfdc/callgraph.svg>`__ for octez-node)
    - `hotspot <https://github.com/KDAB/hotspot>`_: a GUI for the `perf` tool
diff --git a/docs/developer/proposal_testing.rst b/docs/developer/proposal_testing.rst
index d12193025469b1471dda4c1e17430a458b230b18..78bbc809f08ada9dadbefe9b97a8cf72720086d3 100644
--- a/docs/developer/proposal_testing.rst
+++ b/docs/developer/proposal_testing.rst
@@ -36,8 +36,8 @@ latest code and run unit tests::
 
 We can run a node and a client in sandboxed mode by invoking::
 
-  $ ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 0 &
-  $ eval `./src/bin_client/tezos-init-sandboxed-client.sh 1`
+  $ ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 &
+  $ eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
 
 By default, the sandbox starts from the `genesis` block at level 0, and the
 sandbox's active protocol is the `Genesis protocol`. Once the sandbox is
@@ -51,7 +51,7 @@ because the sandbox contains accounts ``bootstrap1`` to ``bootstrap5`` with
 implicit credentials that allow them to bake blocks by using the usual RPCs in
 the shell (see :doc:`../user/sandbox`)::
 
-  $ tezos-client bake for --minimal-timestamp
+  $ octez-client bake for --minimal-timestamp
 
 Adding New Protocol Tests in OCaml
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -369,10 +369,10 @@ For instance, the following commands import a context from the snapshot file
 into the folder ``/tmp/mainnet``,
 and generate an identity in the same folder::
 
-  $ ./tezos-node snapshot import ~/snapshot-mainnet.rolling --data-dir /tmp/tezos-node-mainnet
-  $ ./tezos-node identity generate --data-dir /tmp/tezos-node-mainnet
+  $ ./octez-node snapshot import ~/snapshot-mainnet.rolling --data-dir /tmp/tezos-node-mainnet
+  $ ./octez-node identity generate --data-dir /tmp/tezos-node-mainnet
 
-The ``./tezos-node snapshot import`` command accepts an option
+The ``./octez-node snapshot import`` command accepts an option
 ``--block <block_hash>`` that instructs the command to check that the hash of
 the last block in the imported chain is ``<block_hash>``. This mechanism helps
 the developer to check that the imported chain contains blocks that are part of
@@ -418,7 +418,7 @@ stake of at least 75 percent can be kept with::
 
 By restricting the accumulated stake to 75% as in the command above,
 the wallet is both "lighter" (it may contain around 30-40 keys and
-therefore some commands like ``tezos-client bake for`` will execute
+therefore some commands like ``octez-client bake for`` will execute
 faster) and its keys will represent more than the 2/3rds of the
 endorsing power for any given level.
 
@@ -475,7 +475,7 @@ In case we opted for not snapshotting the Alpha protocol, we could batch steps
 
 The script ``scripts/prepare_migration_test.sh`` receives an optional
 ``<block_hash>`` as the last argument which, if passed, will be used for the
-option ``--block <block_hash>`` to the ``./tezos-node snapshot import`` command
+option ``--block <block_hash>`` to the ``./octez-node snapshot import`` command
 when importing the context form Mainnet.
 
 After performing the steps 1--7, the migration will be ready to be tested. The
@@ -489,14 +489,14 @@ Run the Migration on the Sandbox
 If we run the migration on an empty context, then we would start a sandboxed
 node as usual. In our example we can run the following::
 
-  $ ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 0 &
+  $ ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 &
 
 We can also start the client::
 
-  $ eval `./src/bin_client/tezos-init-sandboxed-client.sh 1`
+  $ eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
 
 Instead of command ``tezos-activate-alpha``, the sandboxed client script
-``src/bin_client/tezos-init-sandboxed-client.sh`` now accepts a command
+``src/bin_client/octez-init-sandboxed-client.sh`` now accepts a command
 ``tezos-activate-XXX-<short_hash>`` that activates the predecessor protocol with
 version number ``XXX`` and short hash ``<short_hash>``. In our example, the
 predecessor protocol is ``011`` with short hash ``PtHangz2``. (Check the folder
@@ -515,15 +515,15 @@ which migration will be triggered, which in our example is ``3``. Since
 activating the predecessor protocol increases the level by one, we need to bake
 two more blocks::
 
-  $ tezos-client bake for --minimal-timestamp
-  $ tezos-client bake for --minimal-timestamp
+  $ octez-client bake for --minimal-timestamp
+  $ octez-client bake for --minimal-timestamp
 
 .. note::
    Prior to Tenderbake activation (i.e. to the Protocol I) the command above
    requires a specific account to bake for. Any of ``bootstrap[0-9]`` accounts
    can be used to do it:
 
-   ``$ tezos-client bake for bootstrap1 --minimal-timestamp``
+   ``$ octez-client bake for bootstrap1 --minimal-timestamp``
 
 At this moment migration will be triggered and the protocol
 ``proto_012_<short_hash>`` will become active, and we will see the log message
@@ -552,12 +552,12 @@ environment variable ``test-directory`` to the path of the test folder, such
 that we can run the node in the test folder later. Then it copies the contents
 of the original context folder into the test folder.
 
-Now, we can run the ``tezos-node`` command by specifying the test folder
+Now, we can run the ``octez-node`` command by specifying the test folder
 ``$test-directory`` as the data directory. We will also specify the RPC address
 ``localhost``, such that the RPCs will be available at the url
 ``localhost:8732``. In our example, by invoking the following::
 
-  $ ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost &
+  $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost &
 
 We will now trigger the migration by baking blocks until the level reaches the
 one specified when setting the user-activated upgrades. The blocks can be baked
@@ -565,14 +565,14 @@ with the yes-wallet created in step 5 above, and with any of the accounts
 ``foundation1`` to ``foundation8``. In our example, we can bake one block by
 running the following command::
 
-  $ ./tezos-client -d /tmp/yes-wallet bake for --minimal-timestamp
+  $ ./octez-client -d /tmp/yes-wallet bake for --minimal-timestamp
 
 .. note::
    Prior to Tenderbake activation (i.e. to the Protocol I) this command requires
    a specific account to bake for. Any of ``foundation[1-8]`` accounts can be
    used to do it.
 
-   ``$ tezos-client bake for foundation1 --minimal-timestamp``
+   ``$ octez-client bake for foundation1 --minimal-timestamp``
 
    If the chosen account ``foundation1`` ceases to have the priority to bake, we
    can switch to any of the remaining accounts ``foundation2`` to
@@ -597,12 +597,12 @@ copy the context of the original folder into the test folder. In our example::
 
 Now we run the node in the test folder by invoking::
 
-  $ ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost &
+  $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost &
 
 And finally, we bake the numbers of blocks specified by the user-activated
 upgrade, with the command::
 
-  $ ./tezos-client -d /tmp/yes-wallet bake for --minimal-timestamp
+  $ ./octez-client -d /tmp/yes-wallet bake for --minimal-timestamp
 
 
 Wrap up the Manual Migration Procedure
@@ -644,8 +644,8 @@ the following fur commands)::
 
 Run sandboxed node and client::
 
-  $ ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 0 &
-  $ eval `./src/bin_client/tezos-init-sandboxed-client.sh 1`
+  $ ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 &
+  $ eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
 
 Activate predecessor of the Alpha protocol and move chain one level forward::
 
@@ -653,18 +653,18 @@ Activate predecessor of the Alpha protocol and move chain one level forward::
 
 Bake two more blocks::
 
-  $ tezos-client bake for --minimal-timestamp
-  $ tezos-client bake for --minimal-timestamp
+  $ octez-client bake for --minimal-timestamp
+  $ octez-client bake for --minimal-timestamp
 
 You should see the ``STITCHING!`` message!
 
 To test again, restart the sandboxed node and client::
 
   $ fg
-  ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 0
+  ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0
   ^C
-  $ ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 0 &
-  $ eval `./src/bin_client/tezos-init-sandboxed-client.sh 1`
+  $ ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 &
+  $ eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
 
 Activate predecessor of the Alpha protocol::
 
@@ -672,8 +672,8 @@ Activate predecessor of the Alpha protocol::
 
 Bake two blocks::
 
-  $ tezos-client bake for --minimal-timestamp
-  $ tezos-client bake for --minimal-timestamp
+  $ octez-client bake for --minimal-timestamp
+  $ octez-client bake for --minimal-timestamp
 
 You should see the ``STITCHING!`` message again!
 
@@ -713,8 +713,8 @@ invoking the following eight commands)::
   $ ./scripts/user_activated_upgrade.sh src/proto_012_* 1617344
   $ ./scripts/patch-yes_node.sh
   $ make
-  $ ./tezos-node snapshot import ~/mainnet.rolling --data-dir /tmp/tezos-node-mainnet
-  $ ./tezos-node identity generate --data-dir /tmp/tezos-node-mainnet
+  $ ./octez-node snapshot import ~/mainnet.rolling --data-dir /tmp/tezos-node-mainnet
+  $ ./octez-node identity generate --data-dir /tmp/tezos-node-mainnet
   $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/tezos-node-mainnet in /tmp/yes-wallet --active-bakers-only
 
 Copy original folder into test folder::
@@ -723,13 +723,13 @@ Copy original folder into test folder::
 
 Run the node`::
 
-  $ ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost &
+  $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost &
 
 Bake three blocks::
 
-  $ ./tezos-client -d /tmp/yes-wallet bake for --minimal-timestamp
-  $ ./tezos-client -d /tmp/yes-wallet bake for --minimal-timestamp
-  $ ./tezos-client -d /tmp/yes-wallet bake for --minimal-timestamp
+  $ ./octez-client -d /tmp/yes-wallet bake for --minimal-timestamp
+  $ ./octez-client -d /tmp/yes-wallet bake for --minimal-timestamp
+  $ ./octez-client -d /tmp/yes-wallet bake for --minimal-timestamp
 
 .. note::
    Prior to Tenderbake activation (i.e. to the Protocol I) this command requires
@@ -741,7 +741,7 @@ You should see the ``STITCHING!`` message!
 To test again, kill the node::
 
   $ fg
-  ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost
+  ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost
   ^C
 
 Clean up by removing test folder and copying original folder into fresh
@@ -753,13 +753,13 @@ test folder, and by removing files ``/tmp/yes-wallet/wallet_lock`` and
 
 Run the node::
 
-  ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost &
+  ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir "$test_directory" --rpc-addr localhost &
 
 And bake three blocks::
 
-  $ ./tezos-client -d /tmp/yes-wallet bake for --minimal-timestamp
-  $ ./tezos-client -d /tmp/yes-wallet bake for --minimal-timestamp
-  $ ./tezos-client -d /tmp/yes-wallet bake for --minimal-timestamp
+  $ ./octez-client -d /tmp/yes-wallet bake for --minimal-timestamp
+  $ ./octez-client -d /tmp/yes-wallet bake for --minimal-timestamp
+  $ ./octez-client -d /tmp/yes-wallet bake for --minimal-timestamp
 
 You should see the ``STITCHING!`` message again!
 
@@ -826,7 +826,7 @@ file ``~/mainnet.rolling`` into it. As explained in Section
 `Batch steps 1--7 above`_, the script ``scripts/prepare_migration_test.sh`` may
 receive an optional ``<block_hash>`` parameter as the last argument which, if
 present, will be used for the option ``--block <block_hash>`` of the command
-``./tezos-node snapshot import`` when importing the context form Mainnet.
+``./octez-node snapshot import`` when importing the context form Mainnet.
 
 If we opt for not snapshotting the Alpha protocol, we can prepare the automatic
 migration with the same command as above, but omitting the optional name
@@ -861,13 +861,13 @@ developer to be able to inspect the storage after the migration has been
 performed. Assume the temporary folder in our example is ``/tmp/tezt-526039``,
 the developer can start the node with the migrated context by invoking::
 
-  $ ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost &
+  $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost &
 
 Once the node is up, it is possible to inspect the storage by using the Tezos
 client and/or the RPCs. New blocks can be baked with any of the accounts
 ``foundation1`` to ``foundation8`` by using the following command::
 
-  $ ./tezos-client -d /tmp/tezt-526039/yes-wallet bake for --minimal-timestamp
+  $ ./octez-client -d /tmp/tezt-526039/yes-wallet bake for --minimal-timestamp
 
 If the developer wishes not to start the node that results after the migration,
 the parameter ``--keep-temp`` can be omitted and the Tezt's temp folder will be
@@ -912,17 +912,17 @@ Run the migration test::
 
 Run the resulting node (assuming temp folder ``/tmp/tezt-526039``)::
 
-  $ ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost &
+  $ ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost &
 
 Use the client, to manually inspect the storage, or for example to bake new
 blocks with the following command::
 
-  $ ./tezos-client -d /tmp/tezt-526039/yes-wallet bake for --minimal-timestamp
+  $ ./octez-client -d /tmp/tezt-526039/yes-wallet bake for --minimal-timestamp
 
 To test again, kill the node::
 
   $ fg
-  ./tezos-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost
+  ./octez-node run --synchronisation-threshold 0 --connections 0 --data-dir /tmp/tezt-526039/tezos-node-test --rpc-addr localhost
   ^C
 
 And run the migration test::
diff --git a/docs/developer/python_testing_framework.rst b/docs/developer/python_testing_framework.rst
index 6aac9e903c0af6fc43d363a933becd1c6488412c..c3299be6213752bacd1c57fe390936eafdae8e3e 100644
--- a/docs/developer/python_testing_framework.rst
+++ b/docs/developer/python_testing_framework.rst
@@ -14,7 +14,7 @@ It contains the following python packages.
 - ``process`` defining utility functions for interacting with processes
 - ``daemons`` defines classes to run Tezos node and daemons,
 - ``client`` mainly defines the ``Client`` class, that provides a programmatic interface to a client,
-- ``codec`` defines a ``Codec`` class, that provides a interface for ``tezos-codec`` binary,
+- ``codec`` defines a ``Codec`` class, that provides a interface for ``octez-codec`` binary,
 - ``launcher`` defines classes used to launch a nodes and daemons with specific settings,
 - ``tools`` contains utility functions and constants shared by the tests,
 - ``examples`` contains example of tests and scripts that run scenarios of interactions between tezos nodes and clients,
@@ -236,8 +236,8 @@ The ``sandbox`` object allows users to add nodes or bakers
 running in tezos sandboxed mode. Whenever a node has been added, one can
 access it using a client object.
 
-The client object is a wrapper on the ``tezos-client`` command. It runs
-``tezos-client`` with "administrative" parameters, plus the parameters determined
+The client object is a wrapper on the ``octez-client`` command. It runs
+``octez-client`` with "administrative" parameters, plus the parameters determined
 by the  method called by the user.
 
 For instance
@@ -250,10 +250,10 @@ will run something like
 
 ::
 
-    tezos-client -base-dir /tmp/tezos-client.be22ya16 -addr 127.0.0.1 -port 18730 transfer 500 from bootstrap1 to bootstrap3
+    octez-client -base-dir /tmp/octez-client.be22ya16 -addr 127.0.0.1 -port 18730 transfer 500 from bootstrap1 to bootstrap3
 
 ``receipt`` is an object of type ``client_output.TransferResult`` which gives
-access to some data of the ``tezos-client`` output.
+access to some data of the ``octez-client`` output.
 
 Alternatively, one can always construct the command manually:
 
@@ -495,8 +495,8 @@ Testing on a production branch (``zeronet``, ``mainnet``,...)
 
 On ``master``, protocol Alpha is named
 ``ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK``, and daemons binary
-name are suffixed with ``alpha`` (``tezos-baker-alpha``,
-``tezos-accuser-alpha``...). However, on *production* branches, an actual
+name are suffixed with ``alpha`` (``octez-baker-alpha``,
+``octez-accuser-alpha``...). However, on *production* branches, an actual
 hash of the protocol is used, and a shortened string is used to specify
 daemons.
 
@@ -525,7 +525,7 @@ match. We apply regression testing using the `pytest-regtest
 
 To simplify the writing of regression tests, we provide a
 specialized version of the ``client`` fixture, ``client_regtest``. It
-registers all output of the ``tezos-client``.
+registers all output of the ``octez-client``.
 
 Output conversion
 ~~~~~~~~~~~~~~~~~
@@ -559,13 +559,13 @@ that they are as expected.
 Writing regression tests
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-To write regression tests targeting the ``tezos-client``, write a test
+To write regression tests targeting the ``octez-client``, write a test
 as usual, but request the ``client_regtest`` (or
 ``client_regtest_scrubbed`` to enable output conversion) fixture
 instead of the ``client`` fixture.
 
 In this example test, we test the output of the `hash data` command of
-`tezos-client`:
+`octez-client`:
 
 .. code-block:: python
 
@@ -599,7 +599,7 @@ We find the generated test log in ``tests_python/tests/_regtest_outputs/test_reg
     Gas remaining: 799862 units remaining
 
 This is exactly the output of the command that was executed by the
-test, namely ``tezos-client hash data '(Pair 1 "foo")' of type '(pair
+test, namely ``octez-client hash data '(Pair 1 "foo")' of type '(pair
 nat string)'``.
 
 As discussed below in the section :ref:`Pitfalls to regression testing
diff --git a/docs/developer/rpc.rst b/docs/developer/rpc.rst
index efbffee283760ecc748d4b36856c570c3e355b70..fbf500cc8ef3600dafa59063a444df80d33308c1 100644
--- a/docs/developer/rpc.rst
+++ b/docs/developer/rpc.rst
@@ -9,29 +9,29 @@ network and just want to explore the RPC, you would run:
 
 ::
 
-    ./tezos-node run --rpc-addr localhost
+    ./octez-node run --rpc-addr localhost
 
-The RPC interface is self-documented and the ``tezos-client`` executable
+The RPC interface is self-documented and the ``octez-client`` executable
 is able to pretty-print the RPC API. For instance, to see the API
 provided by the Tezos Shell:
 
 ::
 
-    ./tezos-client rpc list
+    ./octez-client rpc list
 
 To get API attached to the “genesis” block, including the remote
 procedures provided by the associated economic protocol version:
 
 ::
 
-    ./tezos-client rpc list /chains/main/blocks/genesis
+    ./octez-client rpc list /chains/main/blocks/genesis
 
 You might also want the JSON schema describing the expected input and
 output of a RPC. For instance:
 
 ::
 
-    ./tezos-client rpc schema get /chains/main/blocks/genesis/hash
+    ./octez-client rpc schema get /chains/main/blocks/genesis/hash
 
 Note: you can get the same information, but as a raw JSON object, with a
 simple HTTP request:
@@ -47,11 +47,11 @@ simple HTTP request:
 An online :doc:`index <../active/rpc>` of RPC calls is
 also available.
 
-The general call of an RPC from the client is ``tezos-admin-client rpc
+The general call of an RPC from the client is ``octez-admin-client rpc
 (get|post) <url>``.
 For instance, if you wish to request the current balance of a given
 block and contract, you can call the associated RPC via the command :
-``$ tezos-admin-client rpc get
+``$ octez-admin-client rpc get
 /blocks/<block_id>/proto/context/contracts/<contract_id>/balance``.
 
 An RPC may take an *input* and generate an *output* both in JSON
@@ -61,7 +61,7 @@ input, would display on the standard output : ``{ "balance":
 through command-line, you will be prompted to provide the JSON input
 in your default configured text editor. Alternatively, you can provide
 the JSON input using command
-``$ tezos-admin-client rpc post <url> with <JSON>``. Don't forget to quote
+``$ octez-admin-client rpc post <url> with <JSON>``. Don't forget to quote
 the JSON according to your shell rules.
 
 If you want to learn more about the exchange of RPCs between node and
diff --git a/docs/developer/snoop.rst b/docs/developer/snoop.rst
index edbb15c4a83a9a4d9a04e19e6372a7d4b7f977e5..1843a06424ebbed24acc5dcb67fc6ab92b3e03dc 100644
--- a/docs/developer/snoop.rst
+++ b/docs/developer/snoop.rst
@@ -2,7 +2,7 @@ Benchmarking with Snoop
 =======================
 
 If you have a piece of code for which you'd like to construct
-a model predictive of its performance, ``tezos-snoop`` is the tool to
+a model predictive of its performance, ``octez-snoop`` is the tool to
 help you do that. This tool allows to benchmark any given piece of OCaml code
 and use these measures to fit cost models predictive of execution time.
 
@@ -12,13 +12,13 @@ computing the gas costs in the Tezos protocol.
 
 .. toctree::
    :maxdepth: 2
-   :caption: Architecture of tezos-snoop
+   :caption: Architecture of octez-snoop
 
    snoop_arch
 
 .. toctree::
    :maxdepth: 2
-   :caption: Using tezos-snoop by example
+   :caption: Using octez-snoop by example
 
    snoop_example
 
diff --git a/docs/developer/snoop_arch.rst b/docs/developer/snoop_arch.rst
index 056622cdce1c82cadf6e0dca77c5def2d772cd0e..78cd1b2704a467de8a317b8029bee448c340a3e5 100644
--- a/docs/developer/snoop_arch.rst
+++ b/docs/developer/snoop_arch.rst
@@ -1,14 +1,14 @@
-Architecture of ``tezos-snoop``
+Architecture of ``octez-snoop``
 ===============================
 
 The following figure describes the main functionalities and data
-processed by ``tezos-snoop``, to be read from top to bottom. The boxed
+processed by ``octez-snoop``, to be read from top to bottom. The boxed
 nodes represents the various kinds of data processed by the tool,
 while the unboxed items represent computational steps.
 
 .. image:: images/snoop_arch.png
 
-The code architecture of `tezos-snoop` is itself divided in the following
+The code architecture of `octez-snoop` is itself divided in the following
 main packages:
 
 - ``bin_snoop`` is the main binary (you can have a look at the :ref:`manual<benchmark_tool_manual>`).
@@ -28,7 +28,7 @@ tool.
 High-level description
 ----------------------
 
-``tezos-snoop`` is a tool for benchmarking and fitting statistical models which predict the performance of any piece of code of interest.
+``octez-snoop`` is a tool for benchmarking and fitting statistical models which predict the performance of any piece of code of interest.
 
 More concretely, let us consider a piece of code for which we wish to predict its performance. To understand the performance profile of this piece of code, we must execute it with different arguments, varying the size of the problem to be solved. As "the size of the problem to be solved" is a long expression, we will use the shorter term *workload* for that.
 
@@ -81,7 +81,7 @@ The library is meant to be used as follows:
 
 Modules implementing the ``Benchmark.S`` signature can also be registered
 via the ``Registration.register`` function which makes them available to
-``tezos-snoop``, a binary that wraps these features under a nice CLI.
+``octez-snoop``, a binary that wraps these features under a nice CLI.
 
 Defining benchmarks: the ``Generator`` module
 ---------------------------------------------
@@ -574,7 +574,7 @@ e.g. more than one hundred Michelson instructions it nice to have an
 automated tool figuring out the dependencies and scheduling the inference
 automatically.
 
-``tezos-snoop`` features this. The ``infer parameters`` command is launched
+``octez-snoop`` features this. The ``infer parameters`` command is launched
 in "full auto" mode when a *directory* is passed to it instead of a simple
 workload file. The tool then automatically scans this directory for all
 workload files, compute a dependency graph from the free variables and performs
diff --git a/docs/developer/snoop_example.rst b/docs/developer/snoop_example.rst
index deafc8da0b94df7c496bb784e1179f2ae35cb44b..352ed03b7cf49e13027764042350cdbe7f656c50 100644
--- a/docs/developer/snoop_example.rst
+++ b/docs/developer/snoop_example.rst
@@ -1,7 +1,7 @@
 Usage example
 =============
 
-We present a typical benchmark workflow using ``tezos-snoop``.
+We present a typical benchmark workflow using ``octez-snoop``.
 We'll consider the case of the ``blake2b`` hashing function, which
 is used among other things to hash blocks, operations and contexts:
 
@@ -19,7 +19,7 @@ Step 1: Defining the benchmark
 Benchmarks correspond to OCaml modules implementing the ``Benchmark.S`` signature.
 These must then be registered via the ``Registration.register`` function.
 Of course, for this registration to happen, the file containing the benchmark
-and the call to ``Registration.register`` should be linked with ``tezos-snoop``.
+and the call to ``Registration.register`` should be linked with ``octez-snoop``.
 See :doc:`snoop_arch` for complementary details.
 
 We'll define the benchmark module chunk by chunk and describe each part.
@@ -163,7 +163,7 @@ for this benchmark) but to execute this closure ``100000`` times (through ``--ns
 
 .. code-block:: shell
 
-   tezos-snoop benchmark TIMER_LATENCY and save to timer.workload --bench-num 1 --nsamples 100000
+   octez-snoop benchmark TIMER_LATENCY and save to timer.workload --bench-num 1 --nsamples 100000
 
 The tool returns the following on standard output:
 
@@ -195,7 +195,7 @@ zero. One could also run many benchmarks with fewer samples per benchmark:
 
 .. code-block:: shell
 
-   tezos-snoop benchmark TIMER_LATENCY and save to timer.workload --bench-num 1000 --nsamples 100
+   octez-snoop benchmark TIMER_LATENCY and save to timer.workload --bench-num 1000 --nsamples 100
 
 This yields on standard output:
 
@@ -240,7 +240,7 @@ If not specified, the PRNG will self-initialize using an unknown seed.
 
 .. code-block:: shell
 
-   tezos-snoop benchmark Blake2b_example and save to blake2b.workload --bench-num 500 --nsamples 3000 --determinizer percentile@50 --seed 12897
+   octez-snoop benchmark Blake2b_example and save to blake2b.workload --bench-num 500 --nsamples 3000 --determinizer percentile@50 --seed 12897
 
 Here's the output:
 
@@ -272,7 +272,7 @@ It is possible to remove outliers from the raw benchmark data. The command is th
 
 .. code-block:: shell
 
-   tezos-snoop remove outliers from data ./blake2b.workload above 3 sigmas and save to blake2b-cleaned.workload
+   octez-snoop remove outliers from data ./blake2b.workload above 3 sigmas and save to blake2b-cleaned.workload
 
 In this particular example, the data seems clean though:
 
@@ -297,7 +297,7 @@ At the time of writing, the tool offloads the regression problem to the `scikit-
 
 .. code-block:: shell
 
-   tezos-snoop infer parameters for model blake2b on data blake2b.workload using lasso --lasso-positive --dump-csv blake2b.csv --save-solution blake2b.sol --plot
+   octez-snoop infer parameters for model blake2b on data blake2b.workload using lasso --lasso-positive --dump-csv blake2b.csv --save-solution blake2b.sol --plot
 
 ::
 
@@ -357,7 +357,7 @@ but the principle is similar.
 
 .. code-block:: shell
 
-   tezos-snoop generate code using solution blake2b.sol and model blake2b_codegen
+   octez-snoop generate code using solution blake2b.sol and model blake2b_codegen
 
 By default, the tool produces integer code by casting floating point constant to integers.
 The tool produces the following code on ``stdout``:
@@ -383,7 +383,7 @@ Calling the tool:
 
 .. code-block:: shell
 
-   tezos-snoop generate code using solution blake2b.sol and model blake2b_codegen --fixed-point codegen_params.json
+   octez-snoop generate code using solution blake2b.sol and model blake2b_codegen --fixed-point codegen_params.json
 
 We get:
 
diff --git a/docs/developer/snoop_interpreter.rst b/docs/developer/snoop_interpreter.rst
index fdc71dfcb77e4542d15ff09e4eb068ba08075b7b..d217ff709d651940c3bef87a9ed166b25869f4ed 100644
--- a/docs/developer/snoop_interpreter.rst
+++ b/docs/developer/snoop_interpreter.rst
@@ -1,12 +1,12 @@
 Snoop and the Michelson Interpreter
 ===================================
 
-In order to evaluate gas costs for the Michelson interpreter, we want to have a collection of benchmarks and models that cover every instruction of the language. This document explains how to modify the files in :src:`src/proto_alpha/lib_benchmarks_proto/` in order to fully integrate a new instruction for ``tezos-snoop``.
+In order to evaluate gas costs for the Michelson interpreter, we want to have a collection of benchmarks and models that cover every instruction of the language. This document explains how to modify the files in :src:`src/proto_alpha/lib_benchmarks_proto/` in order to fully integrate a new instruction for ``octez-snoop``.
 
 Interpreter Workload
 --------------------
 
-We first need to update the ``interpreter_workload.ml`` file. It specifies the data that is collected and saved as a ``workload`` for each benchmark. First, we add an entry to ``instruction_name`` with the name of the new instruction prefixed with ``N_``, it will be the name ``tezos-snoop`` will refer to this instruction as. Then add it to the list ``all_instructions``, and update ``string_of_instruction_name``. Now, we can add a function to the ``Instructions`` module. This function should take a number, possibly zero, of integer arguments that defines our workload. We want these arguments to be the different parameters that may influence the benchmarking time. For instance, the time ``DIG`` takes to be executed varies with the depth of digging, so the ``depth`` should be in the workload:
+We first need to update the ``interpreter_workload.ml`` file. It specifies the data that is collected and saved as a ``workload`` for each benchmark. First, we add an entry to ``instruction_name`` with the name of the new instruction prefixed with ``N_``, it will be the name ``octez-snoop`` will refer to this instruction as. Then add it to the list ``all_instructions``, and update ``string_of_instruction_name``. Now, we can add a function to the ``Instructions`` module. This function should take a number, possibly zero, of integer arguments that defines our workload. We want these arguments to be the different parameters that may influence the benchmarking time. For instance, the time ``DIG`` takes to be executed varies with the depth of digging, so the ``depth`` should be in the workload:
 
 .. code-block:: ocaml
 
diff --git a/docs/developer/testing.rst b/docs/developer/testing.rst
index 9209580800cb9a4ee6d1bf7708805d0514201485..efe91da8479f6b6cdca014603886546f483d3391 100644
--- a/docs/developer/testing.rst
+++ b/docs/developer/testing.rst
@@ -174,7 +174,7 @@ Python testing and execution framework
 
 The Tezos project uses `pytest <https://docs.pytest.org/>`_, a Python testing
 framework, combined with :doc:`tezos-launchers <python_testing_framework>`, a Python wrapper
-``tezos-node`` and ``tezos-client``, to perform integration testing
+``octez-node`` and ``octez-client``, to perform integration testing
 of the node, the client, networks of nodes and daemons such as the baker
 and endorser.
 
@@ -185,7 +185,7 @@ enables regression testing.
 
 
 Typical use cases:
- - Testing the commands of ``tezos-client``. This allows to test the
+ - Testing the commands of ``octez-client``. This allows to test the
    full chain: from client, to node RPC to the implementation of the
    economic protocol.
  - Test networks of nodes, with daemons.
@@ -264,7 +264,7 @@ detect performance regressions. See :doc:`long-tezts`.
    The `Michelson unit test proposal
    <https://gitlab.com/tezos/tezos/-/merge_requests/1487>`__ defines a
    format for unit tests for Michelson snippets. If the proposal is eventually accepted, then these
-   tests will be executable through ``tezos-client``.
+   tests will be executable through ``octez-client``.
 
    Example use cases:
     - Verifying the functional (input--output) behavior of snippets of
@@ -434,8 +434,8 @@ guidelines:
 
 For system test frameworks
    System test frameworks, as :doc:`tezt` and :doc:`python_testing_framework`,
-   run binaries e.g. ``tezos-client`` and
-   ``tezos-node``. Typically, they do so with calls to ``exec`` so the
+   run binaries e.g. ``octez-client`` and
+   ``octez-node``. Typically, they do so with calls to ``exec`` so the
    resulting process does not inherit the signal handlers from the
    parent process (the test framework). When writing tests in these
    frameworks, the author must ensure that the processes launched are
diff --git a/docs/developer/time_measurement_ppx.rst b/docs/developer/time_measurement_ppx.rst
index fb5ec97eb407e0e2935e8067072360310f390624..3c975fa0ad693a78b6ab4047051e15338f17a17d 100644
--- a/docs/developer/time_measurement_ppx.rst
+++ b/docs/developer/time_measurement_ppx.rst
@@ -189,7 +189,7 @@ The PPX provides the handling of three attributes:
 
 Some of these attributes are used, for instance, in the implementation of the :ref:`performance regression test framework <performance_regression_test_fw>`.
 
-Instrumenting the tezos-node executable
+Instrumenting the octez-node executable
 ---------------------------------------
 
 A helper has been added in the ``Makefile``, so you just need to run the following
diff --git a/docs/include/rpc_introduction.rst.inc b/docs/include/rpc_introduction.rst.inc
index 0e566a2fb4d8aba650fa9cd82b22e78e179e9d5d..004243549f837a59f6f08902890ff9b6b77b3bdf 100644
--- a/docs/include/rpc_introduction.rst.inc
+++ b/docs/include/rpc_introduction.rst.inc
@@ -17,12 +17,12 @@ RPCs - Index
 
 Note that the RPCs served under a given prefix can also be listed using the client, e.g.::
 
-    tezos-client rpc list /chains/main/blocks/head/context/constants
+    octez-client rpc list /chains/main/blocks/head/context/constants
 
 Any RPC endpoint may also be described, using the ``describe`` RPC to
 retrieve all JSON and binary schemas, e.g.::
 
-    tezos-client rpc get /describe/chains/main/blocks/head/context/constants
+    octez-client rpc get /describe/chains/main/blocks/head/context/constants
 
 Shell
 =====
diff --git a/docs/introduction/howtoget.rst b/docs/introduction/howtoget.rst
index 8fc1b4cff45f27d25afb16fa5fc24544c3d7aa5f..e2fa5df66d2b6d0e3fc5a13b22c48ddd7b5755e6 100644
--- a/docs/introduction/howtoget.rst
+++ b/docs/introduction/howtoget.rst
@@ -147,7 +147,7 @@ Using Docker Images And Docker-Compose
 For every change committed in the GitLab repository, Docker images are
 automatically generated and published on `DockerHub
 <https://hub.docker.com/r/tezos/tezos/>`_. This provides a convenient
-way to run an always up-to-date ``tezos-node``.
+way to run an always up-to-date ``octez-node``.
 
 One way to run those Docker images is with `docker-compose <https://docs.docker.com/compose>`_.
 We provide ``docker-compose`` files for all active
@@ -336,15 +336,15 @@ Now, install all the binaries by:
   :start-after: [install tezos]
   :end-before: [test executables]
 
-You can be more specific and only ``opam install tezos-node``, ``opam
-install tezos-baker-alpha``, ... In that case, it is enough to install
+You can be more specific and only ``opam install octez-node``, ``opam
+install octez-baker-alpha``, ... In that case, it is enough to install
 the system dependencies of this package only by running ``opam depext
-tezos-node`` for example instead of ``opam depext tezos``.
+octez-node`` for example instead of ``opam depext tezos``.
 
 .. warning::
 
-   Note that ``opam install tezos-client`` and ``opam install
-   tezos-signer`` are "minimal" and do not install the support for
+   Note that ``opam install octez-client`` and ``opam install
+   octez-signer`` are "minimal" and do not install the support for
    Ledger Nano devices. To enable it, run ``opam install
    ledgerwallet-tezos`` in addition to installing the binaries. (The
    macro meta-package ``tezos`` installs ``ledgerwallet-tezos``.)
diff --git a/docs/introduction/howtorun.rst b/docs/introduction/howtorun.rst
index d22c1923e8fe1f63ab090ed6ce252d19b74d9833..b6540466d5c7f6853bba16fc3e5f838e76c7fa74 100644
--- a/docs/introduction/howtorun.rst
+++ b/docs/introduction/howtorun.rst
@@ -30,7 +30,7 @@ achieved by the following command:
 
 ::
 
-   tezos-client set delegate for <implicit_account> to <delegate>
+   octez-client set delegate for <implicit_account> to <delegate>
 
 where ``<implicit_account>`` is the address or alias of the implicit
 account to delegate and ``<delegate>`` is the address or alias of the
@@ -40,7 +40,7 @@ To stop a delegation, the following command can be used:
 
 ::
 
-   tezos-client withdraw delegate from <implicit_account>
+   octez-client withdraw delegate from <implicit_account>
 
 
 
@@ -50,7 +50,7 @@ origination using the ``--delegate`` option:
 
 ::
 
-    tezos-client originate contract <contract_alias> transferring <initial_balance> from <originator> running <script> --delegate <delegate> --burn-cap <cap>
+    octez-client originate contract <contract_alias> transferring <initial_balance> from <originator> running <script> --delegate <delegate> --burn-cap <cap>
 
 
 Once the contract is originated, the only way to stop or modify its
@@ -101,7 +101,7 @@ frozen deposits with the following command:
 
 ::
 
-   tezos-client set deposits limit for <delegate> to <limit>
+   octez-client set deposits limit for <delegate> to <limit>
 
 
 On testnets, when you obtain coins from :ref:`a faucet<faucet>`, if
@@ -119,7 +119,7 @@ Register and check your rights
 To run a delegate, you first need to register as one using
 your implicit account::
 
-   tezos-client register key bob as delegate
+   octez-client register key bob as delegate
 
 Once registered, you need to wait ``preserved_cycles + 2 = 7`` cycles
 for your rights to be considered.
@@ -129,7 +129,7 @@ cycle, up to 5 cycles in the future.
 
 ::
 
-   tezos-client rpc get /chains/main/blocks/head/helpers/baking_rights\?cycle=300\&delegate=tz1_xxxxxxxxxxx\&max_round=2
+   octez-client rpc get /chains/main/blocks/head/helpers/baking_rights\?cycle=300\&delegate=tz1_xxxxxxxxxxx\&max_round=2
 
 Sometimes there is no consensus at a round, so it is worth considering also
 baking rights at higher rounds, like 2 in the example above.
@@ -169,7 +169,7 @@ accounts have the necessary rights.
 Let's launch the daemon pointing to the standard node directory and
 baking for user *bob*::
 
-   tezos-baker-alpha run with local node ~/.tezos-node bob --liquidity-baking-toggle-vote pass
+   octez-baker-alpha run with local node ~/.tezos-node bob --liquidity-baking-toggle-vote pass
 
 Note that the baker needs direct access to
 the node data directory for performance reasons (to reduce the number of RPC calls to the node).
@@ -187,7 +187,7 @@ Note that ``--liquidity-baking-toggle-vote`` must be placed
 .. note::
 
    In protocols before Ithaca, a separate daemon, the endorser, is responsible for emitting endorsements.
-   In these protocols, one needs to run the daemon ``tezos-endorser-NNN-*`` to endorse.
+   In these protocols, one needs to run the daemon ``octez-endorser-NNN-*`` to endorse.
 
 Accuser
 ~~~~~~~
@@ -205,7 +205,7 @@ cause the offender to be :ref:`slashed<slashing>`, that is, to lose part of its
 
 ::
 
-   tezos-accuser-alpha run
+   octez-accuser-alpha run
 
 
 Docker
diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst
index 4d4dfd2b3b494c5eaa7481832c363f5c4c9982ad..2a127662492e1b944f8ad5f5b406319ee0016340 100644
--- a/docs/introduction/howtouse.rst
+++ b/docs/introduction/howtouse.rst
@@ -15,25 +15,25 @@ The Binaries
 
 After a successful compilation, you should have the following binaries:
 
-- ``tezos-node``: the tezos daemon itself (see `Node`_);
-- ``tezos-client``: a command-line client and basic wallet (see `Client`_);
-- ``tezos-admin-client``: administration tool for the node (see :ref:`tezos-admin-client`);
-- ``tezos-{baker,accuser}-*``: daemons to bake and accuse on the Tezos network (see :doc:`howtorun`);
-  note that prior to v12 of Octez, there was also an endorser daemon ``tezos-endorser-*``;
-- ``tezos-validator``: a daemon for validating and applying operations in blocks (see `Validator`_)
-- ``tezos-signer``: a client to remotely sign operations or blocks
+- ``octez-node``: the tezos daemon itself (see `Node`_);
+- ``octez-client``: a command-line client and basic wallet (see `Client`_);
+- ``octez-admin-client``: administration tool for the node (see :ref:`octez-admin-client`);
+- ``octez-{baker,accuser}-*``: daemons to bake and accuse on the Tezos network (see :doc:`howtorun`);
+  note that prior to v12 of Octez, there was also an endorser daemon ``octez-endorser-*``;
+- ``octez-validator``: a daemon for validating and applying operations in blocks (see `Validator`_)
+- ``octez-signer``: a client to remotely sign operations or blocks
   (see :ref:`signer`);
-- ``tezos-proxy-server``: a readonly frontend to ``tezos-node`` designed to lower the load of full nodes (see :doc:`../user/proxy-server`)
-- ``tezos-codec``: a utility for documenting the data encodings and for performing data encoding/decoding (see `Codec`_)
-- ``tezos-protocol-compiler``: a domain-specific compiler for Tezos protocols (see `Protocol compiler`_)
-- ``tezos-snoop``: a tool for modeling the performance of any piece of OCaml code, based on benchmarking (see :doc:`../developer/snoop`)
+- ``octez-proxy-server``: a readonly frontend to ``octez-node`` designed to lower the load of full nodes (see :doc:`../user/proxy-server`)
+- ``octez-codec``: a utility for documenting the data encodings and for performing data encoding/decoding (see `Codec`_)
+- ``octez-protocol-compiler``: a domain-specific compiler for Tezos protocols (see `Protocol compiler`_)
+- ``octez-snoop``: a tool for modeling the performance of any piece of OCaml code, based on benchmarking (see :doc:`../developer/snoop`)
 
 The daemons other than the node are suffixed with the name of the protocol they are
 bound to, and up to some version, also by its number.
-For instance, ``tezos-baker-014-PtKathma`` is the baker
-for the Kathmandu protocol, and ``tezos-baker-alpha`` is the baker
+For instance, ``octez-baker-014-PtKathma`` is the baker
+for the Kathmandu protocol, and ``octez-baker-alpha`` is the baker
 of the development protocol.
-The ``tezos-node`` daemon is not suffixed by any protocol name, because it is independent of the economic protocol. See also the `Node's Protocol`_ section below.
+The ``octez-node`` daemon is not suffixed by any protocol name, because it is independent of the economic protocol. See also the `Node's Protocol`_ section below.
 
 
 Read The Manual
@@ -44,15 +44,15 @@ All the Tezos binaries provide the ``--help`` option to display information abou
 Additionally, most of the above binaries (i.e., all but the node, the validator, and the compiler) provide a textual manual that can be obtained with the command ``man``,
 whose verbosity can be increased with ``-v``, for example::
 
-    tezos-client man -v 3
+    octez-client man -v 3
 
 It is also possible to get information on a specific command in the manual with ``man <command>``::
 
-   tezos-client man set
+   octez-client man set
 
 To see the usage of one specific command, you may also type the command without arguments, which display its possible completions and options::
 
-   tezos-client transfer
+   octez-client transfer
 
 .. warning::
 
@@ -76,11 +76,11 @@ To see the usage of one specific command, you may also type the command without
 
 To get the manual of a client command for a protocol other than that used by the node (or even when not connected to a node), use the option ``--protocol``, e.g.::
 
-    tezos-client --protocol ProtoALphaALph man transfer
+    octez-client --protocol ProtoALphaALph man transfer
 
 Note that you can get the list of protocols known to the client with::
 
-    tezos-client list understood protocols
+    octez-client list understood protocols
 
 The full command line documentation of the Tezos binaries supporting the ``man`` command is also available
 online: :doc:`../shell/cli-commands`.
@@ -91,7 +91,7 @@ Node
 The node is the main actor of the Tezos blockchain and it has two main
 functions: running the gossip network and updating the context.
 The gossip network is where all Tezos nodes exchange blocks and
-operations with each other (see :ref:`tezos-admin-client` to monitor
+operations with each other (see :ref:`octez-admin-client` to monitor
 p2p connections).
 Using this peer-to-peer network, an operation originated by a user can
 hop several times through other nodes until it finds its way in a
@@ -109,8 +109,8 @@ disseminating this information to build a consensus across the
 network.
 
 Other than passively observing the network, your node can also inject
-its own new operations when instructed by the ``tezos-client`` and even
-send new blocks when guided by the ``tezos-baker-*``.
+its own new operations when instructed by the ``octez-client`` and even
+send new blocks when guided by the ``octez-baker-*``.
 The node has also a view of the multiple chains that may exist
 concurrently and selects the best one based on its fitness (see
 :doc:`../active/consensus`).
@@ -122,7 +122,7 @@ Node Identity
 First, we need to generate a new identity for the node to
 connect to the network::
 
-    tezos-node identity generate
+    octez-node identity generate
 
 .. note::
 
@@ -198,7 +198,7 @@ internet. With the following command, it is available uniquely on the
 
 ::
 
-   tezos-node run --rpc-addr 127.0.0.1
+   octez-node run --rpc-addr 127.0.0.1
 
 Node configuration
 ~~~~~~~~~~~~~~~~~~
@@ -213,7 +213,7 @@ Many options of the node can be configured when running the node:
 
 The list of configurable options can be obtained using the following command::
 
-    tezos-node run --help
+    octez-node run --help
 
 You can read more about the :doc:`node configuration <../user/node-configuration>` and its :ref:`private mode <private-mode>`.
 
@@ -231,11 +231,11 @@ Putting together all the above instructions, you may want to run a node as follo
     # Download a snapshot for your target network, e.g. <test-net>:
     wget <snapshot-url> -O <snapshot-file>
     # Configure the node for running on <test-net>:
-    tezos-node config init --data-dir ~/.tezos-node-<test-net> --network <test-net>
+    octez-node config init --data-dir ~/.tezos-node-<test-net> --network <test-net>
     # Import the snapshot into the node data directory:
-    tezos-node snapshot import --data-dir ~/.tezos-node-<test-net> --block <block-hash> <snapshot-file>
+    octez-node snapshot import --data-dir ~/.tezos-node-<test-net> --block <block-hash> <snapshot-file>
     # Run the node:
-    tezos-node run --data-dir ~/.tezos-node-<test-net> --rpc-addr 127.0.0.1
+    octez-node run --data-dir ~/.tezos-node-<test-net> --rpc-addr 127.0.0.1
 
 .. _howtouse_tezos_client:
 
@@ -247,7 +247,7 @@ status or ask the node to perform some actions.
 For example, after starting your node you can check if it has finished
 synchronizing (see :doc:`../shell/sync`) using::
 
-   tezos-client bootstrapped
+   octez-client bootstrapped
 
 This call will hang and return only when the node is synchronized
 (recall that this is much faster when starting a node from a snapshot).
@@ -255,7 +255,7 @@ Once the above command returns,
 we can check what is the current timestamp of the head of the
 chain (time is in UTC so it may differ from your local time)::
 
-   tezos-client get timestamp
+   octez-client get timestamp
 
 You can also use the above command before the node is bootstrapped, from another terminal.
 However, recall that the commands available on the client depend on the specific
@@ -269,11 +269,11 @@ A Simple Wallet
 The client is also a basic wallet. We can, for example, generate a new pair of keys, which can be used locally
 with the alias *alice*::
 
-      $ tezos-client gen keys alice
+      $ octez-client gen keys alice
 
 To check the account (also called a contract) for Alice has been created::
 
-      $ tezos-client list known contracts
+      $ octez-client list known contracts
 
 You will notice that the client data directory (by default, ``~/.tezos-client``) has been populated with
 3 files ``public_key_hashs``, ``public_keys`` and ``secret_keys``.
@@ -289,7 +289,7 @@ contracts, which have the form *KT1…*.
 Notice that by default, the keys were stored unencrypted, which is fine in our test example.
 In more realistic scenarios, you should supply the option ``--encrypted`` when generating a new account::
 
-      $ tezos-client gen keys bob --encrypted
+      $ octez-client gen keys bob --encrypted
 
 Tezos support three different ECC (`Elliptic-Curve Cryptography <https://en.wikipedia.org/wiki/Elliptic-curve_cryptography>`_) schemes: *Ed25519*, *secp256k1* (the
 one used in Bitcoin), and *P-256* (also called *secp256r1*). The two
@@ -327,7 +327,7 @@ the network, so that we can inspect its receipt.
 
 Let's try::
 
-  tezos-client transfer 1 from alice to bob --dry-run
+  octez-client transfer 1 from alice to bob --dry-run
 
   Fatal error:
     The operation will burn ꜩ0.257 which is higher than the configured burn cap (ꜩ0).
@@ -345,7 +345,7 @@ Because storing an address requires burning ꜩ0.257 and the client has
 a default of 0, we need to explicitly set a cap on the amount that we
 allow to burn::
 
-  tezos-client transfer 1 from alice to bob --dry-run --burn-cap 0.257
+  octez-client transfer 1 from alice to bob --dry-run --burn-cap 0.257
 
 This should do it and you should see a rather long receipt being
 produced, here's an excerpt::
@@ -448,7 +448,7 @@ In Tezos there are two kinds of accounts: *implicit accounts* and *smart contrac
 
 Let's originate our first contract and call it *id*::
 
-    tezos-client originate contract id transferring 1 from alice \
+    octez-client originate contract id transferring 1 from alice \
                  running ./tests_python/contracts_alpha/attic/id.tz \
                  --init '"hello"' --burn-cap 0.4
 
@@ -498,7 +498,7 @@ abuse and encourage lean programs.
 Let's see what calling a program with a new argument would look like
 with the ``--dry-run`` option::
 
-   tezos-client transfer 0 from alice to id --arg '"world"' --dry-run
+   octez-client transfer 0 from alice to id --arg '"world"' --dry-run
 
 The transaction would successfully update the storage but this time it
 wouldn't cost us anything more than the fee, the reason is that the
@@ -524,7 +524,7 @@ Note that the storage limit sets an upper bound to the storage size *difference*
 
 ::
 
-   tezos-client transfer 0 from alice to id --arg '"world"' \
+   octez-client transfer 0 from alice to id --arg '"world"' \
                                             --gas-limit 11375 \
                                             --storage-limit 0
 
@@ -579,7 +579,7 @@ make sure that the node is listening on the right ports and that the ports are
 open.
 For example the ``get timestamp`` command above is a shortcut for::
 
-   tezos-client rpc get /chains/main/blocks/head/header/shell
+   octez-client rpc get /chains/main/blocks/head/header/shell
 
 The client tries to simplify common tasks as much as possible, however
 if you want to query the node for more specific information you'll
@@ -591,7 +591,7 @@ For example to check the value of important
 :ref:`constants <protocol_constants>` in Tezos, which may differ between Mainnet and other
 :ref:`test networks<test-networks>`, you can use::
 
-   tezos-client rpc get /chains/main/blocks/head/context/constants | jq
+   octez-client rpc get /chains/main/blocks/head/context/constants | jq
    {
      "proof_of_work_nonce_size": 8,
      "nonce_length": 32,
@@ -601,11 +601,11 @@ For example to check the value of important
 Another interesting use of RPCs is to inspect the receipts of the
 operations of a block::
 
-  tezos-client rpc get /chains/main/blocks/head/operations
+  octez-client rpc get /chains/main/blocks/head/operations
 
 It is also possible to review the receipt of the whole block::
 
-  tezos-client rpc get /chains/main/blocks/head/metadata
+  octez-client rpc get /chains/main/blocks/head/metadata
 
 An interesting block receipt is the one produced at the end of a
 cycle as many delegates receive back part of their unfrozen accounts.
@@ -640,7 +640,7 @@ In this short tutorial we will not use some other binaries, but let as briefly r
 Validator
 ~~~~~~~~~
 
-The Tezos validator (``tezos-validator``) is an auxiliary daemon that is launched by ``tezos-node`` in order to validate operations in parallel to its main process (unless the option ``--singleprocess`` is given).
+The Tezos validator (``octez-validator``) is an auxiliary daemon that is launched by ``octez-node`` in order to validate operations in parallel to its main process (unless the option ``--singleprocess`` is given).
 It also applies the valid operations in a block and computes the resulting context.
 
 It is not meant to be invoked directly by users.
@@ -648,9 +648,9 @@ It is not meant to be invoked directly by users.
 Codec
 ~~~~~
 
-The Tezos codec (``tezos-codec``) is a utility that:
+The Tezos codec (``octez-codec``) is a utility that:
 
-- provides documentation for all the encodings used in the ``tezos-node`` (and other binaries), and
+- provides documentation for all the encodings used in the ``octez-node`` (and other binaries), and
 - allows to convert from JSON to binary and vice-versa for all these encodings.
 
 It is meant to be used by developers for tests, for generating documentation when writing libraries that share data with the node, for light scripting, etc.
@@ -659,7 +659,7 @@ For more details on its usage, refer to its :ref:`online manual <codec_manual>`
 Protocol compiler
 ~~~~~~~~~~~~~~~~~
 
-The protocol compiler (``tezos-protocol-compiler``) can compile protocols within the limited environment that the shell provides.
+The protocol compiler (``octez-protocol-compiler``) can compile protocols within the limited environment that the shell provides.
 This environment is limited to a restricted set of libraries in order to constrain the possible behavior of the protocols.
 
 It is meant to be used:
diff --git a/docs/introduction/install-opam-scratch.sh b/docs/introduction/install-opam-scratch.sh
index cb8994c20932d68716448a9f39fd50fa5bd3149c..136345a6537c503e724f7f1a22ce53dd4b6803bb 100755
--- a/docs/introduction/install-opam-scratch.sh
+++ b/docs/introduction/install-opam-scratch.sh
@@ -35,4 +35,4 @@ opam depext tezos
 # [install tezos]
 opam install -y tezos
 # [test executables]
-tezos-client --version
+octez-client --version
diff --git a/docs/kathmandu/cli-commands.rst b/docs/kathmandu/cli-commands.rst
index 0eaba7aebaa722aba62f918a2a31785058b5c7c5..95e17d8a1c1a45220ad581e7e0617d3db56f802f 100644
--- a/docs/kathmandu/cli-commands.rst
+++ b/docs/kathmandu/cli-commands.rst
@@ -8,7 +8,7 @@ using shell commands such as (:ref:`indicating the appropriate protocol <tezos_c
 
 ::
 
-   tezos-client -protocol <protocol_hash> man -verbosity 3
+   octez-client -protocol <protocol_hash> man -verbosity 3
 
 The rest of this page documents the protocol-dependent tools.
 The protocol-independent tools are documented :doc:`here <../shell/cli-commands>`.
@@ -21,7 +21,7 @@ Client manual
 =============
 
 .. raw:: html
-         :file: tezos-client.html
+         :file: octez-client.html
 
 
 .. _baker_manual:
@@ -31,7 +31,7 @@ Baker manual
 ============
 
 .. raw:: html
-         :file: tezos-baker.html
+         :file: octez-baker.html
 
 
 .. _accuser_manual:
@@ -41,4 +41,4 @@ Accuser manual
 ==============
 
 .. raw:: html
-         :file: tezos-accuser.html
+         :file: octez-accuser.html
diff --git a/docs/kathmandu/consensus.rst b/docs/kathmandu/consensus.rst
index c12dc6c58d2195990e4413a129e71725aadbe806..29c7a90ed32f276644edc36ba3576e30dca281e6 100644
--- a/docs/kathmandu/consensus.rst
+++ b/docs/kathmandu/consensus.rst
@@ -186,8 +186,8 @@ not the other way around.):
 - ``spendable balance`` is obtained with ``../context/contracts/<pkh>/balance``
 
 Delegates can set an upper limit to their frozen deposits with the
-command ``tezos-client set deposits limit for <delegate> to
-<deposit_limit>``, and unset this limit with the command ``tezos-client
+command ``octez-client set deposits limit for <delegate> to
+<deposit_limit>``, and unset this limit with the command ``octez-client
 unset deposits limit for <delegate>``. These commands are implemented
 using a new manager operation ``Set_deposits_limit``. When emitting such a
 command in cycle ``c``, it affects the active stake for cycles starting
diff --git a/docs/kathmandu/global_constants.rst b/docs/kathmandu/global_constants.rst
index 9b8286f906b59bdf722aee25834e6c6a0bbeb968..383f3e0e3fd2cb02c4edd2ad17802b5c9464427f 100644
--- a/docs/kathmandu/global_constants.rst
+++ b/docs/kathmandu/global_constants.rst
@@ -26,12 +26,12 @@ The new ``register_global_constant`` operation includes an object with a
 single key ``"value"``, the value of which is the Micheline expression
 to be registered.
 
-You can submit this operation conveniently through a new :doc:`tezos-client <cli-commands>` command.
+You can submit this operation conveniently through a new :doc:`octez-client <cli-commands>` command.
 For example, the command:
 
 .. code:: sh
 
-    tezos-client register global constant "999" from bootstrap1 --burn-cap 0.017
+    octez-client register global constant "999" from bootstrap1 --burn-cap 0.017
 
 would result in the output:
 
@@ -44,7 +44,7 @@ would result in the output:
    Operation hash is 'onsFknW5iWa6eiTYqAghY4peQZ7JYQUJg5fR8MwAQkMKjXfNqGf'
    NOT waiting for the operation to be included.
    Use command
-     tezos-client wait for onsFknW5iWa6eiTYqAghY4peQZ7JYQUJg5fR8MwAQkMKjXfNqGf to be included --confirmations 5 --branch BLockGenesisGenesisGenesisGenesisGenesisCCCCCeZiLHU
+     octez-client wait for onsFknW5iWa6eiTYqAghY4peQZ7JYQUJg5fR8MwAQkMKjXfNqGf to be included --confirmations 5 --branch BLockGenesisGenesisGenesisGenesisGenesisCCCCCeZiLHU
    and/or an external block explorer to make sure that it has been included.
    This sequence of operations was run:
      Manager signed operations:
diff --git a/docs/kathmandu/liquidity_baking.rst b/docs/kathmandu/liquidity_baking.rst
index 63c6270bdc4dda2a9a03ef9d42b0d892b2832af5..f7cfa46098bfb97630a969e8493255fe44a372f2 100644
--- a/docs/kathmandu/liquidity_baking.rst
+++ b/docs/kathmandu/liquidity_baking.rst
@@ -68,13 +68,13 @@ non-abstaining blocks, about 1386 blocks if everyone signals, 1963
 blocks if 80% do, 3583 blocks if 60% do etc. Recall for comparison
 that assuming two blocks per minute there are 2880 blocks per day.
 
-When producing blocks using Octez baking daemon ``tezos-baker``, there
+When producing blocks using Octez baking daemon ``octez-baker``, there
 are two command-line options affecting toggle vote. The
 ``--liquidity-baking-toggle-vote <on|off|pass>`` option sets a static
 value to be used in each block. Note that this option must be placed
 **after** ``run`` on the command-line. Moreover, the path of a JSON file
 can be given to the ``--votefile <path>`` option
-e.g. ``tezos-baker-<protocol codename> run with local node
+e.g. ``octez-baker-<protocol codename> run with local node
 ~/.tezos-node alice --liquidity-baking-toggle-vote on --votefile
 "per_block_votes.json"``, or placed in a default location:
 ``per_block_votes.json`` in the current working directory. The content
diff --git a/docs/kathmandu/plugins.rst b/docs/kathmandu/plugins.rst
index eda740324e8f73ac4a30740faa8e560f84c83ad2..057080a8beb522feb7680669daf5c18ac8b2cd65 100644
--- a/docs/kathmandu/plugins.rst
+++ b/docs/kathmandu/plugins.rst
@@ -137,11 +137,11 @@ by a factor (currently fixed to 5%). In case of successful replacement, the old
 operation is re-classified as ``Outdated``.
 
 Concretely, a user can replace a successfully prechecked manager operation in the
-mempool, with the help of ``tezos-client``, using two methods :
+mempool, with the help of ``octez-client``, using two methods :
 
 - manually provide a higher fee to bump the "fee/gas limit" ratio by at least 5% for the new
   operation,
-- via option ``--replace``: In this case, ``tezos-client`` will automatically
+- via option ``--replace``: In this case, ``octez-client`` will automatically
   compute the minimal amount of fee for the second operation to be able to
   replace the one in the mempool.
 
@@ -227,9 +227,9 @@ The following parameters can be thus inspected and modified:
 For example, each command below modifies the provided parameter and resets all
 the others to their default values::
 
-   tezos-client rpc post /chains/main/mempool/filter with '{ "minimal_fees": "42" }'
-   tezos-client rpc post /chains/main/mempool/filter with '{ "replace_by_fee_factor": [ "23", "20" ] }'
-   tezos-client rpc post /chains/main/mempool/filter with '{ "max_prechecked_manager_operations": 7500 }'
+   octez-client rpc post /chains/main/mempool/filter with '{ "minimal_fees": "42" }'
+   octez-client rpc post /chains/main/mempool/filter with '{ "replace_by_fee_factor": [ "23", "20" ] }'
+   octez-client rpc post /chains/main/mempool/filter with '{ "max_prechecked_manager_operations": 7500 }'
 
 Changing filters default configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/kathmandu/sapling.rst b/docs/kathmandu/sapling.rst
index 9b991a4401891d4246426bdd330fc96b5535ab47..92a7d08a461d70193630de049c1dba6465d57a82 100644
--- a/docs/kathmandu/sapling.rst
+++ b/docs/kathmandu/sapling.rst
@@ -339,7 +339,7 @@ Client
 Wallet
 ^^^^^^
 
-tezos-client supports Sapling keys and can send
+octez-client supports Sapling keys and can send
 shielded transactions to smart contracts.
 
 The client supports two ways to generate a new Sapling spending key.
@@ -483,52 +483,52 @@ unshielding.
 ::
 
    # set up the sandbox
-   ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 0 &
-   eval `./src/bin_client/tezos-init-sandboxed-client.sh 1`
+   ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 &
+   eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
    tezos-activate-alpha
 
    # originate the contract with its initial empty sapling storage,
    # bake a block to include it.
    # { } represents an empty Sapling state.
-   tezos-client originate contract shielded-tez transferring 0 from bootstrap1 \
+   octez-client originate contract shielded-tez transferring 0 from bootstrap1 \
    running src/proto_014_PtKathma/lib_protocol/test/integration/michelson/contracts/sapling_contract.tz \
    --init '{ }' --burn-cap 3 &
-   tezos-client bake for bootstrap1
+   octez-client bake for bootstrap1
 
-   # as usual you can check the tezos-client manual
-   tezos-client sapling man
+   # as usual you can check the octez-client manual
+   octez-client sapling man
 
    # generate two shielded keys for Alice and Bob and use them for the shielded-tez contract
    # the memo size has to be indicated
-   tezos-client sapling gen key alice
-   tezos-client sapling use key alice for contract shielded-tez --memo-size 8
-   tezos-client sapling gen key bob
-   tezos-client sapling use key bob for contract shielded-tez --memo-size 8
+   octez-client sapling gen key alice
+   octez-client sapling use key alice for contract shielded-tez --memo-size 8
+   octez-client sapling gen key bob
+   octez-client sapling use key bob for contract shielded-tez --memo-size 8
 
    # generate an address for Alice to receive shielded tokens.
-   tezos-client sapling gen address alice
+   octez-client sapling gen address alice
    zet1AliceXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # Alice's address
 
 
    # shield 10 tez from bootstrap1 to alice
-   tezos-client sapling shield 10 from bootstrap1 to zet1AliceXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez --burn-cap 2 &
-   tezos-client bake for bootstrap1
-   tezos-client sapling get balance for alice in contract shielded-tez
+   octez-client sapling shield 10 from bootstrap1 to zet1AliceXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez --burn-cap 2 &
+   octez-client bake for bootstrap1
+   octez-client sapling get balance for alice in contract shielded-tez
 
    # generate an address for Bob to receive shielded tokens.
-   tezos-client sapling gen address bob
+   octez-client sapling gen address bob
    zet1BobXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # Bob's address
 
    # forge a shielded transaction from alice to bob that is saved to a file
-   tezos-client sapling forge transaction 10 from alice to zet1BobXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez
+   octez-client sapling forge transaction 10 from alice to zet1BobXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez
 
    # submit the shielded transaction from any transparent account
-   tezos-client sapling submit sapling_transaction from bootstrap2 using shielded-tez --burn-cap 1 &
-   tezos-client bake for bootstrap1
-   tezos-client sapling get balance for bob in contract shielded-tez
+   octez-client sapling submit sapling_transaction from bootstrap2 using shielded-tez --burn-cap 1 &
+   octez-client bake for bootstrap1
+   octez-client sapling get balance for bob in contract shielded-tez
 
    # unshield from bob to any transparent account
-   tezos-client sapling unshield 10 from bob to bootstrap1 using shielded-tez --burn-cap 1
+   octez-client sapling unshield 10 from bob to bootstrap1 using shielded-tez --burn-cap 1
    ctrl+z # to put the process in background
-   tezos-client bake for bootstrap1
+   octez-client bake for bootstrap1
    fg # to put resume the transfer
diff --git a/docs/kathmandu/transaction_rollups.rst b/docs/kathmandu/transaction_rollups.rst
index 55ba0f68e34879322846483d0260adeed4bdc441..4cf39120e02ba4070bbbc8b70f7cf0e18f454a5e 100644
--- a/docs/kathmandu/transaction_rollups.rst
+++ b/docs/kathmandu/transaction_rollups.rst
@@ -526,12 +526,12 @@ Getting Started
 Originating a Transaction Rollup
 ********************************
 
-The ``tezos-client`` has a dedicated command that any implicit account holder
+The ``octez-client`` has a dedicated command that any implicit account holder
 can use to originate a transaction rollup.
 
 .. code:: sh
 
-    tezos-client originate tx rollup ${tx_rollup_allias} from ${implicit_account_alias}
+    octez-client originate tx rollup ${tx_rollup_allias} from ${implicit_account_alias}
 
 where ``tx`` is an abbreviation for transaction.
 
@@ -546,7 +546,7 @@ prefixed by ``txr1``. For instance,::
 
 is a valid transaction rollup address.
 
-When using the ``tezos-client`` to originate a transaction rollup, it outputs
+When using the ``octez-client`` to originate a transaction rollup, it outputs
 the newly created address.
 
 Starting a Rollup Node
@@ -742,7 +742,7 @@ the deposit.
 
 .. code:: sh
 
-    tezos-client originate contract ${contract_alias} \
+    octez-client originate contract ${contract_alias} \
                  transferring 0 \
                  from ${alias} \
                  running ${path_to_contract} \
@@ -751,23 +751,23 @@ the deposit.
 Once the contract is originated, it becomes possible to deposit
 arbitrary tickets to the layer-2.
 
-Note that the ``tezos-client`` comes with facilities to generate and
+Note that the ``octez-client`` comes with facilities to generate and
 manipulate BLS keys (that are used to authenticate users on the
 layer-2, and to generate layer-2 addresses).
 
 .. code:: sh
 
     # generate a pair of public and secret keys
-    tezos-client bls gen keys ${alias}
+    octez-client bls gen keys ${alias}
     # display the keys (including the ``tz4`` hash)
-    tezos-client bls show address ${alias}
+    octez-client bls show address ${alias}
 
 So, to mint and deposit a ``ticket string`` whose contents is
 ``foobar``, one can make the following contract call.
 
 .. code:: sh
 
-    tezos-client transfer 0 from user to deposit_contract \
+    octez-client transfer 0 from user to deposit_contract \
              --arg '(Pair "foobar" ${qty} "${tz4_address}" "${tx_rollup_address}")' \
              --burn-cap 0.068
 
@@ -839,7 +839,7 @@ The ``--endpoint`` argument can be omitted if the rollup node is using
 the default RPC server address, that is ``localhost:9999``.
 
 Here, the source has to be an alias identifying a BLS pair of keys
-generated with ``tezos-client bls gen key``, while the destination can
+generated with ``octez-client bls gen key``, while the destination can
 either be an alias, or a ``tz4`` address directly.
 
 Similarly to Tezos, a transaction rollup also has a notion of L2
@@ -867,7 +867,7 @@ implicit account address directly.
 If a rollup node is run using the mode ``operator``, then once the
 commitment related to a withdraw order is finalized, the rollup node
 will “dispatch” the ticket to the ``l1_dst`` address. Once this is
-done, the owner of ``l1_dst`` can use a dedicated ``tezos-client``
+done, the owner of ``l1_dst`` can use a dedicated ``octez-client``
 command to transfer their tickets to a smart contract.
 
 To do so, it is necessary to provide the layer-1 with the actual
@@ -875,7 +875,7 @@ contents of the ticket, not just the ticket hash.
 
 .. code:: sh
 
-    tezos-client transfer ${qty} tickets \
+    octez-client transfer ${qty} tickets \
           from ${src} to ${sc_dst} \
           with entrypoint ${ep} \
           and contents ${micheline_contents} \
diff --git a/docs/kathmandu/voting.rst b/docs/kathmandu/voting.rst
index 59167edf388ecd77924168ee70770c14e3f4626a..649bc909668652dbd1110f587b1c60fcb2905e6a 100644
--- a/docs/kathmandu/voting.rst
+++ b/docs/kathmandu/voting.rst
@@ -247,12 +247,12 @@ quorum of the next vote.
 More details on the operations can be found in
 :src:`src/proto_014_PtKathma/lib_protocol/operation_repr.ml`.
 The binary format is described by
-``tezos-client describe unsigned operation``.
+``octez-client describe unsigned operation``.
 
 Client Commands
 ---------------
 
-The Octez client, ``tezos-client``, provides commands for basic exploration and
+The Octez client, ``octez-client``, provides commands for basic exploration and
 interaction with the amendment and voting process.
 
 
@@ -263,13 +263,13 @@ Tezos' client provides a command to show the status of a voting period.
 It displays different information for different kind of periods, as
 in the following samples::
 
-  $ tezos-client show voting period
+  $ octez-client show voting period
   Current period: "proposal"
   Blocks remaining until end of period: 59
   Current proposals:
   PsNa6jTtsRfbGaNSoYXNTNM5A7c3Lji22Yf2ZhpFUjQFC17iZVp 2,400,000 ꜩ
 
-  $ tezos-client show voting period
+  $ octez-client show voting period
   Current period: "exploration"
   Blocks remaining until end of period: 63
   Current proposal: PsNa6jTtsRfbGaNSoYXNTNM5A7c3Lji22Yf2ZhpFUjQFC17iZVp
@@ -280,7 +280,7 @@ in the following samples::
   Current participation 20.00%, necessary quorum 80.00%
   Current in favor 2,400,000 ꜩ, needed supermajority 1,920,000 ꜩ
 
-  $ tezos-client show voting period
+  $ octez-client show voting period
   Current period: "cooldown"
   Blocks remaining until end of period: 64
   Current proposal: PsNa6jTtsRfbGaNSoYXNTNM5A7c3Lji22Yf2ZhpFUjQFC17iZVp
@@ -297,7 +297,7 @@ Submit proposals
 
 During a proposal period, a list of proposals can be submitted with::
 
-    tezos-client submit proposals for <delegate> <proposal1> <proposal2> ...
+    octez-client submit proposals for <delegate> <proposal1> <proposal2> ...
 
 Remember that each delegate can submit a maximum of 20 protocol
 hashes and that duplicates count towards this total.
@@ -324,7 +324,7 @@ Submit ballots
 During either of the **exploration** or **promotion** periods,
 ballots can be submitted once with::
 
-    tezos-client submit ballot for <delegate> <proposal> <yay|nay|pass>
+    octez-client submit ballot for <delegate> <proposal> <yay|nay|pass>
 
 Further External Resources
 --------------------------
diff --git a/docs/lima/cli-commands.rst b/docs/lima/cli-commands.rst
index b1c68ec2f353e01e11c428d75ac875ebbe8caf61..cef4283180f9a44aab303901a00fa31938f155bd 100644
--- a/docs/lima/cli-commands.rst
+++ b/docs/lima/cli-commands.rst
@@ -8,7 +8,7 @@ using shell commands such as (:ref:`indicating the appropriate protocol <tezos_c
 
 ::
 
-   tezos-client -protocol <protocol_hash> man -verbosity 3
+   octez-client -protocol <protocol_hash> man -verbosity 3
 
 The rest of this page documents the protocol-dependent tools.
 The protocol-independent tools are documented :doc:`here <../shell/cli-commands>`.
@@ -20,7 +20,7 @@ Client manual
 =============
 
 .. raw:: html
-         :file: tezos-client.html
+         :file: octez-client.html
 
 
 .. _baker_manual_lima:
@@ -29,7 +29,7 @@ Baker manual
 ============
 
 .. raw:: html
-         :file: tezos-baker.html
+         :file: octez-baker.html
 
 
 .. _accuser_manual_lima:
@@ -38,4 +38,4 @@ Accuser manual
 ==============
 
 .. raw:: html
-         :file: tezos-accuser.html
+         :file: octez-accuser.html
diff --git a/docs/lima/consensus.rst b/docs/lima/consensus.rst
index eaeeb9ebb8aff7185f02e086d9a0de644098bf02..18d549e21b0c32c1607aac445f920c328745aae3 100644
--- a/docs/lima/consensus.rst
+++ b/docs/lima/consensus.rst
@@ -181,8 +181,8 @@ not the other way around.):
 - ``spendable balance`` is obtained with ``../context/contracts/<pkh>/balance``
 
 Delegates can set an upper limit to their frozen deposits with the
-command ``tezos-client set deposits limit for <delegate> to
-<deposit_limit>``, and unset this limit with the command ``tezos-client
+command ``octez-client set deposits limit for <delegate> to
+<deposit_limit>``, and unset this limit with the command ``octez-client
 unset deposits limit for <delegate>``. These commands are implemented
 using a new manager operation ``Set_deposits_limit``. When emitting such a
 command in cycle ``c``, it affects the active stake for cycles starting
diff --git a/docs/lima/global_constants.rst b/docs/lima/global_constants.rst
index 9b8286f906b59bdf722aee25834e6c6a0bbeb968..383f3e0e3fd2cb02c4edd2ad17802b5c9464427f 100644
--- a/docs/lima/global_constants.rst
+++ b/docs/lima/global_constants.rst
@@ -26,12 +26,12 @@ The new ``register_global_constant`` operation includes an object with a
 single key ``"value"``, the value of which is the Micheline expression
 to be registered.
 
-You can submit this operation conveniently through a new :doc:`tezos-client <cli-commands>` command.
+You can submit this operation conveniently through a new :doc:`octez-client <cli-commands>` command.
 For example, the command:
 
 .. code:: sh
 
-    tezos-client register global constant "999" from bootstrap1 --burn-cap 0.017
+    octez-client register global constant "999" from bootstrap1 --burn-cap 0.017
 
 would result in the output:
 
@@ -44,7 +44,7 @@ would result in the output:
    Operation hash is 'onsFknW5iWa6eiTYqAghY4peQZ7JYQUJg5fR8MwAQkMKjXfNqGf'
    NOT waiting for the operation to be included.
    Use command
-     tezos-client wait for onsFknW5iWa6eiTYqAghY4peQZ7JYQUJg5fR8MwAQkMKjXfNqGf to be included --confirmations 5 --branch BLockGenesisGenesisGenesisGenesisGenesisCCCCCeZiLHU
+     octez-client wait for onsFknW5iWa6eiTYqAghY4peQZ7JYQUJg5fR8MwAQkMKjXfNqGf to be included --confirmations 5 --branch BLockGenesisGenesisGenesisGenesisGenesisCCCCCeZiLHU
    and/or an external block explorer to make sure that it has been included.
    This sequence of operations was run:
      Manager signed operations:
diff --git a/docs/lima/liquidity_baking.rst b/docs/lima/liquidity_baking.rst
index 980530eea74dc9f82fe699ac14a3e3d99f82853b..17c8a588cbff2ff0f36f3554feaa250c8e48d3bc 100644
--- a/docs/lima/liquidity_baking.rst
+++ b/docs/lima/liquidity_baking.rst
@@ -62,13 +62,13 @@ non-abstaining blocks, about 1386 blocks if everyone signals, 1963
 blocks if 80% do, 3583 blocks if 60% do etc. Recall for comparison
 that assuming two blocks per minute there are 2880 blocks per day.
 
-When producing blocks using Octez baking daemon ``tezos-baker``, there
+When producing blocks using Octez baking daemon ``octez-baker``, there
 are two command-line options affecting toggle vote. The
 ``--liquidity-baking-toggle-vote <on|off|pass>`` option sets a static
 value to be used in each block. Note that this option must be placed
 **after** ``run`` on the command-line. Moreover, the path of a JSON file
 can be given to the ``--votefile <path>`` option
-e.g. ``tezos-baker-<protocol codename> run with local node
+e.g. ``octez-baker-<protocol codename> run with local node
 ~/.tezos-node alice --liquidity-baking-toggle-vote on --votefile
 "per_block_votes.json"``, or placed in a default location:
 ``per_block_votes.json`` in the current working directory. The content
diff --git a/docs/lima/plugins.rst b/docs/lima/plugins.rst
index 756172098d859ecae8c9edd8efe6e53937d75e78..3972ee212532b2f41103cd1189ffbda64fca30af 100644
--- a/docs/lima/plugins.rst
+++ b/docs/lima/plugins.rst
@@ -134,11 +134,11 @@ by a factor (currently fixed to 5%). In case of successful replacement, the old
 operation is re-classified as ``Outdated``.
 
 Concretely, a user can replace a successfully prechecked manager operation in the
-mempool, with the help of ``tezos-client``, using two methods :
+mempool, with the help of ``octez-client``, using two methods :
 
 - manually provide a higher fee to bump the "fee/gas limit" ratio by at least 5% for the new
   operation,
-- via option ``--replace``: In this case, ``tezos-client`` will automatically
+- via option ``--replace``: In this case, ``octez-client`` will automatically
   compute the minimal amount of fee for the second operation to be able to
   replace the one in the mempool.
 
@@ -223,9 +223,9 @@ The following parameters can be thus inspected and modified:
 For example, each command below modifies the provided parameter and resets all
 the others to their default values::
 
-   tezos-client rpc post /chains/main/mempool/filter with '{ "minimal_fees": "42" }'
-   tezos-client rpc post /chains/main/mempool/filter with '{ "replace_by_fee_factor": [ "23", "20" ] }'
-   tezos-client rpc post /chains/main/mempool/filter with '{ "max_prechecked_manager_operations": 7500 }'
+   octez-client rpc post /chains/main/mempool/filter with '{ "minimal_fees": "42" }'
+   octez-client rpc post /chains/main/mempool/filter with '{ "replace_by_fee_factor": [ "23", "20" ] }'
+   octez-client rpc post /chains/main/mempool/filter with '{ "max_prechecked_manager_operations": 7500 }'
 
 Changing filters default configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/lima/sapling.rst b/docs/lima/sapling.rst
index b95c77411b744e325b722ad484d32333aba6f611..ddc03c08927d3090548c303abdb9e7bb6fcd1e74 100644
--- a/docs/lima/sapling.rst
+++ b/docs/lima/sapling.rst
@@ -339,7 +339,7 @@ Client
 Wallet
 ^^^^^^
 
-tezos-client supports Sapling keys and can send
+octez-client supports Sapling keys and can send
 shielded transactions to smart contracts.
 
 The client supports two ways to generate a new Sapling spending key.
@@ -483,52 +483,52 @@ unshielding.
 ::
 
    # set up the sandbox
-   ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 0 &
-   eval `./src/bin_client/tezos-init-sandboxed-client.sh 1`
+   ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 &
+   eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
    tezos-activate-alpha
 
    # originate the contract with its initial empty sapling storage,
    # bake a block to include it.
    # { } represents an empty Sapling state.
-   tezos-client originate contract shielded-tez transferring 0 from bootstrap1 \
+   octez-client originate contract shielded-tez transferring 0 from bootstrap1 \
    running src/proto_015_PtLimaPt/lib_protocol/test/integration/michelson/contracts/sapling_contract.tz \
    --init '{ }' --burn-cap 3 &
-   tezos-client bake for bootstrap1
+   octez-client bake for bootstrap1
 
-   # as usual you can check the tezos-client manual
-   tezos-client sapling man
+   # as usual you can check the octez-client manual
+   octez-client sapling man
 
    # generate two shielded keys for Alice and Bob and use them for the shielded-tez contract
    # the memo size has to be indicated
-   tezos-client sapling gen key alice
-   tezos-client sapling use key alice for contract shielded-tez --memo-size 8
-   tezos-client sapling gen key bob
-   tezos-client sapling use key bob for contract shielded-tez --memo-size 8
+   octez-client sapling gen key alice
+   octez-client sapling use key alice for contract shielded-tez --memo-size 8
+   octez-client sapling gen key bob
+   octez-client sapling use key bob for contract shielded-tez --memo-size 8
 
    # generate an address for Alice to receive shielded tokens.
-   tezos-client sapling gen address alice
+   octez-client sapling gen address alice
    zet1AliceXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # Alice's address
 
 
    # shield 10 tez from bootstrap1 to alice
-   tezos-client sapling shield 10 from bootstrap1 to zet1AliceXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez --burn-cap 2 &
-   tezos-client bake for bootstrap1
-   tezos-client sapling get balance for alice in contract shielded-tez
+   octez-client sapling shield 10 from bootstrap1 to zet1AliceXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez --burn-cap 2 &
+   octez-client bake for bootstrap1
+   octez-client sapling get balance for alice in contract shielded-tez
 
    # generate an address for Bob to receive shielded tokens.
-   tezos-client sapling gen address bob
+   octez-client sapling gen address bob
    zet1BobXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # Bob's address
 
    # forge a shielded transaction from alice to bob that is saved to a file
-   tezos-client sapling forge transaction 10 from alice to zet1BobXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez
+   octez-client sapling forge transaction 10 from alice to zet1BobXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX using shielded-tez
 
    # submit the shielded transaction from any transparent account
-   tezos-client sapling submit sapling_transaction from bootstrap2 using shielded-tez --burn-cap 1 &
-   tezos-client bake for bootstrap1
-   tezos-client sapling get balance for bob in contract shielded-tez
+   octez-client sapling submit sapling_transaction from bootstrap2 using shielded-tez --burn-cap 1 &
+   octez-client bake for bootstrap1
+   octez-client sapling get balance for bob in contract shielded-tez
 
    # unshield from bob to any transparent account
-   tezos-client sapling unshield 10 from bob to bootstrap1 using shielded-tez --burn-cap 1
+   octez-client sapling unshield 10 from bob to bootstrap1 using shielded-tez --burn-cap 1
    ctrl+z # to put the process in background
-   tezos-client bake for bootstrap1
+   octez-client bake for bootstrap1
    fg # to put resume the transfer
diff --git a/docs/lima/transaction_rollups.rst b/docs/lima/transaction_rollups.rst
index 8a1b4f2142c254a21297a5a5099951908169bc53..c09276365d122fd951ecdebfd6a1b65a4485f8a4 100644
--- a/docs/lima/transaction_rollups.rst
+++ b/docs/lima/transaction_rollups.rst
@@ -532,12 +532,12 @@ Getting Started
 Originating a Transaction Rollup
 ********************************
 
-The ``tezos-client`` has a dedicated command that any implicit account holder
+The ``octez-client`` has a dedicated command that any implicit account holder
 can use to originate a transaction rollup.
 
 .. code:: sh
 
-    tezos-client originate tx rollup ${tx_rollup_allias} from ${implicit_account_alias}
+    octez-client originate tx rollup ${tx_rollup_allias} from ${implicit_account_alias}
 
 where ``tx`` is an abbreviation for transaction.
 
@@ -552,7 +552,7 @@ prefixed by ``txr1``. For instance,::
 
 is a valid transaction rollup address.
 
-When using the ``tezos-client`` to originate a transaction rollup, it outputs
+When using the ``octez-client`` to originate a transaction rollup, it outputs
 the newly created address.
 
 Starting a Rollup Node
@@ -748,7 +748,7 @@ the deposit.
 
 .. code:: sh
 
-    tezos-client originate contract ${contract_alias} \
+    octez-client originate contract ${contract_alias} \
                  transferring 0 \
                  from ${alias} \
                  running ${path_to_contract} \
@@ -757,23 +757,23 @@ the deposit.
 Once the contract is originated, it becomes possible to deposit
 arbitrary tickets to the layer-2.
 
-Note that the ``tezos-client`` comes with facilities to generate and
+Note that the ``octez-client`` comes with facilities to generate and
 manipulate BLS keys (that are used to authenticate users on the
 layer-2, and to generate layer-2 addresses).
 
 .. code:: sh
 
     # generate a pair of public and secret keys
-    tezos-client bls gen keys ${alias}
+    octez-client bls gen keys ${alias}
     # display the keys (including the ``tz4`` hash)
-    tezos-client bls show address ${alias}
+    octez-client bls show address ${alias}
 
 So, to mint and deposit a ``ticket string`` whose contents is
 ``foobar``, one can make the following contract call.
 
 .. code:: sh
 
-    tezos-client transfer 0 from user to deposit_contract \
+    octez-client transfer 0 from user to deposit_contract \
              --arg '(Pair "foobar" ${qty} "${tz4_address}" "${tx_rollup_address}")' \
              --burn-cap 0.068
 
@@ -845,7 +845,7 @@ The ``--endpoint`` argument can be omitted if the rollup node is using
 the default RPC server address, that is ``localhost:9999``.
 
 Here, the source has to be an alias identifying a BLS pair of keys
-generated with ``tezos-client bls gen key``, while the destination can
+generated with ``octez-client bls gen key``, while the destination can
 either be an alias, or a ``tz4`` address directly.
 
 Similarly to Tezos, a transaction rollup also has a notion of L2
@@ -873,7 +873,7 @@ implicit account address directly.
 If a rollup node is run using the mode ``operator``, then once the
 commitment related to a withdraw order is finalized, the rollup node
 will “dispatch” the ticket to the ``l1_dst`` address. Once this is
-done, the owner of ``l1_dst`` can use a dedicated ``tezos-client``
+done, the owner of ``l1_dst`` can use a dedicated ``octez-client``
 command to transfer their tickets to a smart contract.
 
 To do so, it is necessary to provide the layer-1 with the actual
@@ -881,7 +881,7 @@ contents of the ticket, not just the ticket hash.
 
 .. code:: sh
 
-    tezos-client transfer ${qty} tickets \
+    octez-client transfer ${qty} tickets \
           from ${src} to ${sc_dst} \
           with entrypoint ${ep} \
           and contents ${micheline_contents} \
diff --git a/docs/lima/voting.rst b/docs/lima/voting.rst
index eef0115565aa6c1215d605e48055d65f5787474f..92a13cc6d029af91924619f6af926c26b93a77db 100644
--- a/docs/lima/voting.rst
+++ b/docs/lima/voting.rst
@@ -246,12 +246,12 @@ quorum of the next vote.
 More details on the operations can be found in
 :src:`src/proto_015_PtLimaPt/lib_protocol/operation_repr.ml`.
 The binary format is described by
-``tezos-client describe unsigned operation``.
+``octez-client describe unsigned operation``.
 
 Client Commands
 ---------------
 
-The Octez client, ``tezos-client``, provides commands for basic exploration and
+The Octez client, ``octez-client``, provides commands for basic exploration and
 interaction with the amendment and voting process.
 
 
@@ -262,13 +262,13 @@ Tezos' client provides a command to show the status of a voting period.
 It displays different information for different kind of periods, as
 in the following samples::
 
-  $ tezos-client show voting period
+  $ octez-client show voting period
   Current period: "proposal"
   Blocks remaining until end of period: 59
   Current proposals:
   PsNa6jTtsRfbGaNSoYXNTNM5A7c3Lji22Yf2ZhpFUjQFC17iZVp 2,400,000 ꜩ
 
-  $ tezos-client show voting period
+  $ octez-client show voting period
   Current period: "exploration"
   Blocks remaining until end of period: 63
   Current proposal: PsNa6jTtsRfbGaNSoYXNTNM5A7c3Lji22Yf2ZhpFUjQFC17iZVp
@@ -279,7 +279,7 @@ in the following samples::
   Current participation 20.00%, necessary quorum 80.00%
   Current in favor 2,400,000 ꜩ, needed supermajority 1,920,000 ꜩ
 
-  $ tezos-client show voting period
+  $ octez-client show voting period
   Current period: "cooldown"
   Blocks remaining until end of period: 64
   Current proposal: PsNa6jTtsRfbGaNSoYXNTNM5A7c3Lji22Yf2ZhpFUjQFC17iZVp
@@ -296,7 +296,7 @@ Submit proposals
 
 During a proposal period, a list of proposals can be submitted with::
 
-    tezos-client submit proposals for <delegate> <proposal1> <proposal2> ...
+    octez-client submit proposals for <delegate> <proposal1> <proposal2> ...
 
 Remember that each delegate can submit a maximum of 20 protocol
 hashes and that duplicates count towards this total.
@@ -323,7 +323,7 @@ Submit ballots
 During either of the **exploration** or **promotion** periods,
 ballots can be submitted once with::
 
-    tezos-client submit ballot for <delegate> <proposal> <yay|nay|pass>
+    octez-client submit ballot for <delegate> <proposal> <yay|nay|pass>
 
 Further External Resources
 --------------------------
diff --git a/docs/michelson/michelson-meta.yaml b/docs/michelson/michelson-meta.yaml
index be0f550b55a1d74375d90130844cbee2c43c5ef0..309163f9207e05c2688156422a26c308d52d272e 100644
--- a/docs/michelson/michelson-meta.yaml
+++ b/docs/michelson/michelson-meta.yaml
@@ -2258,7 +2258,7 @@ types:
       code. Instead, they must be created using ``EMPTY_BIG_MAP`` and
       manipulated using ``GET``, ``UPDATE`` and ``MEM``. However,
       literal ``big_map``\ s are used when originating and calling
-      contracts using ``tezos-client``.
+      contracts using ``octez-client``.
 
       Values of the ``big_map`` type cannot be serialized using ``PACK``.
     examples:
diff --git a/docs/shell/cli-commands.rst b/docs/shell/cli-commands.rst
index 2e63c317b52d238253cc1a634e6a78b42a35d1e9..a3ad661720977a987fd1e3bf6296185faa5b3e92 100644
--- a/docs/shell/cli-commands.rst
+++ b/docs/shell/cli-commands.rst
@@ -8,7 +8,7 @@ obtain similar pages using shell commands such as:
 
 ::
 
-   tezos-admin-client man -verbosity 3
+   octez-admin-client man -verbosity 3
 
 The rest of this page documents the protocol-independent tools.
 The protocol-dependent tools are documented :doc:`here <../active/cli-commands>`.
@@ -20,7 +20,7 @@ Admin-client manual
 ===================
 
 .. raw:: html
-         :file: ../api/tezos-admin-client.html
+         :file: ../api/octez-admin-client.html
 
 
 .. _signer_manual:
@@ -29,7 +29,7 @@ Signer manual
 =============
 
 .. raw:: html
-         :file: ../api/tezos-signer.html
+         :file: ../api/octez-signer.html
 
 
 .. _benchmark_tool_manual:
@@ -38,7 +38,7 @@ Benchmark tool manual
 =====================
 
 .. raw:: html
-         :file: ../api/tezos-snoop.html
+         :file: ../api/octez-snoop.html
 
 
 .. _codec_manual:
@@ -47,7 +47,7 @@ Codec manual
 ============
 
 .. raw:: html
-         :file: ../api/tezos-codec.html
+         :file: ../api/octez-codec.html
 
 
 .. _node_manual:
@@ -58,7 +58,7 @@ Node manual
 The command line of the Tezos node is not currently documented as a web page, but
 you can obtain it in Unix manual format by running the node with no arguments::
 
-  tezos-node
+  octez-node
 
 The above command briefly shows the available node commands.
 Each command accepts its own set of options and arguments, see :doc:`../user/node-configuration`.
diff --git a/docs/shell/micheline.rst b/docs/shell/micheline.rst
index 5926f4d7b042311266b6f2a8bfa002348bc8843f..2196615cf59c8b3a700027886759d7d76e978094 100644
--- a/docs/shell/micheline.rst
+++ b/docs/shell/micheline.rst
@@ -213,7 +213,7 @@ encoding depends on the way primitives are encoded.
 
 The documentation for the binary encoding specialized to Michelson
 primitives of the Alpha protocol can be generated by the command
-``tezos-codec describe alpha.script.expr binary schema``.
+``octez-codec describe alpha.script.expr binary schema``.
 
 Usage of the OCaml Micheline library
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/shell/p2p.rst b/docs/shell/p2p.rst
index 1eddd3f9527a73ba782200f346e1e83f59bb54a8..2b69b377b3198eb35e363a1a558000884da30c84 100644
--- a/docs/shell/p2p.rst
+++ b/docs/shell/p2p.rst
@@ -83,7 +83,7 @@ handled.
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The welcome worker takes care of filtering all incoming connections using two
-static lists of addresses handled by ``tezos-admin-client`` and a system
+static lists of addresses handled by ``octez-admin-client`` and a system
 table that is handled automatically by the P2P layer. The node administrator can
 block (blacklist) or enable (whitelist) individual IP addresses, while the P2P layer is in charge of
 temporarily banning (greylist) IP addresses and peers who misbehave. The delay to remove an
@@ -91,7 +91,7 @@ IP address from the greylist table is defined by the configuration variable
 ``greylist_timeout``, while peers that are greylisted are periodically removed.
 
 The node administrator can also flush greylist tables with the
-``tezos-admin-client``.
+``octez-admin-client``.
 
 The node administrator can also choose to unban peers and addresses that
 were manually banned or accidentally greylisted.
diff --git a/docs/shell/rpc_introduction.rst.inc b/docs/shell/rpc_introduction.rst.inc
index acb6d7d76bf060524b95af5bed7c31dbc94c4f4a..93abbd5534b8199bef1dcd16a144ab6c63c6c4a1 100644
--- a/docs/shell/rpc_introduction.rst.inc
+++ b/docs/shell/rpc_introduction.rst.inc
@@ -12,12 +12,12 @@ RPCs - Index
 
 Note that the RPCs served under a given prefix can also be listed using the client, e.g.::
 
-    tezos-client rpc list /chains/main/levels
+    octez-client rpc list /chains/main/levels
 
 Any RPC endpoint may also be described, using the ``describe`` RPC to
 retrieve all JSON and binary schemas, e.g.::
 
-    tezos-client rpc get /describe/chains/main/chain_id
+    octez-client rpc get /describe/chains/main/chain_id
 
 Protocol
 ========
diff --git a/docs/user/fa12.rst b/docs/user/fa12.rst
index 594bcb2b12d99777648dc1d4e256e00676ea0892..89aa753fa077aa03ff905e970df436fc27a97545 100644
--- a/docs/user/fa12.rst
+++ b/docs/user/fa12.rst
@@ -31,14 +31,14 @@ implements the standard, and both have been verified using the `Mi-Cho-Coq
 <https://gitlab.com/nomadic-labs/mi-cho-coq/>`_ framework (see related :gl:`merge
 request <nomadic-labs/mi-cho-coq!97>`).
 
-The ``tezos-client`` supports this standard with specific commands that allow
+The ``octez-client`` supports this standard with specific commands that allow
 the user to avoid calling FA1.2 contracts using entrypoints and forging
 Michelson arguments. Moreover, it supports calling `views
 <https://gitlab.com/tezos/tzip/-/blob/master/proposals/tzip-4/tzip-4.md#view-entrypoints>`_
 (the ``get*`` entrypoints) offchain, without doing an explicit transaction that
 returns a value on a given contract.
 
-``tezos-client man fa1.2`` gives a complete list of the `built-in commands
+``octez-client man fa1.2`` gives a complete list of the `built-in commands
 <https://tezos.gitlab.io/alpha/cli-commands.html#client-manual>`_ to
 interact with FA1.2-compatible contracts, with details about the syntax of each
 one.
@@ -47,7 +47,7 @@ Checking whether a contract is FA1.2 compatible
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 To check whether a contract has an FA1.2-compatible interface, use
-``tezos-client check contract <alias or KT1> implements fa1.2``. The underlying
+``octez-client check contract <alias or KT1> implements fa1.2``. The underlying
 function is actually used before invoking any FA1.2 command.
 
 Managing tokens
@@ -57,13 +57,13 @@ An FA1.2 contract features two main functionalities: transferring
 tokens from an address to another, and allowing another account to
 transfer an amount of tokens from its own address to any third party.
 
-- ``tezos-client from fa1.2 contract <fa1.2> transfer <amount> from
+- ``octez-client from fa1.2 contract <fa1.2> transfer <amount> from
   <sender> to <receiver>`` transfers a given ``amount`` of tokens from
   ``sender`` to ``receiver``. In that case ``sender`` is the caller of
   the contract. If ``--as <operator>`` is given to the command,
   operator becomes the caller of the contract (and must have allowance
   on ``sender``'s account, as explained).
-- ``tezos-client from fa1.2 contract <fa1.2> approve <amount> as
+- ``octez-client from fa1.2 contract <fa1.2> approve <amount> as
   <sender> from <operator>`` allows operator to transfer a given
   ``amount`` of tokens from ``sender`` to any other account: this is
   the allowance described above.
@@ -76,9 +76,9 @@ other account.
 Batch transfer of tokens
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-As for tez, ``tezos-client`` supports batch transfer of tokens from a single
+As for tez, ``octez-client`` supports batch transfer of tokens from a single
 source to multiple recipients on multiple FA1.2 contracts, using the command
-``tezos-client multiple fa1.2 transfers from <account> using <json>``.
+``octez-client multiple fa1.2 transfers from <account> using <json>``.
 
 To be on par with batch transactions, only one account can be the source of the
 transfer. However, thanks to the approval mechanism, this command takes an
@@ -99,7 +99,7 @@ transfers is the following:
     ..
    ]
 
-The complete schema can be inspected via ``tezos-codec describe
+The complete schema can be inspected via ``octez-codec describe
 <protocol_name>.fa1.2.token_transfer json schema`` (where ``<protocol_name>``
 can be replaced with e.g. ``alpha`` or ``014-PtKathma``).
 
@@ -115,8 +115,8 @@ total supply of tokens of the contract. These entrypoints are implemented as
 they give back the requested information as a transaction on a given contract,
 assuming its parameter is compatible.
 
-``tezos-client`` supports calling these entrypoints completely
-offchain. One can get a balance using ``tezos-client from fa1.2
+``octez-client`` supports calling these entrypoints completely
+offchain. One can get a balance using ``octez-client from fa1.2
 contract <contract> get balance for <account>``, or the allowance
-using ``tezos-client from fa1.2 contract <contract> get allowance on
+using ``octez-client from fa1.2 contract <contract> get allowance on
 <owner> as <operator>``.
diff --git a/docs/user/history_modes.rst b/docs/user/history_modes.rst
index d1a2e00d00c01485bc41aceba88f803da5fc40c8..32886dbe155aac49ba89229ea29bee992014f9a7 100644
--- a/docs/user/history_modes.rst
+++ b/docs/user/history_modes.rst
@@ -105,7 +105,7 @@ To run a ``full`` node you can either use the command line arguments:
 
 .. code-block:: console
 
-   tezos-node run --history-mode full
+   octez-node run --history-mode full
 
 or use your configuration file as described in :doc:`here <node-configuration>`:
 
@@ -121,7 +121,7 @@ You can then verify that your history mode is set to full by using the checkpoin
 
 .. code-block:: console
 
-   tezos-client rpc get /chains/main/checkpoint
+   octez-client rpc get /chains/main/checkpoint
 
 .. code-block:: json
 
@@ -141,7 +141,7 @@ To run a ``rolling`` node you can either use the command line arguments:
 
 .. code-block:: console
 
-   tezos-node run --history-mode experimental-rolling
+   octez-node run --history-mode experimental-rolling
 
 or use your configuration file as described in :doc:`here <node-configuration>`:
 
@@ -165,7 +165,7 @@ Setting up a node in archive mode
 ---------------------------------
 
 To run an ``archive`` node you can use the command line arguments:
-``$ tezos-node run --history-mode archive``
+``$ octez-node run --history-mode archive``
 
 Or the configuration file:
 ``{ "shell": {"history_mode": "archive"} }``
@@ -255,6 +255,6 @@ there are some restrictions when switching from one mode to another.
 +---------+---------+------+---------+
 
 (*) Switching from a ``full`` node to an ``archive`` one is possible
-using the ``reconstruct`` feature. To do so, run ``tezos-node
+using the ``reconstruct`` feature. To do so, run ``octez-node
 reconstruct`` on your node. Note that the storage reconstruction is a
 long process that, on the main network, may requires days to complete.
diff --git a/docs/user/key-management.rst b/docs/user/key-management.rst
index 31de53ffacf30be5d974cddc1008d8465823f0d5..429b21bcd6b3c508eca7d163caba24e40f91f91e 100644
--- a/docs/user/key-management.rst
+++ b/docs/user/key-management.rst
@@ -33,19 +33,19 @@ Tezos Wallet app
 Now on the client we can import the keys (make sure the device is
 in the Tezos Wallet app)::
 
-   ./tezos-client list connected ledgers
+   ./octez-client list connected ledgers
 
 You can follow the instructions to import the ledger private key and
 you can choose between the root or a derived address.
 We can confirm the addition by listing known addresses::
 
-   ./tezos-client import secret key my_ledger ledger://tz1XXXXXXXXXX
-   ./tezos-client list known addresses
+   ./octez-client import secret key my_ledger ledger://tz1XXXXXXXXXX
+   ./octez-client list known addresses
 
 Optional: we can check that our ledger signs correctly using the
 following command and confirming on the device::
 
-   tezos-client show ledger path ledger://tz1XXXXXXXXXX
+   octez-client show ledger path ledger://tz1XXXXXXXXXX
 
 The address can now be used as any other with the exception that
 during an operation the device will prompt you to confirm when it's
@@ -69,7 +69,7 @@ block signed.
 If you have tried the app on some network and want to
 use it on another network you might need to reset this level with the command::
 
-   tezos-client setup ledger to bake for my_ledger
+   octez-client setup ledger to bake for my_ledger
 
 More details can be found on the `Tezos Ledger app
 <https://github.com/obsidiansystems/ledger-app-tezos>`_.
@@ -82,16 +82,16 @@ Signer
 Another solution to decouple the node from the signing process is to
 use the *remote signer*.
 Among the signing scheme supported by the client, that we can list
-with ``tezos-client list signing schemes``, there are ``unix``,
+with ``octez-client list signing schemes``, there are ``unix``,
 ``tcp``, ``http`` and ``https``.
 These schemes send signing requests over their respective
-communication channel towards the ``tezos-signer``, which can run on a
+communication channel towards the ``octez-signer``, which can run on a
 different machine that stores the secret key.
 
 Signer requests
 ~~~~~~~~~~~~~~~
 
-The ``tezos-signer`` handles signing requests with the following format::
+The ``octez-signer`` handles signing requests with the following format::
 
     <magic_byte><data>
 
@@ -133,19 +133,19 @@ In our home server we can generate a new key pair (or import one from a
 :ref:`Ledger<ledger>`) and launch a signer that signs operations using these
 keys.
 The new keys are store in ``$HOME/.tezos-signer`` in the same format
-as ``tezos-client``.
+as ``octez-client``.
 On our internet facing vps we can then import a key with the address
 of the signer.
 
 ::
 
-   home~$ tezos-signer gen keys alice
+   home~$ octez-signer gen keys alice
    home~$ cat ~/.tezos-signer/public_key_hashs
    [ { "name": "alice", "value": "tz1abc..." } ]
-   home~$ tezos-signer launch socket signer -a home
+   home~$ octez-signer launch socket signer -a home
 
-   vps~$ tezos-client import secret key alice tcp://home:7732/tz1abc...
-   vps~$ tezos-client sign bytes 0x03 for alice
+   vps~$ octez-client import secret key alice tcp://home:7732/tz1abc...
+   vps~$ octez-client sign bytes 0x03 for alice
 
 Every time the client on *vps* needs to sign an operation for
 *alice*, it sends a signature request to the remote signer on
@@ -155,30 +155,30 @@ However, with the above method, the address of the signer is hard-coded into the
 Consequently, if we ever have to move the signer to another machine or access it using another protocol, we will have to change all the remote keys.
 A more flexible method is to only register a key as being remote, and separately supply the address of the signer uisng the `-R` option::
 
-   vps~$ tezos-client -R 'tcp://home:7732' import secret key alice remote:tz1abc...
-   vps~$ tezos-client -R 'tcp://home:7732' sign bytes 0x03 for alice
+   vps~$ octez-client -R 'tcp://home:7732' import secret key alice remote:tz1abc...
+   vps~$ octez-client -R 'tcp://home:7732' sign bytes 0x03 for alice
 
 Alternatively, the address of the signer can be recorded in environment variables::
 
    vps~$ export TEZOS_SIGNER_TCP_HOST=home
    vps~$ export TEZOS_SIGNER_TCP_PORT=7732
-   vps~$ tezos-client import secret key alice remote:tz1abc...
-   vps~$ tezos-client sign bytes 0x03 for alice
+   vps~$ octez-client import secret key alice remote:tz1abc...
+   vps~$ octez-client sign bytes 0x03 for alice
 
 All the above methods can be retargeted to the other signing schemes, for instance, ``http``::
 
-   home~$ tezos-signer launch http signer -a home
+   home~$ octez-signer launch http signer -a home
 
-   vps~$ tezos-client import secret key alice http://home:7732/tz1abc...
-   vps~$ tezos-client sign bytes 0x03 for alice
+   vps~$ octez-client import secret key alice http://home:7732/tz1abc...
+   vps~$ octez-client sign bytes 0x03 for alice
 
-   vps~$ tezos-client -R 'http://home:7732' import secret key alice remote:tz1abc...
-   vps~$ tezos-client -R 'http://home:7732' sign bytes 0x03 for alice
+   vps~$ octez-client -R 'http://home:7732' import secret key alice remote:tz1abc...
+   vps~$ octez-client -R 'http://home:7732' sign bytes 0x03 for alice
 
    vps~$ export TEZOS_SIGNER_HTTP_HOST=home
    vps~$ export TEZOS_SIGNER_HTTP_PORT=7732
-   vps~$ tezos-client import secret key alice remote:tz1abc...
-   vps~$ tezos-client sign bytes 0x03 for alice
+   vps~$ octez-client import secret key alice remote:tz1abc...
+   vps~$ octez-client sign bytes 0x03 for alice
 
 The complete list of environment variables for connecting to the remote signer is:
 
@@ -212,14 +212,14 @@ signer and it is not used as a Tezos account.
 
 ::
 
-   vps~$ tezos-client gen keys vps
+   vps~$ octez-client gen keys vps
    vps~$ cat ~/.tezos-client/public_keys
    [ { "name": "vps",
        "value":
           "unencrypted:edpk123456789" } ]
 
-   home~$ tezos-signer add authorized key edpk123456789 --name vps
-   home~$ tezos-signer --require-authentication launch socket signer -a home-ip
+   home~$ octez-signer add authorized key edpk123456789 --name vps
+   home~$ octez-signer --require-authentication launch socket signer -a home-ip
 
 All request are now signed with the *vps* key thus you are
 guaranteed authenticity and integrity.
@@ -240,7 +240,7 @@ This feature is also included in some wallets.
 If you have any questions or issues, refer to that page or to the `Tezos
 foundation <https://tezos.foundation/>`_ for support.
 
-You may also use ``tezos-client`` to activate your account, **be
+You may also use ``octez-client`` to activate your account, **be
 warned that you should have a very good understanding of key
 management in Tezos and be familiar with the command-line.**
 The first step is to recover your private key using the following
@@ -252,7 +252,7 @@ command which will ask for:
 
 ::
 
-   tezos-client import fundraiser key alice
+   octez-client import fundraiser key alice
 
 Once you insert all the required information, the client computes
 your secret key and it asks to create a new password to store your
@@ -264,7 +264,7 @@ foundation.
 
 ::
 
-   tezos-client activate fundraiser account alice with <code>
+   octez-client activate fundraiser account alice with <code>
 
 Like explained above, your keys are stored under ``~/.tezos-client``.
 We strongly advice you to first **make a backup** and then
@@ -273,4 +273,4 @@ transfer your tokens to a new pair of keys imported from a ledger (see
 
 Check the balance with::
 
-    tezos-client get balance for alice
+    octez-client get balance for alice
diff --git a/docs/user/light.rst b/docs/user/light.rst
index 0e82f8d379b9798920d16b069d9e38f0d7ededc7..f42dda6af5d4798305b82ae14bb846c07f986683 100644
--- a/docs/user/light.rst
+++ b/docs/user/light.rst
@@ -1,7 +1,7 @@
 Light mode
 ----------
 
-The ``tezos-client`` described in
+The ``octez-client`` described in
 :ref:`its own tutorial <howtouse_tezos_client>` forwards all RPCs to a node.
 This page describes the *light* mode, a mode where the client
 performs protocol RPCs locally; like the :doc:`proxy mode<proxy>`.
@@ -24,7 +24,7 @@ Executing commands in light mode
 
 The CLI interface of the client in light mode (the *light client* in short)
 is the same as the default client. To turn light mode ON, you must
-pass two arguments to ``tezos-client``:
+pass two arguments to ``octez-client``:
 
 * ``--mode light``, and
 * ``--sources sources.json``.
@@ -59,14 +59,14 @@ Here is an example valid ``--sources`` file:
 Because computations done locally are protocol dependent, the light mode
 does not support all protocols. However, at any given time, it should
 support the protocol being developed (``alpha``) and the three most
-recent protocols. Execute ``tezos-client list light protocols``
+recent protocols. Execute ``octez-client list light protocols``
 to see the supported protocols.
 
 If ``--protocol`` is omitted when calling the light client, it
 tries to match the node's protocol. On the one hand, this is handy when
 testing. On the other hand, in a production environment, it is recommended
 to specify ``--protocol`` if the protocol is known, to avoid an extra
-RPC at **every** call ``tezos-client --mode light ...``.
+RPC at **every** call ``octez-client --mode light ...``.
 
 Examples with the sandbox
 ~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -79,7 +79,7 @@ start a sandboxed node:
 
 ::
 
-    $ ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 1
+    $ ./src/bin_node/octez-sandboxed-node.sh 1 --connections 1
       # This node listens to p2p events on localhost:19731
       # RPC server of the node is reachable at localhost:18731
 
@@ -88,7 +88,7 @@ Leave that terminal running. In a second terminal, start another node:
 
 ::
 
-    $ ./src/bin_node/tezos-sandboxed-node.sh 2 --connections 1
+    $ ./src/bin_node/octez-sandboxed-node.sh 2 --connections 1
       # This node listens to p2p events on localhost:19732
       # RPC server of the node is reachable at localhost:18732
 
@@ -98,14 +98,14 @@ in this terminal):
 
 ::
 
-    $ eval `./src/bin_client/tezos-init-sandboxed-client.sh 1`
+    $ eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
 
 Then upgrade the node to protocol alpha:
 
 ::
 
     $ tezos-activate-alpha  # Triggers output in terminal of first node
-    $ tezos-client bake for bootstrap1  # Triggers output in terminal of first node
+    $ octez-client bake for bootstrap1  # Triggers output in terminal of first node
 
 To avoid warnings being printed in upcoming commands (optional):
 
@@ -125,7 +125,7 @@ You're now ready to use the light client. For example, bake a block:
 
 ::
 
-    $ tezos-client --endpoint http://localhost:18731 --mode light --sources sources.json bake for bootstrap1
+    $ octez-client --endpoint http://localhost:18731 --mode light --sources sources.json bake for bootstrap1
     protocol of light mode unspecified, using the node's protocol: ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK
     Apr  8 16:42:24.202 - alpha.baking.forge: found 0 valid operations (0 refused) for timestamp 2021-04-08T14:42:24.000-00:00 (fitness 01::0000000000000004)
     Injected block BMAHozsNCos2
@@ -147,7 +147,7 @@ keystrokes and the ``protocol of light mode unspecified`` warning:
 
 ::
 
-    $ alias light-client="tezos-client --endpoint http://localhost:18731 --mode light --protocol ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK --sources sources.json"
+    $ alias light-client="octez-client --endpoint http://localhost:18731 --mode light --protocol ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK --sources sources.json"
 
 And then bake a new block:
 
@@ -178,7 +178,7 @@ Here's the meaning of these lines:
 * Line ``integrated data for key v1 ...`` indicates that the light mode
   obtained data for ``v1`` from a single endpoint and that it is about
   to fetch Merkle proofs for this key from other endpoints.
-* Lines ``API call: get ...`` indicate that ``tezos-client`` is requesting
+* Lines ``API call: get ...`` indicate that ``octez-client`` is requesting
   data from the light mode's cache. In this snippet, after the light mode
   gathered data for key ``v1``; the client is requesting data for the children
   keys ``v1;constants`` and ``v1;first_level`` (the ``;`` indicates  nesting).
diff --git a/docs/user/logging.rst b/docs/user/logging.rst
index ef97b14f1e9f1e42f120e5cc48365c545aa37a19..62f4768d2a76eb85e646454a1615b0cc6dbf4727 100644
--- a/docs/user/logging.rst
+++ b/docs/user/logging.rst
@@ -237,7 +237,7 @@ Node-Specific Configuration
 Configuration File
 ~~~~~~~~~~~~~~~~~~
 
-See ``tezos-node config --help`` for the full schema of the node’s JSON
+See ``octez-node config --help`` for the full schema of the node’s JSON
 configuration file.
 
 In particular the fields:
@@ -251,7 +251,7 @@ In particular the fields:
 Command Line Options
 ~~~~~~~~~~~~~~~~~~~~
 
-See ``tezos-node run --help``, the ``lwt-log://`` sink configuration can
+See ``octez-node run --help``, the ``lwt-log://`` sink configuration can
 be also changed with 2 options:
 
 -  ``-v`` / ``-vv``: set the global log level to ``Info`` or ``Debug``
@@ -274,13 +274,13 @@ events) this call adds a sink to suddenly start pretty-printing all
 
 ::
 
-   tezos-client rpc put /config/logging with \
+   octez-client rpc put /config/logging with \
      '{ "active_sinks": [ "file-descriptor-path:///tmp/rpclogs?section-prefix=rpc:debug&format=pp&fresh=true" ] }'
 
 Client and Baking Daemons
 -------------------------
 
-For now, ``tezos-client``, ``tezos-{baker,accuser}-*``, etc.
+For now, ``octez-client``, ``octez-{baker,accuser}-*``, etc.
 can only be configured using the environment variables.
 
 There is one common option ``--log-requests`` which can be used to trace
@@ -292,12 +292,12 @@ Processing Structured Events
 
 This is work-in-progress, see:
 
--  ``tezos-admin-client show event-logging`` outputs the configuration
-   currently understood by ``tezos-admin-client`` (hence through the
+-  ``octez-admin-client show event-logging`` outputs the configuration
+   currently understood by ``octez-admin-client`` (hence through the
    ``TEZOS_EVENTS_CONFIG`` variable) and lists all the events it knows
    about.
--  ``tezos-admin-client output schema of <Event-Name> to <File-path>``
+-  ``octez-admin-client output schema of <Event-Name> to <File-path>``
    get the JSON-Schema for an event.
 
 Example:
-``tezos-admin-client output schema of block-seen-alpha to block-seen-alpha.json``
+``octez-admin-client output schema of block-seen-alpha to block-seen-alpha.json``
diff --git a/docs/user/mockup.rst b/docs/user/mockup.rst
index 0b7bdfe8ba3ac66dc050b489f94a92510003ed22..a50478f3d12290b9beed95770fe159290693fe66 100644
--- a/docs/user/mockup.rst
+++ b/docs/user/mockup.rst
@@ -2,7 +2,7 @@
  Mockup mode
 =============
 
-By default the ``tezos-client`` described in the
+By default the ``octez-client`` described in the
 :doc:`sandboxed node <sandbox>` needs a node running.
 This page describes the *mockup* mode, a mode that works without
 connecting to a node. For the moment, its features are more
@@ -29,10 +29,10 @@ Mockup mode can run in three ways:
 
 - Stateless mode.
 
-  In this mode, tezos-client operates on its inputs and returns a value. Nothing is written to disk, and no state is preserved between calls to the client. This is the default.
+  In this mode, octez-client operates on its inputs and returns a value. Nothing is written to disk, and no state is preserved between calls to the client. This is the default.
 - Stateful mode.
 
-  In this mode, tezos-client creates or manipulates a state on disk. The switch for this is ``--base-dir <directory_name>``.
+  In this mode, octez-client creates or manipulates a state on disk. The switch for this is ``--base-dir <directory_name>``.
 - Stateful asynchronous mode.
 
   This mode adds baking. The command-line switch for this is ``--base-dir <directory_name> --asynchronous``.
@@ -65,13 +65,13 @@ typecheck scripts. Let's typecheck for example the script :src:`tests_python/con
 
 .. code-block:: shell-session
 
-    $ tezos-client --mode mockup typecheck script tests_python/contracts_alpha/mini_scenarios/hardlimit.tz
+    $ octez-client --mode mockup typecheck script tests_python/contracts_alpha/mini_scenarios/hardlimit.tz
 
 The script can also be executed:
 
 .. code-block:: shell-session
 
-   $ tezos-client --mode mockup run script <filename> on storage <storage> and input <input>
+   $ octez-client --mode mockup run script <filename> on storage <storage> and input <input>
 
 where ``<storage>`` and ``<input>`` are some :ref:`Michelson expression
 <michelson_type_system>` describing the contract's storage and script input
@@ -82,7 +82,7 @@ For example:
 
 .. code-block:: shell-session
 
-  $ tezos-client --mode mockup run script tests_python/contracts_alpha/attic/id.tz on storage '"hello"' and input '"world"'
+  $ octez-client --mode mockup run script tests_python/contracts_alpha/attic/id.tz on storage '"hello"' and input '"world"'
   # Ignore warnings about the missing/wrong base directory, they do not apply to "run script"
   storage
     "world"
@@ -97,7 +97,7 @@ following command:
 
 .. code-block:: shell-session
 
-    $ tezos-client list mockup protocols
+    $ octez-client list mockup protocols
 
 At any given time, it should return ``Alpha`` and at least the two protocols before that.
 
@@ -105,7 +105,7 @@ To create the mockup client state, issue the following command:
 
 .. code-block:: shell-session
 
-    $ tezos-client \
+    $ octez-client \
       --protocol ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK \
       --base-dir /tmp/mockup \
       --mode mockup \
@@ -118,7 +118,7 @@ do the following in the local shell running the session:
 
 .. code-block:: shell-session
 
-    $ alias mockup-client='tezos-client --mode mockup --base-dir /tmp/mockup'
+    $ alias mockup-client='octez-client --mode mockup --base-dir /tmp/mockup'
 
 You can now use standard commands, such as:
 
@@ -141,7 +141,7 @@ You can now use standard commands, such as:
     Operation hash is 'ooMyN7FDmDGyNk8CLdSFwcdxcQea5KLXYqrgzu6CEYB7G2xYbth'
     NOT waiting for the operation to be included.
     Use command
-      tezos-client wait for ooMyN7FDmDGyNk8CLdSFwcdxcQea5KLXYqrgzu6CEYB7G2xYbth to be included --confirmations 30 --branch BLockGenesisGenesisGenesisGenesisGenesisCCCCCeZiLHU
+      octez-client wait for ooMyN7FDmDGyNk8CLdSFwcdxcQea5KLXYqrgzu6CEYB7G2xYbth to be included --confirmations 30 --branch BLockGenesisGenesisGenesisGenesisGenesisCCCCCeZiLHU
     and/or an external block explorer to make sure that it has been included.
     This sequence of operations was run:
       Manager signed operations:
@@ -199,7 +199,7 @@ The examples so far have used mockup mode’s default settings. Some use cases n
 
 For simplicity, the mockup mode - like the sandboxed mode - uses
 default values for the :ref:`protocol constants <protocol_constants>`. Such values are visible as follows (we recall
-that ``mockup-client`` is an alias for ``tezos-client``, see previous
+that ``mockup-client`` is an alias for ``octez-client``, see previous
 section):
 
 .. code-block:: shell-session
@@ -296,13 +296,13 @@ Besides usual protocol constants, there are 2 additional fields supported in Moc
 
 .. code-block:: shell-session
 
-   $ tezos-client compute chain id from seed <string>
+   $ octez-client compute chain id from seed <string>
 
 For instance, the following command:
 
 .. code-block:: shell-session
 
-   $ tezos-client compute chain id from seed strudel
+   $ octez-client compute chain id from seed strudel
 
 yields the chain id ``NetXwWbjfCqBTLV``.
 
diff --git a/docs/user/multinetwork.rst b/docs/user/multinetwork.rst
index 2cbeaf779923f0d0411cc7df408d2df932ab9537..42df655c992764731612a044810a79c6912edbe4 100644
--- a/docs/user/multinetwork.rst
+++ b/docs/user/multinetwork.rst
@@ -34,9 +34,9 @@ Built-In Networks
 The simplest way to select the network to connect to is to use the ``--network``
 option when you initialize your :doc:`node configuration <./node-configuration>`. For instance, to run on Limanet::
 
-  tezos-node config init --data-dir ~/tezos-limanet --network limanet
-  tezos-node identity generate --data-dir ~/tezos-limanet
-  tezos-node run --data-dir ~/tezos-limanet
+  octez-node config init --data-dir ~/tezos-limanet --network limanet
+  octez-node identity generate --data-dir ~/tezos-limanet
+  octez-node run --data-dir ~/tezos-limanet
 
 .. note::
    Once initialized, the node remembers its network settings on subsequent runs
@@ -60,11 +60,11 @@ the following built-in networks:
 
 If you did not initialize your node configuration, or if your configuration
 file contains no ``network`` field, the node assumes you want to run Mainnet.
-You can use the ``--network`` option with ``tezos-node run`` to make sure
+You can use the ``--network`` option with ``octez-node run`` to make sure
 your node runs on the expected network. For instance, to make sure that
 it runs on Limanet::
 
-  tezos-node run --data-dir ~/tezos-limanet --network limanet
+  octez-node run --data-dir ~/tezos-limanet --network limanet
 
 This command will fail with an error if the configured network is not Limanet.
 The node also displays the chain name (such as ``TEZOS_MAINNET``) when it starts.
@@ -128,7 +128,7 @@ that you will not automatically get updates to the list of bootstrap peers and
 user-activated upgrades (see `Alias Versus Explicit Configuration`_).
 
 - ``genesis`` is the description of the genesis block, i.e. the first block of the chain.
-  Inspect the genesis block using ``tezos-client rpc get /chains/main/blocks/0``
+  Inspect the genesis block using ``octez-client rpc get /chains/main/blocks/0``
   to find these values.
 
 - ``chain_name`` is the name of the network (nodes only talk to other nodes which use
diff --git a/docs/user/multisig.rst b/docs/user/multisig.rst
index 7fefa5d7eb4e542f6da13fb306a1bded8fcdce04..27712d6352533cd6e5f3c4b8821a5ae954151c1c 100644
--- a/docs/user/multisig.rst
+++ b/docs/user/multisig.rst
@@ -11,23 +11,23 @@ participants that need to agree for the action to be approved is
 called the multisig *threshold*.
 
 On Tezos, a way to run a multisig is by using a smart contract. Such a
-multisig contract has built-in support in the ``tezos-client`` and has
+multisig contract has built-in support in the ``octez-client`` and has
 been formally verified using the `Mi-Cho-Coq <https://gitlab.com/nomadic-labs/mi-cho-coq/>`_ framework.
 
-Interacting with a multisig contract using ``tezos-client``
+Interacting with a multisig contract using ``octez-client``
 -----------------------------------------------------------
 
 The recommended way to create and use a multisig contract is via
-the ``tezos-client`` built-in commands for the multisig contract. The command
-``tezos-client man multisig`` gives a complete list of
+the ``octez-client`` built-in commands for the multisig contract. The command
+``octez-client man multisig`` gives a complete list of
 multisig-related commands with details about the syntax of each
 command.
 
 Originating a new multisig contract
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To originate a new generic multisig contract, use the ``tezos-client
-deploy multisig`` command. It is similar to ``tezos-client originate
+To originate a new generic multisig contract, use the ``octez-client
+deploy multisig`` command. It is similar to ``octez-client originate
 contract`` with the following differences:
 
 - no script is given because the script of the generic multisig
@@ -44,26 +44,26 @@ first bootstrap account:
 
 ::
 
-   $ tezos-client gen keys alice
-   $ tezos-client gen keys bob
-   $ tezos-client gen keys charlie
-   $ tezos-client transfer 100 from bootstrap1 to alice --burn-cap 1
-   $ tezos-client transfer 100 from bootstrap1 to bob --burn-cap 1
-   $ tezos-client transfer 100 from bootstrap1 to charlie --burn-cap 1
-   $ tezos-client deploy multisig msig transferring 100 from bootstrap1 with threshold 2 on public keys alice bob charlie --burn-cap 1
+   $ octez-client gen keys alice
+   $ octez-client gen keys bob
+   $ octez-client gen keys charlie
+   $ octez-client transfer 100 from bootstrap1 to alice --burn-cap 1
+   $ octez-client transfer 100 from bootstrap1 to bob --burn-cap 1
+   $ octez-client transfer 100 from bootstrap1 to charlie --burn-cap 1
+   $ octez-client deploy multisig msig transferring 100 from bootstrap1 with threshold 2 on public keys alice bob charlie --burn-cap 1
 
 
 Preparing a transaction
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-The ``tezos-client prepare multisig transaction`` commands are used to
+The ``octez-client prepare multisig transaction`` commands are used to
 obtain the byte sequence corresponding to a possible action and that
 needs to be signed.
 
 To avoid writing Michelson lambdas, special cases for a single
 transfer or delegate change have their own commands.
 
-By default the ``tezos-client prepare multisig transaction`` commands
+By default the ``octez-client prepare multisig transaction`` commands
 display not only the byte sequence to sign but also a cryptographic
 hash (this can be useful when signing with a hardware signer), the
 threshold and the participant public keys. To obtain the byte sequence
@@ -73,7 +73,7 @@ multisig to Bob they will need to sign a transaction. They can call
 
 ::
 
-   $ tezos-client prepare multisig transaction on msig transferring 10 to bob
+   $ octez-client prepare multisig transaction on msig transferring 10 to bob
 
 This command will give them the byte sequence they need to sign, its
 cryptographic hash, the threshold (which is 2 in this case), and the
@@ -82,26 +82,26 @@ public keys of Alice, Bob, and Charlie.
 Signing an action
 ~~~~~~~~~~~~~~~~~
 
-There are two equivalent ways to sign an action with ``tezos-client``:
+There are two equivalent ways to sign an action with ``octez-client``:
 
-- preparing the action with one of the ``tezos-client prepare multisig
-  transaction`` commands and then signing it using the ``tezos-client
+- preparing the action with one of the ``octez-client prepare multisig
+  transaction`` commands and then signing it using the ``octez-client
   sign bytes`` command,
-- or directly using one of the ``tezos-client sign multisig
+- or directly using one of the ``octez-client sign multisig
   transaction`` commands that combine these two steps.
 
 For example, Alice can sign the transfer to Bob using
 
 ::
 
-   $ TO_SIGN=$(tezos-client prepare multisig transaction on msig transferring 10 to bob --bytes-only)
-   $ ALICE_S_SIGNATURE=$(tezos-client sign bytes "$TO_SIGN" for alice | cut -d ' ' -f 2)
+   $ TO_SIGN=$(octez-client prepare multisig transaction on msig transferring 10 to bob --bytes-only)
+   $ ALICE_S_SIGNATURE=$(octez-client sign bytes "$TO_SIGN" for alice | cut -d ' ' -f 2)
 
 and Charlie can sign the same transfer using
 
 ::
 
-   $ CHARLIE_S_SIGNATURE=$(tezos-client sign multisig transaction on msig transferring 10 to bob using secret key charlie)
+   $ CHARLIE_S_SIGNATURE=$(octez-client sign multisig transaction on msig transferring 10 to bob using secret key charlie)
 
 Acting on the multisig contract
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -110,17 +110,17 @@ Once a user has gathered enough signatures to act on the multisig
 contract, there are again two equivalent ways of sending the
 signatures:
 
-- preparing the action with one of the ``tezos-client prepare multisig
+- preparing the action with one of the ``octez-client prepare multisig
   transaction`` commands and then using the produced byte sequence
-  in the ``tezos-client run transaction`` command,
+  in the ``octez-client run transaction`` command,
 - or directly using one of the following commands depending on the action:
 
 
-  - ``tezos-client from multisig contract <multisig> transfer``
-  - ``tezos-client from multisig contract <multisig> run lambda``
-  - ``tezos-client set delegate of multisig contract``
-  - ``tezos-client withdraw delegate of multisig contract``
-  - ``tezos-client set threshold of multisig contract``
+  - ``octez-client from multisig contract <multisig> transfer``
+  - ``octez-client from multisig contract <multisig> run lambda``
+  - ``octez-client set delegate of multisig contract``
+  - ``octez-client withdraw delegate of multisig contract``
+  - ``octez-client set threshold of multisig contract``
 
 
 For example, if Alice sends her signature to Charlie, he can perform
@@ -128,20 +128,20 @@ the multi-signed transfer of ꜩ10 to Bob using either:
 
 ::
 
-   $ tezos-client run transaction "$TO_SIGN" on multisig contract msig on behalf of charlie with signatures "$ALICE_S_SIGNATURE" "$CHARLIE_S_SIGNATURE"
+   $ octez-client run transaction "$TO_SIGN" on multisig contract msig on behalf of charlie with signatures "$ALICE_S_SIGNATURE" "$CHARLIE_S_SIGNATURE"
 
 or
 
 ::
 
-   $ tezos-client from multisig contract msig transfer 10 to bob on behalf of charlie with signatures "$ALICE_S_SIGNATURE" "$CHARLIE_S_SIGNATURE"
+   $ octez-client from multisig contract msig transfer 10 to bob on behalf of charlie with signatures "$ALICE_S_SIGNATURE" "$CHARLIE_S_SIGNATURE"
 
 
 Supported versions of the multisig contract
 -------------------------------------------
 
 Two main versions of the multisig contract are supported by
-``tezos-client``. They are called the generic multisig contract and
+``octez-client``. They are called the generic multisig contract and
 the legacy multisig contract.
 
 The generic multisig contract
@@ -164,7 +164,7 @@ following features:
 The legacy multisig contract
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The ``tezos-client`` also supports
+The ``octez-client`` also supports
 :src:`a legacy version<tests_python/contracts_alpha/mini_scenarios/legacy_multisig.tz>` of the multisig contract which has the following
 limitations:
 
@@ -190,12 +190,12 @@ multisig contract.
 Listing supported hashes
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-For security reasons, ``tezos-client`` will not interact with unknown
+For security reasons, ``octez-client`` will not interact with unknown
 scripts even if their interface matches one of the supported
 multisig contracts. To check if a script is one of the supported ones,
 it stores a list of script hashes that can be printed by
-``tezos-client show supported multisig hashes``. The script originated
-by the ``tezos-client deploy multisig`` command is always one of the
+``octez-client show supported multisig hashes``. The script originated
+by the ``octez-client deploy multisig`` command is always one of the
 supported multisig contracts.
 
 Interacting with a multisig contract directly
@@ -203,7 +203,7 @@ Interacting with a multisig contract directly
 
 The following subsections describe in detail the low-level API of a
 built-in multisig contract, allowing one to originate and use in
-situations where ``tezos-client`` cannot be used e.g., when
+situations where ``octez-client`` cannot be used e.g., when
 interacting with the chain from a web browser or in a mobile
 application. In particular, this interface is typically useful when
 developing multisig support in another Tezos wallet.
diff --git a/docs/user/node-config.sh b/docs/user/node-config.sh
index 20086afc36ca971a7a62cbf7a32491678630cb57..9deac52317dcd127c9cdf6fbe59844474e0c5483 100755
--- a/docs/user/node-config.sh
+++ b/docs/user/node-config.sh
@@ -5,14 +5,14 @@
 # [remove config file if exists]
 rm -f tmp/config.json
 # [initialize config file]
-./tezos-node config init --config-file=tmp/config.json --network=sandbox
+./octez-node config init --config-file=tmp/config.json --network=sandbox
 # [update config file]
-./tezos-node config update --config-file=tmp/config.json --data-dir=tmp \
+./octez-node config update --config-file=tmp/config.json --data-dir=tmp \
   --peer="[::]:10732" --peer="192.168.1.3:9733" \
   --private-mode \
   --rpc-addr="localhost:8733" --net-addr="1.2.3.4" \
   --connections=25 \
-  --log-output="tezos-node.log" \
+  --log-output="octez-node.log" \
   --history-mode=full
 # [show config file]
-./tezos-node config show --data-dir=tmp
+./octez-node config show --data-dir=tmp
diff --git a/docs/user/node-configuration.rst b/docs/user/node-configuration.rst
index da2208f1da199d4fd10f5e88148e43a74e5bb6e9..107e2efc7f768444910c0d37b9f240aeb8c96c03 100644
--- a/docs/user/node-configuration.rst
+++ b/docs/user/node-configuration.rst
@@ -15,7 +15,7 @@ When the same parameter is set both in the configuration file and using a comman
 The list of configurable options on the command line interface (CLI) can be
 obtained using the following command::
 
-    tezos-node run --help
+    octez-node run --help
 
 .. _node-conf-file:
 
@@ -24,17 +24,17 @@ Configuration file
 
 Parameters in the configuration file can be specified in two different ways:
 
-- by creating and updating the configuration file using the ``config`` command of ``tezos-node``. This covers a subset of the CLI of the ``run`` command of ``tezos-node`` mentioned above.
+- by creating and updating the configuration file using the ``config`` command of ``octez-node``. This covers a subset of the CLI of the ``run`` command of ``octez-node`` mentioned above.
 
   The list of parameters configurable via the ``config`` command can be obtained using the following command::
 
-    tezos-node config update --help
+    octez-node config update --help
 
-- by directly editing the configuration file. This allows to specify all the available configuration parameters, including some that cannot be set using the options of the ``config`` and ``run`` commands of ``tezos-node``, for example network parameters such as connection or authentication timeouts.
+- by directly editing the configuration file. This allows to specify all the available configuration parameters, including some that cannot be set using the options of the ``config`` and ``run`` commands of ``octez-node``, for example network parameters such as connection or authentication timeouts.
 
   The list of configurable parameters in the configuration file can be obtained using the following command::
 
-    tezos-node config --help
+    octez-node config --help
 
   This command also explains the role of each option and parameter and the range of possible values.
 
@@ -43,7 +43,7 @@ The config command
 
 ::
 
-   ./tezos-node config init
+   ./octez-node config init
 
 This will initialize a configuration file for the node in
 ``$HOME/.tezos-node/config.json``, using default values. It only
@@ -60,11 +60,11 @@ The easiest way to amend this default configuration is to use
 ::
 
    # Update the config file:
-   tezos-node config update <…>
+   octez-node config update <…>
    # Check your new values:
-   tezos-node config show
+   octez-node config show
    # If you want to restart from an empty cfg file:
-   tezos-node config reset <…>
+   octez-node config reset <…>
 
 However, note that the ``network`` configuration parameter, needed to run the node on a network other than the default one (Mainnet), can only be defined when the configuration file is initialized (using ``init``), and cannot be updated later (using ``update``). See the instructions for :doc:`running the node in test networks <./multinetwork>`.
 
@@ -79,13 +79,11 @@ Editing the configuration file
 
 All blockchain data is stored under ``$HOME/.tezos-node/`` by default.
 You can
-change this by doing ``./tezos-node config update --data-dir
-</somewhere/in/your/disk>``.
+change this by doing ``./octez-node config update --data-dir </somewhere/in/your/disk>``.
 
 To run multiple nodes on the same machine, you can duplicate and edit
 ``$HOME/.tezos-node/config.json`` while making sure they don't share
-the same ``data-dir``. Then run your node with ``./tezos-node
-run --config-file=</path/to/alternate_cfg>``.
+the same ``data-dir``. Then run your node with ``./octez-node run --config-file=</path/to/alternate_cfg>``.
 
 Here is an example configuration file with several parameters specified.
 Incidentally, it is exactly the one resulting from the command sequence above.
@@ -162,17 +160,17 @@ by command-line argument ``--rpc-addr`` when starting the node.
 
 Additionally either the ``whitelist`` **or** the ``blacklist`` field must be specified
 (but not both), containing a list of paths which should be black-listed or
-white-listed. Each element in the list is an API-endpoint (that can be passed to e.g. the ``tezos-client rpc``
+white-listed. Each element in the list is an API-endpoint (that can be passed to e.g. the ``octez-client rpc``
 command). It may be preceded by a capitalized HTTP method name. In the absence of
 the method, the rule applies to all methods. The path can include an ``*``
 character, which stands for any whole path segment (i.e. it's not allowed to mix ``*``
 with other characters in a path segment).
 A ``**`` stands for any possible path suffix.
 
-Additionally ``--allow-all-rpc`` CLI option to ``tezos-node`` can be used to
+Additionally ``--allow-all-rpc`` CLI option to ``octez-node`` can be used to
 simply allow all RPC endpoints on a given address. When passed to
-``tezos-node config`` command, this option modifies the ``config.json`` file,
-putting an appropriate ACL there. When passed to ``tezos-node run``, it
+``octez-node config`` command, this option modifies the ``config.json`` file,
+putting an appropriate ACL there. When passed to ``octez-node run``, it
 overrides the settings of the ``config.json`` for this particular run, without
 modifying the file.
 
@@ -195,7 +193,7 @@ Examples
 
 ::
 
-  $ tezos-node run --rpc-addr localhost:8732
+  $ octez-node run --rpc-addr localhost:8732
 
 In this case the RPC is only available for requests coming from ``localhost``
 (i.e. ``127.0.0.1``). There's no need configure the ACL, as an allow-all policy
@@ -203,7 +201,7 @@ is applied to the local host by default.
 
 ::
 
-    $ tezos-node run --rpc-addr localhost:8732 --rpc-addr 192.168.0.3:8732
+    $ octez-node run --rpc-addr localhost:8732 --rpc-addr 192.168.0.3:8732
 
 In this example the RPC is available to both ``localhost`` and to the local
 network (assuming the node does have address ``192.168.0.3`` in that network).
@@ -214,7 +212,7 @@ be filtered by the default ACL (:ref:`see below <default_acl>`).
 In this last case, to listen on both ``localhost`` and local network, it might
 be tempting to listen on the special ``0.0.0.0`` address::
 
-  $ tezos-node run --rpc-addr 0.0.0.0:8732
+  $ octez-node run --rpc-addr 0.0.0.0:8732
 
 ``0.0.0.0`` is a special address, not attached to any particular networking
 interface. Instead it tells the OS to route messages incoming to **all**
@@ -230,11 +228,11 @@ remote hosts, but enable all RPCs for localhost (which is for instance necessary
 to perform baking and endorsing). Since all RPCs are available to localhost by
 default, it is sufficient to open another listening address::
 
-  $ tezos-node run --rpc-addr localhost --rpc-addr 0.0.0.0
+  $ octez-node run --rpc-addr localhost --rpc-addr 0.0.0.0
 
 The ``--allow-all-rpc`` switch can be used to open all RPCs on a specific address::
 
-  $ tezos-node run --rpc-addr 192.168.0.3 --allow-all-rpc 192.168.0.3
+  $ octez-node run --rpc-addr 192.168.0.3 --allow-all-rpc 192.168.0.3
 
 Note that the addresses of both ``--rpc-addr`` and ``--allow-all-rpc`` switches
 should match. In particular remember that ``0.0.0.0`` is a specific address
@@ -354,7 +352,7 @@ hardware wallet.
 
 ::
 
-   tezos-node run --rpc-addr [::] --private-mode \
+   octez-node run --rpc-addr [::] --private-mode \
                                   --no-bootstrap-peers \
                                   --synchronisation-threshold=1 \
                                   --connections 1 \
diff --git a/docs/user/proxy-server.rst b/docs/user/proxy-server.rst
index 8d602763d28b5f19c04a8d87ac764ceb2936ce0a..61b9f7ed671de34175236674578285a9b7fb7741 100644
--- a/docs/user/proxy-server.rst
+++ b/docs/user/proxy-server.rst
@@ -1,7 +1,7 @@
 Proxy server
 ------------
 
-This page describes the *proxy server*, a readonly frontend to ``tezos-node``
+This page describes the *proxy server*, a readonly frontend to ``octez-node``
 which is designed to lower the load of full nodes. It can be run separately from
 a node and will handle some RPC requests by itself. It is named after two
 things:
@@ -62,9 +62,9 @@ In a terminal, start a sandboxed node:
 
 ::
 
-    $ ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 1
+    $ ./src/bin_node/octez-sandboxed-node.sh 1 --connections 1
       April 21 11:05:32.789 - node.config.validation: the node configuration has been successfully validated.
-      Created /tmp/tezos-node.Uzq5aGAN/config.json for network: sandbox.
+      Created /tmp/octez-node.Uzq5aGAN/config.json for network: sandbox.
       ...
 
 Leave that terminal running. In a second terminal, prepare the appropriate
@@ -72,14 +72,14 @@ environment for using a proxy server:
 
 ::
 
-    $ eval `./src/bin_client/tezos-init-sandboxed-client.sh 1`
+    $ eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
 
 Then upgrade the node to protocol alpha:
 
 ::
 
     $ tezos-activate-alpha
-    $ tezos-client bake for bootstrap1
+    $ octez-client bake for bootstrap1
 
 To avoid warnings being printed in upcoming commands (optional):
 
@@ -95,7 +95,7 @@ is doing (see the :doc:`proxy mode<proxy>` page for more details).
 ::
 
     $ export TEZOS_LOG="proxy_rpc_ctxt->debug; alpha.proxy_rpc->debug; proxy_server_run->debug; proxy_getter->debug; proxy_services->debug"
-    $ ./tezos-proxy-server --endpoint http://127.0.0.1:18731 --rpc-addr http://127.0.0.1:18732
+    $ ./octez-proxy-server --endpoint http://127.0.0.1:18731 --rpc-addr http://127.0.0.1:18732
       protocol of proxy unspecified, using the node's protocol: ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK
       Apr 21 11:09:22.092 - proxy_server_run: starting proxy RPC server on 127.0.0.1:18732
 
@@ -104,7 +104,7 @@ Now, start a fourth terminal, and make a client request data from the proxy serv
 ::
 
     $ export TEZOS_CLIENT_UNSAFE_DISABLE_DISCLAIMER=y
-    $ ./tezos-client --endpoint http://127.0.0.1:18732 rpc get /chains/main/blocks/head/context/contracts
+    $ ./octez-client --endpoint http://127.0.0.1:18732 rpc get /chains/main/blocks/head/context/contracts
       [ "tz1gjaF81ZRRvdzjobyfVNsAeSC6PScjfQwN",
         "tz1ddb9NMYHZi5UzPdzTZMYQQZoMub195zgv",
         "tz1faswCTDciRzE4oJ9jn2Vm2dvjeyA9fUzU",
@@ -145,13 +145,13 @@ Now, in the fourth terminal, retrieve the contracts again, but twice in a row:
 
 ::
 
-    $ ./tezos-client --endpoint http://127.0.0.1:18732 rpc get /chains/main/blocks/head/context/contracts
+    $ ./octez-client --endpoint http://127.0.0.1:18732 rpc get /chains/main/blocks/head/context/contracts
       [ "tz1gjaF81ZRRvdzjobyfVNsAeSC6PScjfQwN",
         "tz1ddb9NMYHZi5UzPdzTZMYQQZoMub195zgv",
         "tz1faswCTDciRzE4oJ9jn2Vm2dvjeyA9fUzU",
         "tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx",
         "tz1b7tUupMgCNw2cCLpKTkSD1NZzB5TkP2sv" ]
-    $ ./tezos-client --endpoint http://127.0.0.1:18732 rpc get /chains/main/blocks/head/context/contracts
+    $ ./octez-client --endpoint http://127.0.0.1:18732 rpc get /chains/main/blocks/head/context/contracts
       # ... same output ...
 
 In the meantime, in the proxy server's terminal, you should see:
@@ -194,12 +194,12 @@ and restart it as follows:
 
 ::
 
-    $ ./tezos-proxy-server --endpoint http://127.0.0.1:18731 --rpc-addr http://127.0.0.1:18732 --data-dir /tmp/tezos-node.Uzq5aGAN
+    $ ./octez-proxy-server --endpoint http://127.0.0.1:18731 --rpc-addr http://127.0.0.1:18732 --data-dir /tmp/octez-node.Uzq5aGAN
       protocol of proxy unspecified, using the node's protocol: ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK
       Apr 21 11:09:22.092 - proxy_server_run: starting proxy RPC server on 127.0.0.1:18732
 
 The value of the ``--data-dir`` argument was obtained by looking at the
-output of the terminal where ``tezos-node`` was launched
+output of the terminal where ``octez-node`` was launched
 (see :ref:`above <sandbox_example>`).
 
 Now, in the fourth terminal (the client's terminal), redo the request
@@ -207,7 +207,7 @@ to retrieve contracts:
 
 ::
 
-    $ ./tezos-client --endpoint http://127.0.0.1:18732 rpc get /chains/main/blocks/head/context/contracts
+    $ ./octez-client --endpoint http://127.0.0.1:18732 rpc get /chains/main/blocks/head/context/contracts
       # ... same output as above ...
 
 Now the output in the proxy server terminal should be:
@@ -227,7 +227,7 @@ Additional arguments
 ~~~~~~~~~~~~~~~~~~~~
 
 We describe the entire list of arguments of the proxy server. This
-documentation is also available with ``./tezos-proxy-server --help``.
+documentation is also available with ``./octez-proxy-server --help``.
 Here is the list of possible arguments:
 
 * ``-c`` and ``--config`` specify the JSON file to use an input
@@ -285,7 +285,7 @@ Because computations done by the proxy server are protocol dependent, the proxy
 does not support all protocols. However, it is expected that, at any
 given time, the proxy server supports ``Alpha``, the current protocol
 of Mainnet and the current protocol proposal on Mainnet at the time of release.
-In doubt, execute ``tezos-client list proxy protocols`` to see the supported protocols.
+In doubt, execute ``octez-client list proxy protocols`` to see the supported protocols.
 
 .. _unsupported_rpcs:
 
diff --git a/docs/user/proxy.rst b/docs/user/proxy.rst
index 37f0b2b7c1941802fca53a7bcc468b39b31e2735..85ee7df55561e5275f1db536e29aa7d096181ffe 100644
--- a/docs/user/proxy.rst
+++ b/docs/user/proxy.rst
@@ -1,7 +1,7 @@
 Proxy mode
 ----------
 
-The ``tezos-client`` described
+The ``octez-client`` described
 :ref:`here <howtouse_tezos_client>` forwards all RPCs to a node.
 This page describes the *proxy* mode, a mode where the client
 performs protocol RPCs locally. For the computations to be correct,
@@ -18,19 +18,19 @@ Executing commands in proxy mode
 
 The CLI interface of the client in proxy mode (the *proxy client* in short)
 is the same as the default client. To turn proxy mode ON,
-pass ``--mode proxy`` to ``tezos-client``.
+pass ``--mode proxy`` to ``octez-client``.
 
 Because computations done locally are protocol dependent, the proxy mode does not support all protocols.
 It is expected that, at any given time, the proxy mode supports ``Alpha``,
 the current protocol of Mainnet and the current protocol proposal on Mainnet
 at the time of release.
-In doubt, execute ``tezos-client list proxy protocols`` to see the supported protocols.
+In doubt, execute ``octez-client list proxy protocols`` to see the supported protocols.
 
 If ``--protocol`` is omitted when calling the proxy client, it
 tries to match the node's protocol. On the one hand, this is handy when
 testing. On the other hand, in a production environment, it is recommended
 to specify ``--protocol`` if the protocol is known, to avoid an extra
-RPC at **every** call ``tezos-client --mode proxy ...``
+RPC at **every** call ``octez-client --mode proxy ...``
 
 Examples with the sandbox
 ~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -43,21 +43,21 @@ start a sandboxed node:
 
 ::
 
-    $ ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 1
+    $ ./src/bin_node/octez-sandboxed-node.sh 1 --connections 1
 
 Leave that terminal running, in another terminal, prepare the appropriate
 environment for using the proxy client:
 
 ::
 
-    $ eval `./src/bin_client/tezos-init-sandboxed-client.sh 1`
+    $ eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
 
 Then upgrade the node to protocol alpha:
 
 ::
 
     $ tezos-activate-alpha
-    $ tezos-client bake for bootstrap1
+    $ octez-client bake for bootstrap1
 
 To avoid warnings being printed in upcoming commands (optional):
 
@@ -69,7 +69,7 @@ You're now ready to use the proxy client. For example, request baking rights:
 
 ::
 
-    $ tezos-client --mode proxy rpc get /chains/main/blocks/head/helpers/baking_rights
+    $ octez-client --mode proxy rpc get /chains/main/blocks/head/helpers/baking_rights
     protocol of proxy unspecified, using the node's protocol: ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK
     [ { "level": 3, "delegate": "tz1KqTpEZ7Yob7QbPE4Hy4Wo8fHG8LhKxZSx",
         "priority": 0, "estimated_time": "2020-07-01T08:47:21Z" },
@@ -103,7 +103,7 @@ keystrokes and the ``protocol of proxy unspecified`` warning:
 
 ::
 
-    $ alias proxy-client="tezos-client --mode proxy --protocol ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK"
+    $ alias proxy-client="octez-client --mode proxy --protocol ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK"
 
 Now configure ``proxy_rpc_ctxt`` to have more information:
 
diff --git a/docs/user/sandbox.rst b/docs/user/sandbox.rst
index 211649f73a9430ecb4a58d666c44416f51a246c1..82afef2c5d9f7b360c33f69471781af3f916cdbb 100644
--- a/docs/user/sandbox.rst
+++ b/docs/user/sandbox.rst
@@ -4,8 +4,8 @@ Sandboxed mode
 To run a ‘localhost-only’ instance of a Tezos network, we provide two
 helper scripts:
 
--  ``./src/bin_node/tezos-sandboxed-node.sh``
--  ``./src/bin_client/tezos-init-sandboxed-client.sh``
+-  ``./src/bin_node/octez-sandboxed-node.sh``
+-  ``./src/bin_client/octez-init-sandboxed-client.sh``
 
 For the moment these scripts are expected to be run on the ``master``
 branch (see :ref:`Build from sources<build_from_sources>`; in
@@ -21,10 +21,10 @@ for peers on port ``19731`` and listening for RPC on port ``18731``.
 
 ::
 
-    ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 1
+    ./src/bin_node/octez-sandboxed-node.sh 1 --connections 1
 
 This node will store its data in a temporary directory
-``/tmp/tezos-node.xxxxxxxx`` which will be removed when the node is
+``/tmp/octez-node.xxxxxxxx`` which will be removed when the node is
 stopped.
 The option ``--connections`` is just to remove the spurious “Too few
 connections” warnings by lowering the number of expected connection.
@@ -34,7 +34,7 @@ it will listen on port ``19739`` and ``18739``:
 
 ::
 
-    ./src/bin_node/tezos-sandboxed-node.sh 9
+    ./src/bin_node/octez-sandboxed-node.sh 9
 
 You might replace ``1`` or ``9`` by any number in between if you want to
 run more than two nodes.
@@ -48,9 +48,9 @@ Once your node is running, open a new terminal and initialize the
 
 ::
 
-    eval `./src/bin_client/tezos-init-sandboxed-client.sh 1`
+    eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
 
-It will also define in the current shell session an alias ``tezos-client``
+It will also define in the current shell session an alias ``octez-client``
 preconfigured for communicating with the same-numbered node.
 
 When you bootstrap a new network, the network is initialized with a
@@ -62,11 +62,11 @@ For instance:
 
 ::
 
-    $ tezos-client rpc get /chains/main/blocks/head/metadata
+    $ octez-client rpc get /chains/main/blocks/head/metadata
       "next_protocol": "Ps9mPmXaRzmzk35gbAYNCAw6UXdE2qoABTHbN2oEEc1qM7CwT9P"
     $ tezos-activate-alpha
       Injected BMV9KnSPE1yw
-    $ tezos-client rpc get /chains/main/blocks/head/metadata
+    $ octez-client rpc get /chains/main/blocks/head/metadata
       "protocol": "Ps9mPmXaRzmzk35gbAYNCAw6UXdE2qoABTHbN2oEEc1qM7CwT9P"
 
 We now have the possibility to send transactions to the sandboxed network.
@@ -77,7 +77,7 @@ preconfigured accounts which can be listed with:
 
 ::
 
-   $ tezos-client list known addresses
+   $ octez-client list known addresses
 
      activator: tz1TGu6TN5GSez2ndXXeDX6LgUDvLzPLqgYV (unencrypted sk known)
      bootstrap5: tz1ddb9NMYHZi5UzPdzTZMYQQZoMub195zgv (unencrypted sk known)
@@ -91,7 +91,7 @@ another:
 
 ::
 
-   $ tezos-client transfer 42 from bootstrap1 to bootstrap2 &
+   $ octez-client transfer 42 from bootstrap1 to bootstrap2 &
    ...
    Waiting for the operation to be included...
 
@@ -103,12 +103,12 @@ we can do so with the following command:
 
 ::
 
-   $ tezos-client bake for bootstrap1
+   $ octez-client bake for bootstrap1
 
 If the previous transaction is valid, the operation is included in the
 chain and the transfer terminates returning the usual receipt.
 Note that the ``bake for`` command of the client is exclusively for
-testing purposes, all baking should be done using the ``tezos-baker``
+testing purposes, all baking should be done using the ``octez-baker``
 binary.
 
 
@@ -131,7 +131,7 @@ can use the `DATA_DIR` environment variable.
 ::
 
     mkdir /tmp/tz-data
-    DATA_DIR='/tmp/tz-data' ./src/bin_node/tezos-sandboxed-node.sh 1 --connections 1
+    DATA_DIR='/tmp/tz-data' ./src/bin_node/octez-sandboxed-node.sh 1 --connections 1
 
 You can even provide a custom `identity.json` and `config.json` to the
 sandboxed node by placing them in the data directory.
diff --git a/docs/user/snapshots.rst b/docs/user/snapshots.rst
index 6dac8d6b4c92f5f7cdfc445185a63617c7d87c3f..e87a35cca08490bf5cc52e5360191b8538f1db26 100644
--- a/docs/user/snapshots.rst
+++ b/docs/user/snapshots.rst
@@ -49,7 +49,7 @@ will not work), run:
 
 .. code-block:: console
 
-   tezos-node snapshot import <FILE> --block <BLOCK_HASH> [--data-dir <NODE_DIR>]
+   octez-node snapshot import <FILE> --block <BLOCK_HASH> [--data-dir <NODE_DIR>]
 
 The ``--block <BLOCK_HASH>`` option argument aims to verify that the
 block contained in the snapshot is the one that you are expecting to
@@ -83,7 +83,7 @@ This information is displayed by the following command:
 
 .. code-block:: console
 
-   tezos-node snapshot info <FILE>
+   octez-node snapshot info <FILE>
 
 As can be seen in the snapshot information, a snapshot contains
 historical data corresponding to a given history mode, which can be:
@@ -118,7 +118,7 @@ point. This kind of snapshot can only be created from a ``full`` or an
 
 .. code-block:: console
 
-   tezos-node snapshot export --block <BLOCK>
+   octez-node snapshot export --block <BLOCK>
 
 The ``<BLOCK>`` hint can be given as a *block hash*, a *block level*,
 an alias (*head*, *savepoint* or *checkpoint*) and a relative block
@@ -134,7 +134,7 @@ snapshot file name can be given as an additional argument. For example:
 
 .. code-block:: console
 
-   tezos-node snapshot export recent_head_snapshot.full --block head
+   octez-node snapshot export recent_head_snapshot.full --block head
 
 Rolling export
 ~~~~~~~~~~~~~~
@@ -148,7 +148,7 @@ history.
 
 .. code-block:: console
 
-   tezos-node snapshot export <FILE>.rolling --block <BLOCK_HASH> --rolling
+   octez-node snapshot export <FILE>.rolling --block <BLOCK_HASH> --rolling
 
 Snapshot file format and IPFS
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/user/various.rst b/docs/user/various.rst
index f095733bad241bd64f15fe7d65a83c00a0b832dd..135d688a0fce1a2b570fd57a6a86ef5aa1493182 100644
--- a/docs/user/various.rst
+++ b/docs/user/various.rst
@@ -8,7 +8,7 @@ Environment for writing Michelson contracts
 editing and debugging Michelson programs. `Install it <https://www.gnu.org/software/emacs/>`_ and follow the
 configuration instructions in the Michelson Emacs README `here <https://gitlab.com/tezos/tezos/-/tree/master/emacs>`__.
 
-.. _tezos-admin-client:
+.. _octez-admin-client:
 
 Admin Client
 ------------
@@ -24,7 +24,7 @@ A useful command to debug a node that is not syncing is:
 
 ::
 
-   tezos-admin-client p2p stat
+   octez-admin-client p2p stat
 
 .. _tezos_binaries_signals_and_exit_codes:
 
@@ -76,7 +76,7 @@ operation from the message that is being signed or checked.
 
 ::
 
-   tezos-client sign message "hello world" for <account>
+   octez-client sign message "hello world" for <account>
 
-   tezos-client check that message "hello world" was signed by <account> to
+   octez-client check that message "hello world" was signed by <account> to
    produce <signature>
diff --git a/docs/user/versioning.rst b/docs/user/versioning.rst
index 50567c88dd85efac4945c409a59a031b92920b90..86e9292bf395db55069f61a80ae3fccd87b4153e 100644
--- a/docs/user/versioning.rst
+++ b/docs/user/versioning.rst
@@ -31,7 +31,7 @@ least two different versions. For example:
 
 ::
 
-   ./tezos-client rpc get /chains/main/mempool/pending_operations?version=0
+   ./octez-client rpc get /chains/main/mempool/pending_operations?version=0
 
 If the RPC is called with a bad version number (a negative or an
 unsupported version) the call fails with an error message like: