diff --git a/zip-0205.rst b/zip-0205.rst
index 639e042f..6ee35962 100644
--- a/zip-0205.rst
+++ b/zip-0205.rst
@@ -13,7 +13,7 @@
 Terminology
 ===========
 
-The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be 
+The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be
 interpreted as described in RFC 2119. [#RFC2119]_
 
 The terms "branch" and "network upgrade" in this document are to be interpreted as 
@@ -84,7 +84,7 @@ peer connections.
     /** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
     static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
 
-The implementation is similar to that for Overwinter which was described in 
+The implementation is similar to that for Overwinter which was described in
 [#zip-0201]_.
 
 Once Sapling activates on testnet or mainnet, Sapling nodes should take steps to:
@@ -118,13 +118,13 @@ This change does not affect mainnet.
 Backward compatibility
 ======================
 
-Prior to the network upgrade activating, Sapling and pre-Sapling nodes are 
-compatible and can connect to each other. However, Sapling nodes will have a 
-preference for connecting to other Sapling nodes, so pre-Sapling nodes will 
+Prior to the network upgrade activating, Sapling and pre-Sapling nodes are
+compatible and can connect to each other. However, Sapling nodes will have a
+preference for connecting to other Sapling nodes, so pre-Sapling nodes will
 gradually be disconnected in the run up to activation.
 
-Once the network upgrades, even though pre-Sapling nodes can still accept the 
-numerically larger protocol version used by Sapling as being valid, Sapling nodes 
+Once the network upgrades, even though pre-Sapling nodes can still accept the
+numerically larger protocol version used by Sapling as being valid, Sapling nodes
 will always disconnect peers using lower protocol versions.
 
 
diff --git a/zip-0206.rst b/zip-0206.rst
index 1df974cc..36467ff3 100644
--- a/zip-0206.rst
+++ b/zip-0206.rst
@@ -13,7 +13,7 @@
 Terminology
 ===========
 
-The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be 
+The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be
 interpreted as described in RFC 2119. [#RFC2119]_
 
 The term "network upgrade" in this document is to be interpreted as described in
@@ -82,7 +82,7 @@ from the set of peer connections::
     /** The period before a network upgrade activates, where connections to upgrading peers are preferred (in blocks). */
     static const int NETWORK_UPGRADE_PEER_PREFERENCE_BLOCK_PERIOD = 24 * 24 * 3;
 
-The implementation is similar to that for Overwinter which was described in 
+The implementation is similar to that for Overwinter which was described in
 [#zip-0201]_.
 
 Once Blossom activates on testnet or mainnet, Blossom nodes SHOULD take steps to:
@@ -96,11 +96,11 @@ Backward compatibility
 
 Prior to the network upgrade activating on each network, Blossom and pre-Blossom
 nodes are compatible and can connect to each other. However, Blossom nodes will
-have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will 
+have a preference for connecting to other Blossom nodes, so pre-Blossom nodes will
 gradually be disconnected in the run up to activation.
 
-Once the network upgrades, even though pre-Blossom nodes can still accept the 
-numerically larger protocol version used by Blossom as being valid, Blossom nodes 
+Once the network upgrades, even though pre-Blossom nodes can still accept the
+numerically larger protocol version used by Blossom as being valid, Blossom nodes
 will always disconnect peers using lower protocol versions.
 
 Unlike Overwinter and Sapling, Blossom does not define a new transaction version.