diff --git a/spec/blocksync/communication.md b/spec/blocksync/communication.md
index 7ee719129..cfe424b96 100644
--- a/spec/blocksync/communication.md
+++ b/spec/blocksync/communication.md
@@ -67,6 +67,6 @@ If the checks pass, the `block` field of the requester is populated with the new
 `errorsCh   chan peerError` : size `maxPeerErrBuffer`
 
 `didProcessCh chan struct{}` : size `1`.
-The channel is created within the pool routine of the reactor and is used to signal that the reactor should check the block pool for new blocks. A message is sent to the channel after a fixed timeout (`trySyncTicker`). As we need two blocks to verify one of them (this is more clearly defined in [verification](#./verification.md), if we miss only on of them, we will not wait for the sync timer to time out, but rather try quickly again until we fetch both. 
+The channel is created within the pool routine of the reactor and is used to signal that the reactor should check the block pool for new blocks. A message is sent to the channel after a fixed timeout (`trySyncTicker`). As we need two blocks to verify one of them (this is more clearly defined in [verification](./verification.md), if we miss only on of them, we will not wait for the sync timer to time out, but rather try quickly again until we fetch both. 
 
 `switchToConsensusTicker`. In addition to the sync timeout, in the same routine, the reactor checks periodically whether the conditions to switch to consensus are fullfilled. 
\ No newline at end of file
diff --git a/spec/blocksync/readme.md b/spec/blocksync/readme.md
index 119c13931..beee8d26d 100644
--- a/spec/blocksync/readme.md
+++ b/spec/blocksync/readme.md
@@ -54,7 +54,7 @@ The Blocksync reactor is organised as a set of concurrent tasks:
 This section describes the Blocksync reactor and its internals including:
 - [Data structures used](./data_structures.md)
 - [Peer to peer communication pattern](./communication.md)
-- [Block Verification](./block_verification.md)
+- [Block Verification](./verification.md)
 
 More details on how to use the Blocksync reactor and configure it when running Tendermint can be found [here](./../docs/tendermint-core/block-sync/README.md).
 
diff --git a/spec/blocksync/verificaton.md b/spec/blocksync/verificaton.md
index 94276103e..39c40477b 100644
--- a/spec/blocksync/verificaton.md
+++ b/spec/blocksync/verificaton.md
@@ -3,7 +3,7 @@
 When blocksyncing, a node is not participating in conensus. It is receiving blocks that have already been decided and committed. To avoid being fooled by malicious peers, the node has to verify the received blocks before executing the transactions and storing the block in its store. 
 
 
-The verification in blocksync aims to apply the same logic as the [light client verification](#../light-client/verification.md). The model relies on the existence of an **initial trusted state**. 
+The verification in blocksync aims to apply the same logic as the [light client verification](../light-client/verification.md). The model relies on the existence of an **initial trusted state**. 
 
 Based on this state we verify subsequent blocks.