Some smaller updates

rendered/zip-0226.html

@@ -78,7 +78,7 @@
         <section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
             <p>Most of the protocol is kept the same as the Orchard protocol released with NU5, except for the following.</p>
             <section id="asset-identifiers"><h3><span class="section-heading">Asset Identifiers</span><span class="section-anchor"> <a rel="bookmark" href="#asset-identifiers"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h3>
-                <p>For every new Asset, there must be a new and unique Asset Identifier. Every Asset is defined by an <em>Asset description</em>,
+                <p>For every new Asset, there MUST be a new and unique Asset Identifier. Every Asset is defined by an <em>Asset description</em>,
                     <span class="math">\(\mathsf{asset\_desc}\!\)</span>
                 , which is a global byte string (scoped across all future versions of Zcash). From this Asset description and the issuance validating key of the issuer, the specific Asset Identifier,
                     <span class="math">\(\mathsf{AssetId}\!\)</span>

rendered/zip-0227.html

@@ -266,7 +266,7 @@
             </section>
         </section>
         <section id="specification-asset-identifier"><h2><span class="section-heading">Specification: Asset Identifier</span><span class="section-anchor"> <a rel="bookmark" href="#specification-asset-identifier"><img width="24" height="24" class="section-anchor" src="assets/images/section-anchor.png" alt=""></a></span></h2>
-            <p>For every new Asset, there must be a new and unique Asset Identifier, denoted
+            <p>For every new Asset, there MUST be a new and unique Asset Identifier, denoted
                 <span class="math">\(\mathsf{AssetId}\!\)</span>
             . We define this to be a globally unique pair
                 <span class="math">\(\mathsf{AssetId} := (\mathsf{ik}, \mathsf{asset\_desc})\!\)</span>
@@ -390,7 +390,7 @@
                     <span class="math">\(\mathsf{AssetDigest} \in \mathsf{previously\_finalized}\!\)</span>
                 , no further tokens can be issued, so as seen below, the validators will reject the transaction. For Assets with
                     <span class="math">\(\mathsf{AssetDigest} \not\in \mathsf{previously\_finalized}\!\)</span>
-                , new issuance actions can be issued in future transactions. These must use the same Asset description,
+                , new issuance actions can be issued in future transactions. These MUST use the same Asset description,
                     <span class="math">\(\mathsf{asset\_desc}\!\)</span>
                 , and can either maintain
                     <span class="math">\(\mathsf{finalize} = 0\)</span>

zips/zip-0226.rst

@@ -74,7 +74,7 @@ Most of the protocol is kept the same as the Orchard protocol released with NU5,
 Asset Identifiers
 -----------------
 
-For every new Asset, there must be a new and unique Asset Identifier. Every Asset is defined by an *Asset description*, :math:`\mathsf{asset\_desc}\!`, which is a global byte string (scoped across all future versions of Zcash). From this Asset description and the issuance validating key of the issuer, the specific Asset Identifier, :math:`\mathsf{AssetId}\!`, the Asset Digest, and the Asset Base (:math:`\mathsf{AssetBase}\!`) are derived as defined in ZIP 227 [#zip-0227]_.
+For every new Asset, there MUST be a new and unique Asset Identifier. Every Asset is defined by an *Asset description*, :math:`\mathsf{asset\_desc}\!`, which is a global byte string (scoped across all future versions of Zcash). From this Asset description and the issuance validating key of the issuer, the specific Asset Identifier, :math:`\mathsf{AssetId}\!`, the Asset Digest, and the Asset Base (:math:`\mathsf{AssetBase}\!`) are derived as defined in ZIP 227 [#zip-0227]_.
 
 This Asset Base will be the base point of the value commitment for the specific Custom Asset. Note that the Asset Base of the ZEC Asset will be kept as the original value base point, :math:`\mathcal{V}^{\mathsf{Orchard}}\!`.
 

zips/zip-0227.rst

@@ -185,7 +185,7 @@ where the :math:`\mathsf{Verify}` algorithm is defined in BIP 340 [#bip-0340]_.
 Specification: Asset Identifier
 ===============================
 
-For every new Asset, there must be a new and unique Asset Identifier, denoted :math:`\mathsf{AssetId}\!`. We define this to be a globally unique pair :math:`\mathsf{AssetId} := (\mathsf{ik}, \mathsf{asset\_desc})\!`, where :math:`\mathsf{ik}` is the issuance key and :math:`\mathsf{asset\_desc}` is a byte string.
+For every new Asset, there MUST be a new and unique Asset Identifier, denoted :math:`\mathsf{AssetId}\!`. We define this to be a globally unique pair :math:`\mathsf{AssetId} := (\mathsf{ik}, \mathsf{asset\_desc})\!`, where :math:`\mathsf{ik}` is the issuance key and :math:`\mathsf{asset\_desc}` is a byte string.
 
 A given Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the Orchard-ZSA protocol and potentially future Zcash shielded protocols. For this Asset Identifier, we derive an Asset Digest, :math:`\mathsf{AssetDigest}\!`, which is simply is a :math:`\textsf{BLAKE2b-512}` hash of the Asset Identifier.
 From the Asset Digest, we derive a specific Asset Base within each shielded protocol using the applicable hash-to-curve algorithm. This Asset Base is included in shielded notes.
@@ -260,7 +260,10 @@ An issuance action, ``IssueAction``, is the instance of issuing a specific Custo
 - ``vNotes``: an array of ``Note`` containing the unencrypted output notes of the recipients of the Asset.
 - ``flagsIssuance``: a byte that stores the :math:`\mathsf{finalize}` boolean that defines whether the issuance of that specific Custom Asset is finalized or not.
 
-An asset's :math:`\mathsf{AssetDigest}` is added to the :math:`\mathsf{previously\_finalized}` set after a block that contains any issuance transaction for that asset with :math:`\mathsf{finalize} = 1\!`. It then cannot be removed from this set. For Assets with :math:`\mathsf{AssetDigest} \in \mathsf{previously\_finalized}\!`, no further tokens can be issued, so as seen below, the validators will reject the transaction. For Assets with :math:`\mathsf{AssetDigest} \not\in \mathsf{previously\_finalized}\!`, new issuance actions can be issued in future transactions. These must use the same Asset description, :math:`\mathsf{asset\_desc}\!`, and can either maintain :math:`\mathsf{finalize} = 0` or change it to :math:`\mathsf{finalize} = 1\!`, denoting that this Custom Asset cannot be issued after the containing block.
+An asset's :math:`\mathsf{AssetDigest}` is added to the :math:`\mathsf{previously\_finalized}` set after a block that contains any issuance transaction for that asset with :math:`\mathsf{finalize} = 1\!`. 
+It then cannot be removed from this set. For Assets with :math:`\mathsf{AssetDigest} \in \mathsf{previously\_finalized}\!`, no further tokens can be issued, so as seen below, the validators will reject the transaction. 
+For Assets with :math:`\mathsf{AssetDigest} \not\in \mathsf{previously\_finalized}\!`, new issuance actions can be issued in future transactions. These MUST use the same Asset description, :math:`\mathsf{asset\_desc}\!`, 
+and can either maintain :math:`\mathsf{finalize} = 0` or change it to :math:`\mathsf{finalize} = 1\!`, denoting that this Custom Asset cannot be issued after the containing block.
 
 
 +-----------------------------+--------------------------+-------------------------------------------+---------------------------------------------------------------------+