diff --git a/specs/bellatrix/p2p-interface.md b/specs/bellatrix/p2p-interface.md
index 964a77464..2f07068fe 100644
--- a/specs/bellatrix/p2p-interface.md
+++ b/specs/bellatrix/p2p-interface.md
@@ -202,7 +202,7 @@ always by simultaneously respected.
 
 ### Why allow invalid payloads on the P2P network?
 
-The specification allows blocks with invalid payloads to propagate across
+The specification allows blocks with invalid execution payloads to propagate across
 gossip and via RPC calls. The reasoning for this is as follows:
 
 1. Optimistic nodes must listen to block gossip to obtain a view of the head of
@@ -213,8 +213,8 @@ gossip and via RPC calls. The reasoning for this is as follows:
    to requests for the parent via RPC.
 4. Therefore, optimistic nodes must send optimistic blocks via RPC.
 
-So, to prevent network segregation from optimistic nodes accidentally sending
-invalid payloads, nodes should never downscore/disconnect nodes due to invalid
+So, to prevent network segregation from optimistic nodes inadvertently sending
+invalid execution payloads, nodes should never downscore/disconnect nodes due to such invalid
 payloads. This does open the network to some DoS attacks from invalid execution
 payloads, but the scope of actors is limited to validators who can put those
 payloads in valid (and slashable) beacon blocks. Therefore, it is argued that
diff --git a/sync/optimistic.md b/sync/optimistic.md
index cb45b7036..88dc28444 100644
--- a/sync/optimistic.md
+++ b/sync/optimistic.md
@@ -116,16 +116,16 @@ from an execution engine. I.e., perform the following transitions:
 - `SYNCING` -> `INVALID`
 
 When a block transitions from `SYNCING` -> `VALID`, all *ancestors* of the
-block MUST also transition from `SYNCING` -> `VALID`. Such a block is no longer
+block MUST also transition from `SYNCING` -> `VALID`. Such a block and any previously `SYNCING` ancestors are no longer
 considered "optimistically imported".
 
 When a block transitions from `SYNCING` -> `INVALID`, all *descendants* of the
 block MUST also transition from `SYNCING` -> `INVALID`.
 
-When a block transitions from the `SYNCING` state it is removed from the set of
+When a block transitions from the `SYNCING` state, it is removed from the set of
 `store.optimistic_roots`.
 
-When a "merge block" (i.e. a block which enables execution) is declared to be
+When a "merge block" (i.e. the first block which enables execution in a chain) is declared to be
 `VALID` by an execution engine (either directly or indirectly), the full
 [`validate_merge_block`][] MUST be run against the merge block. If the block
 fails [`validate_merge_block`][], the merge block MUST be treated the same as