diff --git a/docs/.gitignore b/docs/.gitignore
index d63c6f035f4c0e218e5da68ae6e3d780965b02bd..6683e75aabc7a286c8fe4e72f0f5734b1c62327a 100644
--- a/docs/.gitignore
+++ b/docs/.gitignore
@@ -1,11 +1,11 @@
-tezos-baker.html
-tezos-accuser.html
-tezos-endorser.html
-tezos-client.html
-/api/tezos-snoop.html
-/api/tezos-codec.html
-/api/tezos-admin-client.html
-/api/tezos-signer.html
+octez-baker.html
+octez-accuser.html
+octez-endorser.html
+octez-client.html
+/api/octez-snoop.html
+/api/octez-codec.html
+/api/octez-admin-client.html
+/api/octez-signer.html
 
 /alpha/rpc.rst
 /shell/rpc.rst
diff --git a/docs/CHANGES.rst b/docs/CHANGES.rst
index e675c48769438a0ad8383924da4d87c856143afa..3f1722f4f7d5c2c9690269072fb7a1f402e30350 100644
--- a/docs/CHANGES.rst
+++ b/docs/CHANGES.rst
@@ -101,7 +101,7 @@ Node
   sections: ``validator.chain``, ``validator.peer``, ``prevalidator``
   and ``validator.block``. Section ``node.chain_validator`` is merged
   into ``validator.chain`` for consistency reasons. Those events see
-  their JSON reprensentation shortened, with no duplicated
+  their JSON representation shortened, with no duplicated
   information. e.g.  ``validator.peer`` events were named
   ``validator.peer.v0`` at top-level and had an ``event`` field with a
   ``name`` field containing the actual event name, for example
diff --git a/docs/Makefile b/docs/Makefile
index 02e49672be03ca7e2f82ec12b276a1aa871102cf..7b616b86b4d2f55475fa744b3f4f6930ab767aa7 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -1,9 +1,8 @@
 # You can set these variables from the command line.
 SPHINXOPTS    = -j auto -aE -n -W --keep-going
 SPHINXBUILD   = poetry run sphinx-build
-SPHINXPROJ    = Tezos
 SOURCEDIR     = .
-TMPDOCDIR        = /tmp/tezosdoc
+TMPDOCDIR        = /tmp/octezdoc
 BUILDDIR      = _build
 TOPBUILDDIR   = ../_build/default
 
@@ -22,8 +21,8 @@ kathmandu_long = PtKathmankSpLLDALzWw7CGD2j2MtyveTwboEYokqUCP4a1LxMg
 lima_long     = PtLimaPtLMwfNinJi9rCfDPWea8dFgTZ1MeJ9f1m2SRic6ayiwW
 alpha_long    = ProtoALphaALphaALphaALphaALphaALphaALphaALphaDdp3zK
 
-kathmandu_short = 014-PtKathma
-lima_short    = 015-PtLimaPt
+kathmandu_short = PtKathma
+lima_short    = PtLimaPt
 alpha_short   = alpha
 
 SCRIPTSDIR    = scripts
@@ -203,4 +202,4 @@ lint: pylint pycodestyle lint_black
 clean:
 	@-rm -Rf "$(BUILDDIR)" linkcheck
 	@-rm -Rf api/errors.rst developer/metrics.csv user/node-config.json alpha/rpc.rst shell/rpc.rst shell/p2p_api.rst user/default-acl.json CHANGES-dev.rst
-	@-rm -Rf api/tezos-*.html api/tezos-*.txt active/tezos-*.html kathmandu/tezos-*.html lima/tezos-*.html alpha/tezos-*.html
+	@-rm -Rf api/octez-*.html api/octez-*.txt active/octez-*.html kathmandu/octez-*.html lima/octez-*.html alpha/octez-*.html
diff --git a/docs/alpha/cli-commands.rst b/docs/alpha/cli-commands.rst
index 4f0763d90f68bc1ada86966b98ca6946c1202767..38bf04030e044dd26cea8df498849fee55762c96 100644
--- a/docs/alpha/cli-commands.rst
+++ b/docs/alpha/cli-commands.rst
@@ -3,8 +3,8 @@ Command Line Interface
 **********************
 
 This document is a prettier output of the documentation produced by
-the command ``man`` of the different Tezos binaries. You can obtain similar pages
-using shell commands such as (:ref:`indicating the appropriate protocol <tezos_client_protocol>`):
+the command ``man`` of the different Octez binaries. You can obtain similar pages
+using shell commands such as (:ref:`indicating the appropriate protocol <octez_client_protocol>`):
 
 ::
 
diff --git a/docs/alpha/michelson.rst b/docs/alpha/michelson.rst
index 1ebe4ed7be79e77b4051dcb72d47bc7526fc6468..80a21c5e071479fbae942915c88e2684a5e0758d 100644
--- a/docs/alpha/michelson.rst
+++ b/docs/alpha/michelson.rst
@@ -3394,7 +3394,7 @@ data include not only a description of the action to perform but also
 the address of the multisig contract and a counter that gets
 incremented at each successful call to the contract.
 
-The multisig commands of :ref:`Tezos command line client <client_manual_alpha>`
+The multisig commands of :ref:`Octez command line client <client_manual_alpha>`
 use this
 smart contract. Moreover, `functional correctness of this contract has
 been verified
diff --git a/docs/alpha/sapling.rst b/docs/alpha/sapling.rst
index b4a0f3d9b4fee992eceeb5441dea2ee2c93140d6..5854de0371ab0e8a6f7ac67900ba3fc4e06999f5 100644
--- a/docs/alpha/sapling.rst
+++ b/docs/alpha/sapling.rst
@@ -485,7 +485,7 @@ unshielding.
    # set up the sandbox
    ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 &
    eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
-   tezos-activate-alpha
+   octez-activate-alpha
 
    # originate the contract with its initial empty sapling storage,
    # bake a block to include it.
diff --git a/docs/alpha/transaction_rollups.rst b/docs/alpha/transaction_rollups.rst
index 3bc2278b5d0221c55b0793a8c86d6bb4d7967db9..1e3e71f1659e929fb22851a615ebe72dcf6080a9 100644
--- a/docs/alpha/transaction_rollups.rst
+++ b/docs/alpha/transaction_rollups.rst
@@ -598,7 +598,7 @@ rollup node is to prepare its configuration file.
 
 .. code:: sh
 
-    tezos-tx-rollup-node-alpha init ${mode} config \
+    octez-tx-rollup-node-alpha init ${mode} config \
           for ${tx_rollup_address_or_name} \
           --data-dir ${data_dir} \
           --rpc-addr ${rpc_address} \
@@ -669,7 +669,7 @@ For instance,
 
 .. code:: sh
 
-    tezos-tx-rollup-node-alpha init batcher config for ${rollup}  \
+    octez-tx-rollup-node-alpha init batcher config for ${rollup}  \
           --data-dir /tmp/tx-node \
           --rpc-addr ${rollup_node_rpc_server_address} \
           --batch-signer ${batcher}
@@ -685,7 +685,7 @@ Once the configuration is ready, starting the rollup node is as simple as
 
 .. code:: sh
 
-    tezos-tx-rollup-node-alpha --endpoint ${tezos_node_address} \
+    octez-tx-rollup-node-alpha --endpoint ${tezos_node_address} \
           run ${mode} for ${rollup_address_or_name} \
           --data-dir ${data_dir} \
           [--allow-deposit]
@@ -825,7 +825,7 @@ the ``get balance`` command can be used.
 
 .. code:: sh
 
-    tezos-tx-rollup-client-alpha get balance for alice of ${ticket_hash}
+    octez-tx-rollup-client-alpha get balance for alice of ${ticket_hash}
 
 .. note::
 
@@ -836,7 +836,7 @@ To transfer a ticket to another address on the layer-2, the
 
 .. code:: sh
 
-    tezos-tx-rollup-client-alpha transfer ${qty} \
+    octez-tx-rollup-client-alpha transfer ${qty} \
           of ${ticket_hash} \
           from ${src} to ${dst} \
           [--endpoint ${tx_rollup_node_address}]
@@ -854,7 +854,7 @@ block, one can use the following command.
 
 .. code:: sh
 
-    tezos-tx-rollup-client-alpha get block ${block_id}
+    octez-tx-rollup-client-alpha get block ${block_id}
 
 where ``block_id`` can either be ``head`` (the latest rollup block), a
 level (0, 1, etc.), or a Tezos block hash.
@@ -864,7 +864,7 @@ rollup, and to inject it back in the layer-1.
 
 .. code:: sh
 
-    tezos-tx-rollup-client-alpha withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst}
+    octez-tx-rollup-client-alpha withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst}
 
 Similarly to the ``transfer`` command, ``l2_src`` has to be an alias
 to a BLS pair of keys, while ``l1_dst`` can either be an alias or an
@@ -896,7 +896,7 @@ To retrieve the values of ``micheline_contents``, ``ty`` and
 
 .. code:: sh
 
-    tezos-tx-rollup-client-alpha rpc get "/context/head/tickets/${ticket_hash}"
+    octez-tx-rollup-client-alpha rpc get "/context/head/tickets/${ticket_hash}"
 
 Besides, the entrypoint ``ep`` of ``sc_dst`` needs to expect a
 ``ticket ty`` as its input.
diff --git a/docs/developer/openmetrics.rst b/docs/developer/openmetrics.rst
index f5567f5239ce1d603ac218b7500871ebed705fe3..63dd9272de2a6ac3ccda09f7600d7e189dda776d 100644
--- a/docs/developer/openmetrics.rst
+++ b/docs/developer/openmetrics.rst
@@ -61,7 +61,7 @@ source - using adequate values:
 
 ::
 
-  - job_name: 'tezos-metrics'
+  - job_name: 'octez-metrics'
       scheme: http
       static_configs:
         - targets: ['localhost:9091']
diff --git a/docs/developer/proposal_testing.rst b/docs/developer/proposal_testing.rst
index 78bbc809f08ada9dadbefe9b97a8cf72720086d3..0668ef318c0deaffdb81dc95877078c727ae110e 100644
--- a/docs/developer/proposal_testing.rst
+++ b/docs/developer/proposal_testing.rst
@@ -43,7 +43,7 @@ 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
 started, the Alpha protocol can be activated by invoking the command::
 
-  $ tezos-activate-alpha
+  $ octez-activate-alpha
 
 This command inserts a new block after which the active protocol is the Alpha
 protocol. From this point on, making the chain progress is straightforward
@@ -366,11 +366,11 @@ fresh test folder every time we want to perform the migration.
 
 For instance, the following commands import a context from the snapshot file
 ``~/snapshot-mainnet.rolling``
-into the folder ``/tmp/mainnet``,
+into the folder ``/tmp/octez-node-mainnet``,
 and generate an identity in the same folder::
 
-  $ ./octez-node snapshot import ~/snapshot-mainnet.rolling --data-dir /tmp/tezos-node-mainnet
-  $ ./octez-node identity generate --data-dir /tmp/tezos-node-mainnet
+  $ ./octez-node snapshot import ~/snapshot-mainnet.rolling --data-dir /tmp/octez-node-mainnet
+  $ ./octez-node identity generate --data-dir /tmp/octez-node-mainnet
 
 The ``./octez-node snapshot import`` command accepts an option
 ``--block <block_hash>`` that instructs the command to check that the hash of
@@ -393,7 +393,7 @@ keys actually encode the same bytes as their corresponding public keys. By
 adding to the yes-wallet the existing accounts of Mainnet bakers, we would have
 enough rights to bake blocks at will. We can do so by running::
 
-  $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/tezos-node-mainnet in /tmp/yes-wallet --active-bakers-only
+  $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/octez-node-mainnet in /tmp/yes-wallet --active-bakers-only
 
 This command creates a yes-wallet and places its folder in the
 system's temp directory (in our example, ``/tmp``) as given by the path argument
@@ -407,7 +407,7 @@ power), you can also use the ``--staking-share`` option to provide a
 limit. For instance, the first largest bakers with an accumulated
 stake of at least 75 percent can be kept with::
 
-  $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/tezos-node-mainnet in /tmp/yes-wallet --active-bakers-only --staking-share 75
+  $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/octez-node-mainnet in /tmp/yes-wallet --active-bakers-only --staking-share 75
 
 .. note::
    Prior to switching to the Tenderbake consensus algorithm it was
@@ -457,14 +457,14 @@ was taken, we can use::
 In the latter case both the context and the yes-wallet folder will be placed in
 the system's temp directory. In our example the temp directory is ``/tmp``, and
 the context and yes-wallet would be placed in paths
-``/tmp/tezos-node-mainnet`` and ``/tmp/yes-wallet``
+``/tmp/octez-node-mainnet`` and ``/tmp/yes-wallet``
 respectively.
 
 If the script detects that the yes-wallet folder already exists int ``/tmp``,
 then it will clean it by removing spurious files ``/tmp/yes-wallet/blocks`` and
 ``/tmp/yes-wallet/wallet_locks``, and it will not create a new yes-wallet
 folder. If the script detects that the folder
-``/tmp/tezos-node-mainnet`` already exists, or if the developer
+``/tmp/octez-node-mainnet`` already exists, or if the developer
 passes the path of a folder instead of the path of a snapshot file, then the
 script will use the corresponding folder as the original folder, and will not
 import a new context.
@@ -495,7 +495,7 @@ We can also start the client::
 
   $ eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
 
-Instead of command ``tezos-activate-alpha``, the sandboxed client script
+Instead of command ``octez-activate-alpha``, the sandboxed client script
 ``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
@@ -543,10 +543,10 @@ unchanged, and every time we want to run the test, we will copy its contents to
 a fresh test folder. In our example, we can do this by taking advantage of an
 environment variable ``test-directory`` and the tool ``mktemp`` as follows::
 
-  $ test_directory=$(mktemp -d -t "tezos-node-mainnet-XXXX") && cp -r "/tmp/tezos-node-mainnet/." "$test_directory"
+  $ test_directory=$(mktemp -d -t "octez-node-mainnet-XXXX") && cp -r "/tmp/octez-node-mainnet/." "$test_directory"
 
 This command creates a fresh test folder in the system's temp directory (in our
-example ``/tmp``) whose name is ``tezos-node-mainnet-XXXX``,
+example ``/tmp``) whose name is ``octez-node-mainnet-XXXX``,
 where the ``XXXX`` are four random alphanumerical characters, and sets the
 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
@@ -593,7 +593,7 @@ can do this with the following command::
 Then we repeat the commands above in order to create a fresh test folder, and to
 copy the context of the original folder into the test folder. In our example::
 
-  $ test_directory=$(mktemp -d -t "tezos-node-mainnet-XXXX") && cp -r "/tmp/tezos-node-mainnet/." "$test_directory"
+  $ test_directory=$(mktemp -d -t "octez-node-mainnet-XXXX") && cp -r "/tmp/octez-node-mainnet/." "$test_directory"
 
 Now we run the node in the test folder by invoking::
 
@@ -713,13 +713,13 @@ invoking the following eight commands)::
   $ ./scripts/user_activated_upgrade.sh src/proto_012_* 1617344
   $ ./scripts/patch-yes_node.sh
   $ make
-  $ ./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
+  $ ./octez-node snapshot import ~/mainnet.rolling --data-dir /tmp/octez-node-mainnet
+  $ ./octez-node identity generate --data-dir /tmp/octez-node-mainnet
+  $ dune exec devtools/yes_wallet/yes_wallet.exe -- create from context /tmp/octez-node-mainnet in /tmp/yes-wallet --active-bakers-only
 
 Copy original folder into test folder::
 
-  $ test_directory=$(mktemp -d -t "tezos-node-mainnet-XXXX") && cp -r "/tmp/tezos-node-mainnet/." "$test_directory"
+  $ test_directory=$(mktemp -d -t "octez-node-mainnet-XXXX") && cp -r "/tmp/octez-node-mainnet/." "$test_directory"
 
 Run the node`::
 
@@ -749,7 +749,7 @@ test folder, and by removing files ``/tmp/yes-wallet/wallet_lock`` and
 ``/tmp/yes-wallet/blocks``::
 
   $ rm -rf "$test_directory" && rm -f /tmp/yes-wallet/{blocks,wallet_lock};
-  $ test_directory=$(mktemp -d -t "tezos-node-mainnet-XXXX") && cp -r "/tmp/tezos-node-mainnet/." "$test_directory"
+  $ test_directory=$(mktemp -d -t "octez-node-mainnet-XXXX") && cp -r "/tmp/octez-node-mainnet/." "$test_directory"
 
 Run the node::
 
@@ -854,14 +854,14 @@ that the option ``-v`` is not required when specifying a log file).
 Each time the automatic test is run, Tezt creates a temporary folder under the
 system's temp directory with name ``tezt-XXXXXX``, where the ``XXXXXX`` are six
 random decimal figures. The content of the original context folder is copied on
-the fly in the test folder ``tezt-XXXXXX/tezos-node-test``, and a yes-wallet
+the fly in the test folder ``tezt-XXXXXX/octez-node-test``, and a yes-wallet
 folder is created on the fly in ``tezt-XXXXXX/yes-wallet``. The option
 ``--keep-temp`` in the command above keeps the temporary folder for the
 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::
 
-  $ ./octez-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/octez-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
@@ -912,7 +912,7 @@ Run the migration test::
 
 Run the resulting node (assuming temp folder ``/tmp/tezt-526039``)::
 
-  $ ./octez-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/octez-node-test --rpc-addr localhost &
 
 Use the client, to manually inspect the storage, or for example to bake new
 blocks with the following command::
@@ -922,7 +922,7 @@ blocks with the following command::
 To test again, kill the node::
 
   $ fg
-  ./octez-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/octez-node-test --rpc-addr localhost
   ^C
 
 And run the migration test::
diff --git a/docs/developer/testing.rst b/docs/developer/testing.rst
index efe91da8479f6b6cdca014603886546f483d3391..d028c2d941ba226a5d40dd01dc091e125a5d7166 100644
--- a/docs/developer/testing.rst
+++ b/docs/developer/testing.rst
@@ -173,8 +173,8 @@ 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
-``octez-node`` and ``octez-client``, to perform integration testing
+framework, combined with :doc:`a Python wrapper <python_testing_framework>`
+around ``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.
 
diff --git a/docs/introduction/howtoget.rst b/docs/introduction/howtoget.rst
index e2fa5df66d2b6d0e3fc5a13b22c48ddd7b5755e6..9a0cf87f4d44cb67b79f88527671f4e2c47a5150 100644
--- a/docs/introduction/howtoget.rst
+++ b/docs/introduction/howtoget.rst
@@ -164,16 +164,16 @@ the Alpha protocol.
 
 You can open a new shell session and run ``docker ps`` in it, to display all the available containers, e.g.::
 
-    8f3638fae48c  docker.io/tezos/tezos:latest  tezos-node            3 minutes ago  Up 3 minutes ago   0.0.0.0:8732->8732/tcp, 0.0.0.0:9732->9732/tcp  node-alpha
-    8ba4d6077e2d  docker.io/tezos/tezos:latest  tezos-baker --liq...  3 minutes ago  Up 31 seconds ago                                                  baker-alpha
-    3ee7fcbc2158  docker.io/tezos/tezos:latest  tezos-accuser         3 minutes ago  Up 35 seconds ago                                                  accuser-alpha
+    8f3638fae48c  docker.io/tezos/tezos:latest  octez-node            3 minutes ago  Up 3 minutes ago   0.0.0.0:8732->8732/tcp, 0.0.0.0:9732->9732/tcp  node-alpha
+    8ba4d6077e2d  docker.io/tezos/tezos:latest  octez-baker --liq...  3 minutes ago  Up 31 seconds ago                                                  baker-alpha
+    3ee7fcbc2158  docker.io/tezos/tezos:latest  octez-accuser         3 minutes ago  Up 35 seconds ago                                                  accuser-alpha
 
 
-The node's RPC interface will be available on localhost and can be queried with ``tezos-client``.
+The node's RPC interface will be available on localhost and can be queried with ``octez-client``.
 
 ::
 
-    docker exec node-alpha tezos-client rpc list
+    docker exec node-alpha octez-client rpc list
 
 Building Docker Images Locally
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -310,7 +310,7 @@ of variable ``$ocaml_version`` in file ``scripts/version.sh``). To get an enviro
 
    The command ``eval $(opam env)`` sets up required environment
    variables. OPAM will suggest to add it in your rc file. If, at any
-   point, you get an error like ``tezos-something: command not
+   point, you get an error like ``octez-something: command not
    found``, first thing to try is to (re)run ``eval $(opam
    env --switch $ocaml_version)`` (replace ``$ocaml_version`` with its value
    in ``scripts/version.sh``) to see if it fixes the problem.
diff --git a/docs/introduction/howtorun.rst b/docs/introduction/howtorun.rst
index 315dea10cb23d73573642355015a48ba3bdec996..afd4d8b784f574bf051f35dcaba2a5243fb8de20 100644
--- a/docs/introduction/howtorun.rst
+++ b/docs/introduction/howtorun.rst
@@ -221,14 +221,14 @@ If you are running the baker Docker image, you can watch the baker logs with
     docker ps
 
 If your container is running, its name will appear in the last column.
-For instance, if the name is ``mainnet_baker-014-PtKathma``, you can
+For instance, if the name is ``mainnet_baker-PtKathma``, you can
 view recent logs with::
 
-    docker logs mainnet_baker-014-PtKathma
+    docker logs mainnet_baker-PtKathma
 
 If you want to keep watching logs, use ``-f``::
 
-    docker logs mainnet_baker-014-PtKathma -f
+    docker logs mainnet_baker-PtKathma -f
 
 This allows you to know if you baked.
 You should see lines such as::
diff --git a/docs/introduction/howtouse.rst b/docs/introduction/howtouse.rst
index 794cb6c234d45b7c7f0dcaa4fa7a692e72874f36..106881d3ec2ef74de0844a41dc065e173d01fee6 100644
--- a/docs/introduction/howtouse.rst
+++ b/docs/introduction/howtouse.rst
@@ -29,7 +29,7 @@ After a successful compilation, you should have the following binaries:
 
 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, ``octez-baker-014-PtKathma`` is the baker
+For instance, ``octez-baker-PtKathma`` is the baker
 for the Kathmandu protocol, and ``octez-baker-alpha`` is the baker
 of the development protocol.
 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.
@@ -38,7 +38,7 @@ The ``octez-node`` daemon is not suffixed by any protocol name, because it is in
 Read The Manual
 ---------------
 
-All the Tezos binaries provide the ``--help`` option to display information about their usage, including the available options and the possible parameters.
+All the Octez binaries provide the ``--help`` option to display information about their usage, including the available options and the possible parameters.
 
 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::
@@ -71,7 +71,7 @@ To see the usage of one specific command, you may also type the command without
         Usage:
           [...]
 
-.. _tezos_client_protocol:
+.. _octez_client_protocol:
 
 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.::
 
@@ -81,7 +81,7 @@ Note that you can get the list of protocols known to the client with::
 
     octez-client list understood protocols
 
-The full command line documentation of the Tezos binaries supporting the ``man`` command is also available
+The full command line documentation of the Octez binaries supporting the ``man`` command is also available
 online: :doc:`../shell/cli-commands`.
 
 Node
@@ -248,7 +248,7 @@ Putting together all the above instructions, you may want to run a node as follo
 Client
 ------
 
-Tezos client can be used to interact with the node, it can query its
+Octez client can be used to interact with the node, it can query its
 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::
diff --git a/docs/introduction/install-opam.sh b/docs/introduction/install-opam.sh
index 007e5100492d3dfa99ece3646bd6a58543b83c93..48967f6f156d0fb4128aa4f9548f7953373040a1 100755
--- a/docs/introduction/install-opam.sh
+++ b/docs/introduction/install-opam.sh
@@ -28,6 +28,6 @@ eval $(opam env)
 # depext handling is done directly by opam 2.1 and later
 opam depext tezos
 # [install tezos]
-opam install tezos
+opam install octez
 # [test executables]
-tezos-client --version
+octez-client --version
diff --git a/docs/kathmandu/cli-commands.rst b/docs/kathmandu/cli-commands.rst
index 95e17d8a1c1a45220ad581e7e0617d3db56f802f..b61a23e2882b5583d25ce3e90d6f1b935384fae7 100644
--- a/docs/kathmandu/cli-commands.rst
+++ b/docs/kathmandu/cli-commands.rst
@@ -3,8 +3,8 @@ Command Line Interface
 **********************
 
 This document is a prettier output of the documentation produced by
-the command ``man`` of the different Tezos binaries. You can obtain similar pages
-using shell commands such as (:ref:`indicating the appropriate protocol <tezos_client_protocol>`):
+the command ``man`` of the different Octez binaries. You can obtain similar pages
+using shell commands such as (:ref:`indicating the appropriate protocol <octez_client_protocol>`):
 
 ::
 
diff --git a/docs/kathmandu/sapling.rst b/docs/kathmandu/sapling.rst
index 92a7d08a461d70193630de049c1dba6465d57a82..b7c0e475c80cfbeb36eb537d15b222fcfe17d074 100644
--- a/docs/kathmandu/sapling.rst
+++ b/docs/kathmandu/sapling.rst
@@ -485,7 +485,7 @@ unshielding.
    # set up the sandbox
    ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 &
    eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
-   tezos-activate-alpha
+   octez-activate-alpha
 
    # originate the contract with its initial empty sapling storage,
    # bake a block to include it.
diff --git a/docs/kathmandu/transaction_rollups.rst b/docs/kathmandu/transaction_rollups.rst
index 4cf39120e02ba4070bbbc8b70f7cf0e18f454a5e..b83751302797d2882a303ee3917798a2b80abebb 100644
--- a/docs/kathmandu/transaction_rollups.rst
+++ b/docs/kathmandu/transaction_rollups.rst
@@ -593,7 +593,7 @@ rollup node is to prepare its configuration file.
 
 .. code:: sh
 
-    tezos-tx-rollup-node-014-PtKathma init ${mode} config \
+    octez-tx-rollup-node-PtKathma init ${mode} config \
           for ${tx_rollup_address_or_name} \
           --data-dir ${data_dir} \
           --rpc-addr ${rpc_address} \
@@ -664,7 +664,7 @@ For instance,
 
 .. code:: sh
 
-    tezos-tx-rollup-node-014-PtKathma init batcher config for ${rollup}  \
+    octez-tx-rollup-node-PtKathma init batcher config for ${rollup}  \
           --data-dir /tmp/tx-node \
           --rpc-addr ${rollup_node_rpc_server_address} \
           --batch-signer ${batcher}
@@ -680,7 +680,7 @@ Once the configuration is ready, starting the rollup node is as simple as
 
 .. code:: sh
 
-    tezos-tx-rollup-node-014-PtKathma --endpoint ${tezos_node_address} \
+    octez-tx-rollup-node-PtKathma --endpoint ${tezos_node_address} \
           run ${mode} for ${rollup_address_or_name} \
           --data-dir ${data_dir} \
           [--allow-deposit]
@@ -819,7 +819,7 @@ the ``get balance`` command can be used.
 
 .. code:: sh
 
-    tezos-tx-rollup-client-014-PtKathma get balance for alice of ${ticket_hash}
+    octez-tx-rollup-client-PtKathma get balance for alice of ${ticket_hash}
 
 .. note::
 
@@ -830,7 +830,7 @@ To transfer a ticket to another address on the layer-2, the
 
 .. code:: sh
 
-    tezos-tx-rollup-client-014-PtKathma transfer ${qty} \
+    octez-tx-rollup-client-PtKathma transfer ${qty} \
           of ${ticket_hash} \
           from ${src} to ${dst} \
           [--endpoint ${tx_rollup_node_address}]
@@ -848,7 +848,7 @@ block, one can use the following command.
 
 .. code:: sh
 
-    tezos-tx-rollup-client-014-PtKathma get block ${block_id}
+    octez-tx-rollup-client-PtKathma get block ${block_id}
 
 where ``block_id`` can either be ``head`` (the latest rollup block), a
 level (0, 1, etc.), or a Tezos block hash.
@@ -858,7 +858,7 @@ rollup, and to inject it back in the layer-1.
 
 .. code:: sh
 
-    tezos-tx-rollup-client-014-PtKathma withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst}
+    octez-tx-rollup-client-PtKathma withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst}
 
 Similarly to the ``transfer`` command, ``l2_src`` has to be an alias
 to a BLS pair of keys, while ``l1_dst`` can either be an alias or an
@@ -890,7 +890,7 @@ To retrieve the values of ``micheline_contents``, ``ty`` and
 
 .. code:: sh
 
-    tezos-tx-rollup-client-014-PtKathma rpc get "/context/head/tickets/${ticket_hash}"
+    octez-tx-rollup-client-PtKathma rpc get "/context/head/tickets/${ticket_hash}"
 
 Besides, the entrypoint ``ep`` of ``sc_dst`` needs to expect a
 ``ticket ty`` as its input.
diff --git a/docs/lima/cli-commands.rst b/docs/lima/cli-commands.rst
index cef4283180f9a44aab303901a00fa31938f155bd..05324e738cf2b6d251fbd5e84889b02bdcea0547 100644
--- a/docs/lima/cli-commands.rst
+++ b/docs/lima/cli-commands.rst
@@ -3,8 +3,8 @@ Command Line Interface
 **********************
 
 This document is a prettier output of the documentation produced by
-the command ``man`` of the different Tezos binaries. You can obtain similar pages
-using shell commands such as (:ref:`indicating the appropriate protocol <tezos_client_protocol>`):
+the command ``man`` of the different Octez binaries. You can obtain similar pages
+using shell commands such as (:ref:`indicating the appropriate protocol <octez_client_protocol>`):
 
 ::
 
diff --git a/docs/lima/sapling.rst b/docs/lima/sapling.rst
index ddc03c08927d3090548c303abdb9e7bb6fcd1e74..0cbf62103edc51a8a2b4809a887e06fdad53abc2 100644
--- a/docs/lima/sapling.rst
+++ b/docs/lima/sapling.rst
@@ -485,7 +485,7 @@ unshielding.
    # set up the sandbox
    ./src/bin_node/octez-sandboxed-node.sh 1 --connections 0 &
    eval `./src/bin_client/octez-init-sandboxed-client.sh 1`
-   tezos-activate-alpha
+   octez-activate-alpha
 
    # originate the contract with its initial empty sapling storage,
    # bake a block to include it.
diff --git a/docs/lima/transaction_rollups.rst b/docs/lima/transaction_rollups.rst
index c09276365d122fd951ecdebfd6a1b65a4485f8a4..a1c1abdbc26e71baab81569afa41f3e194044714 100644
--- a/docs/lima/transaction_rollups.rst
+++ b/docs/lima/transaction_rollups.rst
@@ -598,7 +598,7 @@ rollup node is to prepare its configuration file.
 
 .. code:: sh
 
-    tezos-tx-rollup-node-alpha init ${mode} config \
+    octez-tx-rollup-node-alpha init ${mode} config \
           for ${tx_rollup_address_or_name} \
           --data-dir ${data_dir} \
           --rpc-addr ${rpc_address} \
@@ -669,7 +669,7 @@ For instance,
 
 .. code:: sh
 
-    tezos-tx-rollup-node-alpha init batcher config for ${rollup}  \
+    octez-tx-rollup-node-alpha init batcher config for ${rollup}  \
           --data-dir /tmp/tx-node \
           --rpc-addr ${rollup_node_rpc_server_address} \
           --batch-signer ${batcher}
@@ -685,7 +685,7 @@ Once the configuration is ready, starting the rollup node is as simple as
 
 .. code:: sh
 
-    tezos-tx-rollup-node-alpha --endpoint ${tezos_node_address} \
+    octez-tx-rollup-node-alpha --endpoint ${tezos_node_address} \
           run ${mode} for ${rollup_address_or_name} \
           --data-dir ${data_dir} \
           [--allow-deposit]
@@ -825,7 +825,7 @@ the ``get balance`` command can be used.
 
 .. code:: sh
 
-    tezos-tx-rollup-client-alpha get balance for alice of ${ticket_hash}
+    octez-tx-rollup-client-alpha get balance for alice of ${ticket_hash}
 
 .. note::
 
@@ -836,7 +836,7 @@ To transfer a ticket to another address on the layer-2, the
 
 .. code:: sh
 
-    tezos-tx-rollup-client-alpha transfer ${qty} \
+    octez-tx-rollup-client-alpha transfer ${qty} \
           of ${ticket_hash} \
           from ${src} to ${dst} \
           [--endpoint ${tx_rollup_node_address}]
@@ -854,7 +854,7 @@ block, one can use the following command.
 
 .. code:: sh
 
-    tezos-tx-rollup-client-alpha get block ${block_id}
+    octez-tx-rollup-client-alpha get block ${block_id}
 
 where ``block_id`` can either be ``head`` (the latest rollup block), a
 level (0, 1, etc.), or a Tezos block hash.
@@ -864,7 +864,7 @@ rollup, and to inject it back in the layer-1.
 
 .. code:: sh
 
-    tezos-tx-rollup-client-alpha withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst}
+    octez-tx-rollup-client-alpha withdraw ${qty} of ${ticket_hash} from ${l2_src} to ${l1_dst}
 
 Similarly to the ``transfer`` command, ``l2_src`` has to be an alias
 to a BLS pair of keys, while ``l1_dst`` can either be an alias or an
@@ -896,7 +896,7 @@ To retrieve the values of ``micheline_contents``, ``ty`` and
 
 .. code:: sh
 
-    tezos-tx-rollup-client-alpha rpc get "/context/head/tickets/${ticket_hash}"
+    octez-tx-rollup-client-alpha rpc get "/context/head/tickets/${ticket_hash}"
 
 Besides, the entrypoint ``ep`` of ``sc_dst`` needs to expect a
 ``ticket ty`` as its input.
diff --git a/docs/protocols/tenderbake.rst b/docs/protocols/tenderbake.rst
index 66f42092440c70eecf8c1be89e3a9d80ab62831d..39a24c32e713ed1114d987e696a3a13ba8fa9194 100644
--- a/docs/protocols/tenderbake.rst
+++ b/docs/protocols/tenderbake.rst
@@ -275,19 +275,19 @@ The baker daemon takes the same options as in Hangzhou.
 Client
 ------
 
-The command ``tezos-client bake for`` has been changed:
+The command ``octez-client bake for`` has been changed:
 
 - It takes a (possibly empty) list of delegate references. It then bakes a block and (pre)endorses this block, using the rights of all the specified delegates. When the list is empty is does so for all delegates whose secret keys are known.
 - It performs a full consensus round: it "proposes" a block (that is, it injects a block candidate), it preendorses the block, and it endorses the block, if possible.
 
 The following commands have been added:
 
-- ``tezos-client propose for``: forge and inject a candidate block (a `proposal`).
+- ``octez-client propose for``: forge and inject a candidate block (a `proposal`).
 
-- ``tezos-client preendorse for``: forge and inject a preendorsement operation.
+- ``octez-client preendorse for``: forge and inject a preendorsement operation.
 
-- ``tezos-client endorse for``: forge and inject an endorsement operation.
+- ``octez-client endorse for``: forge and inject an endorsement operation.
 
-- ``tezos-client set deposits limit for <src> to <deposits_limit>``: sets the deposits limit for a registered delegate.
+- ``octez-client set deposits limit for <src> to <deposits_limit>``: sets the deposits limit for a registered delegate.
 
-- ``tezos-client unset deposits limit for <src>``: remove the deposits limit of a registered delegate.
+- ``octez-client unset deposits limit for <src>``: remove the deposits limit of a registered delegate.
diff --git a/docs/releases/version-11.rst b/docs/releases/version-11.rst
index bf6aa99209c2e0e6b7ec8704e22f381e44b0589a..6ab8e82755ea7a9d2833173b074f47155badf9ab 100644
--- a/docs/releases/version-11.rst
+++ b/docs/releases/version-11.rst
@@ -31,7 +31,7 @@ To update from sources::
 
 If you are using Docker instead, use the ``v11.1`` Docker images of Tezos.
 
-If you are installing Octez using Opam, note that the required
+If you are installing Tezos using Opam, note that the required
 OCaml version is now 4.12.1. This means that you need to create a
 new switch with ``opam switch create 4.12.1`` before you run ``opam install tezos``.
 
diff --git a/docs/user/key-management.rst b/docs/user/key-management.rst
index 8c309f5e3dac8b211587640db9d2761590fc575b..7fcad5e88af84021831842c7df85fa0f57f1415d 100644
--- a/docs/user/key-management.rst
+++ b/docs/user/key-management.rst
@@ -163,7 +163,7 @@ 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.
 To select the ``tcp`` signing scheme, one has to launch ``octez-signer`` with the ``socket`` argument, as shown below.
-The new keys are stored by the signer in ``$HOME/.tezos-signer`` in the same format
+The new keys are stored by the signer in ``$HOME/.octez-signer`` in the same format
 as ``octez-client``.
 On our internet-facing virtual private server, called "vps" here, we can then import a key with the address
 of the signer.
@@ -171,7 +171,7 @@ of the signer.
 ::
 
    home~$ octez-signer gen keys alice
-   home~$ cat ~/.tezos-signer/public_key_hashs
+   home~$ cat ~/.octez-signer/public_key_hashs
    [ { "name": "alice", "value": "tz1abc..." } ]
    home~$ octez-signer launch socket signer -a home
 
@@ -238,7 +238,7 @@ client to authenticate before signing any operation.
 
 First we create a new key on the *vps* and then import it as an
 authorized key on *home* where it is stored under
-``.tezos-signer/authorized_keys`` (similarly to ``ssh``).
+``.octez-signer/authorized_keys`` (similarly to ``ssh``).
 Note that this key is only used to authenticate the client to the
 signer and it is not used as a Tezos account.
 
diff --git a/docs/user/light.rst b/docs/user/light.rst
index f42dda6af5d4798305b82ae14bb846c07f986683..1daef4d642556427840df0c8766c99aa5733b49d 100644
--- a/docs/user/light.rst
+++ b/docs/user/light.rst
@@ -104,7 +104,7 @@ Then upgrade the node to protocol alpha:
 
 ::
 
-    $ tezos-activate-alpha  # Triggers output in terminal of first node
+    $ octez-activate-alpha  # 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):
diff --git a/docs/user/logging.rst b/docs/user/logging.rst
index 1ab6993d42b51d1f1ec9565ac8b1893bd5c5e610..3c3155b91f085c6bed88af902158c78c84d1bfee 100644
--- a/docs/user/logging.rst
+++ b/docs/user/logging.rst
@@ -203,7 +203,7 @@ Environment Variables
 The logging framework can be configured with environment variables
 before starting the node. Those variables work on all the code using the
 ``tezos-stdlib-unix`` library as long as ``Internal_event_unix.init`` is
-called; this should include *all* the regular ``tezos-*`` binaries.
+called; this should include *all* the regular ``octez-*`` binaries.
 
 -  ``TEZOS_EVENTS_CONFIG`` must be a whitespace-separated list of URIs:
 
diff --git a/docs/user/proxy-server.rst b/docs/user/proxy-server.rst
index 1ba8043d7430c4466b1fc75188adb08f301d7dc6..f9660ccb775388dd5f7e02cbd74dab953d759057 100644
--- a/docs/user/proxy-server.rst
+++ b/docs/user/proxy-server.rst
@@ -78,7 +78,7 @@ Then upgrade the node to protocol alpha:
 
 ::
 
-    $ tezos-activate-alpha
+    $ octez-activate-alpha
     $ octez-client bake for bootstrap1
 
 To avoid warnings being printed in upcoming commands (optional):