diff --git a/rendered/zip-0227.html b/rendered/zip-0227.html
index 09a3cd179..1231e710a 100644
--- a/rendered/zip-0227.html
+++ b/rendered/zip-0227.html
@@ -624,7 +624,7 @@
                     <span class="math">\(\mathsf{issued\_assets(AssetBase).final}\)</span>
                  to
                     <span class="math">\(1\)</span>
-                 in the global state immediately after the block in which this transaction occurs.</li>
+                 in the global state.</li>
                 <li>(Replay Protection) If issue bundle is present, the fees MUST be greater than zero.</li>
             </ul>
         </section>
@@ -646,11 +646,6 @@
                 <li>We limit the size of the
                     <span class="math">\(\mathsf{asset\_desc}\)</span>
                  string to 512 bytes as it is a reasonable size to store metadata about the Asset, for example in JSON format.</li>
-                <li>We require a check whether the
-                    <span class="math">\(\mathsf{finalize}\)</span>
-                 flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the
-                    <span class="math">\(\mathsf{issued\_assets}\)</span>
-                 map at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve.</li>
                 <li>We require non-zero fees in the presence of an issue bundle, in order to preclude the possibility of a transaction containing only an issue bundle. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack.</li>
             </ul>
             <section id="concrete-applications"><h3><span class="section-heading">Concrete Applications</span><span class="section-anchor"> <a rel="bookmark" href="#concrete-applications"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst
index 9dac2581d..4a981f2c8 100644
--- a/zips/zip-0227.rst
+++ b/zips/zip-0227.rst
@@ -362,7 +362,7 @@ If all of the above checks pass, do the following:
   - Add :math:`\mathsf{cm}` to the Merkle tree of note commitments.
   - Increase the value of :math:`\mathsf{issued\_assets(AssetBase).balance}` by the value of the note, :math:`\mathsf{v}`.
 
-- If :math:`\mathsf{finalize} = 1\!`, set :math:`\mathsf{issued\_assets(AssetBase).final}` to :math:`1` in the global state immediately after the block in which this transaction occurs.
+- If :math:`\mathsf{finalize} = 1\!`, set :math:`\mathsf{issued\_assets(AssetBase).final}` to :math:`1` in the global state.
 
 - (Replay Protection) If issue bundle is present, the fees MUST be greater than zero.
 
@@ -382,7 +382,6 @@ The following is a list of rationale for different decisions made in the proposa
     - information to be committed by the issuer, though not enforceable by the protocol.
 
 - We limit the size of the :math:`\mathsf{asset\_desc}` string to 512 bytes as it is a reasonable size to store metadata about the Asset, for example in JSON format.
-- We require a check whether the :math:`\mathsf{finalize}` flag only has been set in a previous block rather than a previous transaction in the same block. In other words, we only update the :math:`\mathsf{issued\_assets}` map at the block boundary. This is in keeping with the current property which allows for a miner to reorder transactions in a block without changing the meaning, which we aim to preserve.
 - We require non-zero fees in the presence of an issue bundle, in order to preclude the possibility of a transaction containing only an issue bundle. If a transaction includes only an issue bundle, the SIGHASH transaction hash would be computed solely based on the issue bundle. A duplicate bundle would have the same SIGHASH transaction hash, potentially allowing for a replay attack.
 
 Concrete Applications