diff --git a/specs/altair/validator.md b/specs/altair/validator.md
index 3511c77d5..c7b41dd8b 100644
--- a/specs/altair/validator.md
+++ b/specs/altair/validator.md
@@ -413,7 +413,7 @@ Subnet assignments are known `EPOCHS_PER_SYNC_COMMITTEE_PERIOD` epochs in advanc
 ENR advertisement is indicated by setting the appropriate bit(s) of the bitfield found under the `syncnets` key in the ENR corresponding to the derived `subnet_id`(s). 
 Any bits modified for the sync committee responsibilities are unset in the ENR after any validators have left the sync committee.
 
-*Note*: The first sync committee from phase 0 to the Altair fork will not be known until the fork happens which implies subnet assignments are not known until then. 
+  *Note*: The first sync committee from phase 0 to the Altair fork will not be known until the fork happens which implies subnet assignments are not known until then.
 Early sync committee members should listen for topic subscriptions from peers and employ discovery via the ENR advertisements near the fork boundary to form initial subnets 
 Some early sync committee rewards may be missed while the initial subnets form.
 
diff --git a/specs/phase0/p2p-interface.md b/specs/phase0/p2p-interface.md
index 9336fac82..e9e8e092c 100644
--- a/specs/phase0/p2p-interface.md
+++ b/specs/phase0/p2p-interface.md
@@ -1298,10 +1298,10 @@ Requests are segregated by protocol ID to:
 6. Parallelise RFCs (or Eth2 EIPs).
   By decoupling requests from one another, each RFC that affects the request protocol can be deployed/tested/debated independently
   without relying on a synchronization point to version the general top-level protocol.
-  1. This has the benefit that clients can explicitly choose which RFCs to deploy
-    without buying into all other RFCs that may be included in that top-level version.
-  2. Affording this level of granularity with a top-level protocol would imply creating as many variants
-    (e.g. /protocol/43-{a,b,c,d,...}) as the cartesian product of RFCs inflight, O(n^2).
+   1. This has the benefit that clients can explicitly choose which RFCs to deploy
+      without buying into all other RFCs that may be included in that top-level version.
+   2. Affording this level of granularity with a top-level protocol would imply creating as many variants
+      (e.g. /protocol/43-{a,b,c,d,...}) as the cartesian product of RFCs inflight, O(n^2).
 7. Allow us to simplify the payload of requests.
   Request-id’s and method-ids no longer need to be sent.
   The encoding/request type and version can all be handled by the framework.
diff --git a/specs/phase0/weak-subjectivity.md b/specs/phase0/weak-subjectivity.md
index 4137efade..fd1b3cc28 100644
--- a/specs/phase0/weak-subjectivity.md
+++ b/specs/phase0/weak-subjectivity.md
@@ -141,12 +141,12 @@ Clients should allow users to input a Weak Subjectivity Checkpoint at startup, a
 ### Weak Subjectivity Sync Procedure
 
 1. Input a Weak Subjectivity Checkpoint as a CLI parameter in `block_root:epoch_number` format,
-  where `block_root` (an "0x" prefixed 32-byte hex string) and `epoch_number` (an integer) represent a valid `Checkpoint`.
-  Example of the format:
+   where `block_root` (an "0x" prefixed 32-byte hex string) and `epoch_number` (an integer) represent a valid `Checkpoint`.
+   Example of the format:
 
-```
-0x8584188b86a9296932785cc2827b925f9deebacce6d72ad8d53171fa046b43d9:9544
-```
+   ```
+   0x8584188b86a9296932785cc2827b925f9deebacce6d72ad8d53171fa046b43d9:9544
+   ```
 
 2. Check the weak subjectivity requirements:
     - *IF* `epoch_number > store.finalized_checkpoint.epoch`,