diff --git a/learn/protocol/sync-protocol/history-macro-sync.md b/learn/protocol/sync-protocol/history-macro-sync.md
index a3de13c..3e96cde 100644
--- a/learn/protocol/sync-protocol/history-macro-sync.md
+++ b/learn/protocol/sync-protocol/history-macro-sync.md
@@ -25,6 +25,8 @@ Towards receiving as many history chunks as optimally as possible, the node can
 2. a chunk index within the epoch; if the index of the chunk is 0, it receives history items from 0 to 999
 3. the closing macro block of the respective chunk; can be either an election or a checkpoint block
 
+### Final considerations
+
 As mentioned, this process can be made with many history nodes. History items are aggregated into chunks to avoid the time-consuming process of downloading item by item. Plus, requesting chunks from multiple nodes makes the process practical and accelerated. The syncing node makes this request continuously until it reaches the most recent history item. Mind that as the chain progresses, it might be required for the syncing node to re-request some of the requests mentioned above.
 
 Note that this is an extensive process. The syncing node must fetch data from as many nodes as possible to reach the endpoint faster and have a decentralized, thus consensual response that can prove the chain's integrity. Relying on a single node could result in receiving inaccurate data.
diff --git a/learn/protocol/sync-protocol/nodes-and-sync.md b/learn/protocol/sync-protocol/nodes-and-sync.md
index dde931b..e293ea7 100644
--- a/learn/protocol/sync-protocol/nodes-and-sync.md
+++ b/learn/protocol/sync-protocol/nodes-and-sync.md
@@ -37,6 +37,8 @@ History nodes rely on other history nodes to sync through two mechanisms:
 - [History Macro Sync](history-macro-sync.md)
 - [Block Live Sync](block-live-sync.md)
 
+## Other nodes
+
 In addition to the node types outlined, Nimiq PoS also features [prover nodes](/learn/protocol/prover-node.md) and [validator nodes](/learn/protocol/validators/validators-and-stakers.md):
 
 - Prover nodes play a crucial role in blockchain networks by generating zero-knowledge proofs that allow both light and full nodes to sync. While zero-knowledge proofs are small and easy to verify, generating them requires significant computational resources. Prover nodes are, therefore, responsible for generating these proofs and must have the necessary resources.
diff --git a/learn/protocol/validators/validator-keys.md b/learn/protocol/validators/validator-keys.md
index b693a25..062af0b 100644
--- a/learn/protocol/validators/validator-keys.md
+++ b/learn/protocol/validators/validator-keys.md
@@ -24,6 +24,8 @@ The [Schnorr](https://en.wikipedia.org/wiki/Schnorr_signature) signature scheme
 - The hot public key is stored in the validator as the `voting_key`
 - The hot private key is used for the validator to vote for macro block proposals and skip blocks
 
+### Why so many keys?
+
 Having 3 key pairs for validators adds layers of security and reduces the chance of compromising each key. Validators use their keys to sign blocks, vote for block proposals, and send staking contract transactions.
 
 The terminology of hot, warm, and cold keys outlines the frequency of key usage. The hot key is used more often and readily accessible for regular use. While still used regularly, the warm key is less frequently accessed. On the other hand, the cold key is meant to be kept offline and used less often, making it less susceptible to potential attacks.