diff --git a/zip-0221.rst b/zip-0221.rst
index 668fc048..e9c51fa0 100644
--- a/zip-0221.rst
+++ b/zip-0221.rst
@@ -166,43 +166,6 @@ bandwidth and storage requirements for resource-limited clients like mobile or I
 devices.
 
 
-Security and Privacy Considerations
-===================================
-
-This ZIP imposes an additional validation cost on new blocks. While this validation cost
-is small, it may exacerbate any existing DoS opportunities, particularly during abnormal
-events like long reorgs. Fortunately, these costs are logarithmic in the number of delete
-and append operations. In the worst case scenario, a well-resourced attacker could
-maintain 2 chains of approximately equal length, and alternate which chain they extend.
-This would result in repeated reorgs of increasing length.
-
-Given the performance of Blake2b, we expect this validation cost to be negligible.
-However, it seems prudent to benchmark potential MMR implementations during the
-implementation process. Should the validation cost be higher than expected, there are
-several potential mitigations, e.g. holding recently seen nodes in memory after a reorg.
-
-Generally, header commitments have no impact on privacy. However, FlyClient has additional
-security and privacy implications. Because FlyClient is a motivating factor for this ZIP,
-it seems prudent to include a brief overview. A more in-depth security analysis of
-FlyClient should be performed before designing a FlyClient-based light client ecosystem
-for Zcash.
-
-FlyClient, like all light clients, requires a connection to a light client server. That
-server may collect information about client requests, and may use that information to
-attempt to deanonymize clients. However, because FlyClient proofs are non-interactive and
-publicly verifiable, they could be shared among many light clients after the initial
-server interaction.
-
-FlyClient proofs are probabilistic. When properly constructed, there is negligible
-probability that a dishonest chain commitment will be accepted by the verifier. The
-security analysis assumes adversary mining power is bounded by a known fraction of
-combined mining power of honest nodes, and cannot drop or tamper with messages between
-client and full nodes. It also assumes the client is connected to at least one full node
-and knows the genesis block. However, these security properties have not been examined
-closely in chain models with rapidly-adjusting difficulty.
-
-
-
 Specification
 =============
 
@@ -711,6 +674,42 @@ implementation that would join these commitments, but it is clearly not appropri
 Zcash as it exists.
 
 
+Security and Privacy Considerations
+===================================
+
+This ZIP imposes an additional validation cost on new blocks. While this validation cost
+is small, it may exacerbate any existing DoS opportunities, particularly during abnormal
+events like long reorgs. Fortunately, these costs are logarithmic in the number of delete
+and append operations. In the worst case scenario, a well-resourced attacker could
+maintain 2 chains of approximately equal length, and alternate which chain they extend.
+This would result in repeated reorgs of increasing length.
+
+Given the performance of Blake2b, we expect this validation cost to be negligible.
+However, it seems prudent to benchmark potential MMR implementations during the
+implementation process. Should the validation cost be higher than expected, there are
+several potential mitigations, e.g. holding recently seen nodes in memory after a reorg.
+
+Generally, header commitments have no impact on privacy. However, FlyClient has additional
+security and privacy implications. Because FlyClient is a motivating factor for this ZIP,
+it seems prudent to include a brief overview. A more in-depth security analysis of
+FlyClient should be performed before designing a FlyClient-based light client ecosystem
+for Zcash.
+
+FlyClient, like all light clients, requires a connection to a light client server. That
+server may collect information about client requests, and may use that information to
+attempt to deanonymize clients. However, because FlyClient proofs are non-interactive and
+publicly verifiable, they could be shared among many light clients after the initial
+server interaction.
+
+FlyClient proofs are probabilistic. When properly constructed, there is negligible
+probability that a dishonest chain commitment will be accepted by the verifier. The
+security analysis assumes adversary mining power is bounded by a known fraction of
+combined mining power of honest nodes, and cannot drop or tamper with messages between
+client and full nodes. It also assumes the client is connected to at least one full node
+and knows the genesis block. However, these security properties have not been examined
+closely in chain models with rapidly-adjusting difficulty.
+
+
 Additional Reading
 ==================