diff --git a/docs/shell/storage.rst b/docs/shell/storage.rst
index d39d7a0c631a8736c0ce46c7b7f4568d6a441669..63002457e4d99df75fd5200709b2bb6fe025d3fa 100644
--- a/docs/shell/storage.rst
+++ b/docs/shell/storage.rst
@@ -58,7 +58,7 @@ Pruning
 *******
 
 When the complete (hence, un-reorganizable) cycle is retrieved, it is
-archived with the *cemented cycles*. This process is
+archived in the *cemented cycles*. This process is
 called a **merge** and is performed asynchronously. Depending on which
 history mode is ran and on the amount of additional cycles, blocks
 and/or their associated metadata present in these cemented cycles may
diff --git a/docs/user/history_modes.rst b/docs/user/history_modes.rst
index dbb46b5501352d99f7dcf206ded6d158a3661766..846394efbe93d435068eb14ce607725a22e26093 100644
--- a/docs/user/history_modes.rst
+++ b/docs/user/history_modes.rst
@@ -7,7 +7,7 @@ history can be deleted as they are not required anymore.
 
 Three history modes are provided:
 
-- **Full** (default mode with 1 additional cycle)
+- **Full** (default mode with 1 :ref:`additional cycle <History_mode_additional_cycles>`)
 
   The node stores the minimal data since the genesis required to reconstruct
   (or 'replay') the complete chain's ledger state.
@@ -27,7 +27,7 @@ Three history modes are provided:
   * Downsides:
 
     - The node is not able to query the balances or staking rights
-      before the current checkpoint.
+      before the current :ref:`savepoint <history_markers>`.
     - Disk storage slowly increases as the node keeps the history.
 
   See how to :ref:`set up a full node<Set_up_a_full_node>`.
@@ -43,10 +43,10 @@ Three history modes are provided:
     + Can run on low resources architectures.
     + Can be bootstrapped within minutes, thanks to a rolling snapshot import.
 
-  * Downsides
+  * Downsides:
 
     - The node is not able to query block information of balances and
-      staking rights before the current checkpoint.
+      staking rights before the current :ref:`savepoint <history_markers>`.
     - The node does not help other nodes to bootstrap as it is not able to
       send the whole chain history.
 
@@ -88,11 +88,13 @@ kept cycles is high enough to allow the computation of rewards.
 See :ref:`Keeping additional cycles<History_mode_additional_cycles>` for
 details.
 
+.. _history_markers:
+
 History modes use some markers which are used to describe the state
 of the storage:
 
-- *checkpoint*: the most recently finalized block of the chain,
-- *savepoint*: the lowest level block that contains metadata,
+- *checkpoint*: the most recently :ref:`finalized block <finality>` of the chain,
+- *savepoint*: the lowest level block that contains :ref:`context <def_context>` data and :ref:`metadata <def_metadata>`,
 - *caboose*: the lowest level known block.
 
 For more details about what data are stored in each mode, refer to :doc:`../shell/storage`.
@@ -118,19 +120,18 @@ or use your configuration file as described in :doc:`here <node-configuration>`:
 
 Note that, since the full mode is the default one, this configuration is optional.
 
-You can then verify that your history mode is set to full by using the checkpoint RPC.
+You can then verify that your history mode is set to full by using the following RPC.
 
 .. code-block:: console
 
-   octez-client rpc get /chains/main/checkpoint
+   octez-client rpc get /config/history_mode
 
 .. code-block:: json
 
-    { "block": { "some": "data" },
-       "savepoint": 4096, "caboose": 0, "history_mode": "full" }
+   { "history_mode": "full" }
 
 In full mode, the savepoint is the last block which contains its
-metadata. The caboose is the last known block which is pruned (that
+context and metadata. The caboose is the last known block which is pruned (that
 contains partial data).
 
 .. _Set_up_a_rolling_node:
@@ -155,9 +156,10 @@ or use your configuration file as described in :doc:`here <node-configuration>`:
 In ``rolling`` mode, the caboose is the genesis at its early state,
 and then, it is updated to the last known block of the rolling
 window. The savepoint is moved in accordance to the number of
-configured additional cycles.
+configured additional cycles::
 
-``$ tezos rpc get /chains/main/checkpoint``
+  octez-client rpc get /chains/main/levels/caboose
+  octez-client rpc get /chains/main/levels/savepoint
 
 
 .. _Set_up_an_archive_node:
@@ -184,23 +186,22 @@ Keeping additional cycles
 -------------------------
 
 When running a node in ``full`` or ``rolling`` mode, you have a full
-access to the block information in a sliding window of
-history. Indeed, at each new cycle, a garbage collection phase removes
+access to the block information history in a sliding window of a given number
+of block levels. Indeed, at each new cycle, a garbage collection phase removes
 the ledger state and the block metadata (operation receipts, rewards
 updates, etc.) of blocks outside the offset of this sliding
-window. Depending on the network, a minimum number of cycles are
-kept. This number of cycles corresponds to the
-:ref:`preserved_cycles<ps_constants>` protocol parameter, which on
-mainnet is set to 5 cycles. However, the node is able to keep an
-additional number of cycles that is configurable.
+window. The number of cycles kept (beyond the current cycle) is the
+``blocks_preservation_cycles`` :ref:`protocol parameter <protocol_constants>`
+(set to 1 cycle on mainnet) plus a number of
+additional cycles which is configurable.
 
 By default, 1 additional cycle is kept for both ``full`` and
 ``rolling`` nodes. It is possible to increase this parameter to keep
 more history or, on the contrary, decrease it to reduce the storage
 size. For example, it is possible to run a node with *5* additional
-cycles. On mainnet, this would total *10 cycles* of complete history
+cycles. On mainnet, this would total *6 cycles* of complete history
 (approximately four weeks), as we keep 5 cycles beyond the minimal
-number of cycles, that is *5 + 5 = 10*.
+number of cycles, that is *1 + 5 = 6*.
 
 
 When initializing your node on an empty storage, you may specify the