diff --git a/spec/blocksync/communication.md b/spec/blocksync/communication.md
index 9c2c8f40c..c3c8d3e1a 100644
--- a/spec/blocksync/communication.md
+++ b/spec/blocksync/communication.md
@@ -12,7 +12,7 @@ On startup, the reactor fires up four go routines:
 3. Handle p2p channel messages
 4. Process peer updates
 
-The pool routine picks out blocks form the block pool and processes them. It also checks whether the node  should switch to consensus. ToDo - change wording (Remove we, discuss whether the pool routing should be the one checking the condition for consensus).
+The pool routine picks out blocks form the block pool and processes them. It also checks whether the node  should switch to consensus.
 
 All messages that go through the p2p channel are processed within the `processBlockSyncCh` routine.
 
diff --git a/spec/blocksync/verification.md b/spec/blocksync/verification.md
index 0b3a1741d..6ee65f453 100644
--- a/spec/blocksync/verification.md
+++ b/spec/blocksync/verification.md
@@ -21,7 +21,7 @@ Currently there are two possible ways to obtain a trusted state :
 
 **Case 1 - blocksync from genesis**
 
-In this case we only verify that the validator hash of the block matches the validator set of the initial state. We will use the initially provided validator set for verification and further verify the block against witnesses. In this scenario, this state is very likely to be outside the trusting period. We will accept this block as a trusted state and store it inside the node's block store. 
+In this case we only verify that the validator hash of the block matches the validator set of the initial state. We will use the initially provided validator set for verification and further verify the block against witne+sses. In this scenario, this state is very likely to be outside the trusting period. We will accept this block as a trusted state and store it inside the node's block store. 
 
 It is worth noting that, running block sync from the first height is significantly slower than running statesync first. However, statesync does not keep the entire blockchain history and some operators might opt not to state sync. The reason is that, if sufficiently many nodes state sync and other nodes who have historical data fail or leave the network, we have no history.