diff --git a/static/css/style.css b/static/css/style.css
index e0a79a772..b0198bb43 100644
--- a/static/css/style.css
+++ b/static/css/style.css
@@ -418,9 +418,9 @@ div.math {
   display: block;
   overflow-x: auto;
   overflow-y: hidden;
-  margin: 2.6rem 1rem 2.6rem 1rem;
+  margin: 1rem 1rem 1rem 1rem;
   text-align: center;
-  padding: 2rem;
+  padding: 1rem;
 }
 
 a, a:visited {
diff --git a/zips/zip-0226.rst b/zips/zip-0226.rst
index 990555eb9..bbe5ef941 100644
--- a/zips/zip-0226.rst
+++ b/zips/zip-0226.rst
@@ -23,11 +23,13 @@ Terminology
 
 The key word "MUST" in this document is to be interpreted as described in BCP 14 [#BCP14]_ when, and only when, it appears in all capitals.
 
-The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_.
+The term "network upgrade" in this document is to be interpreted as described in ZIP 200. [#zip-0200]_
 
-The terms "Orchard" and "Action" in this document are to be interpreted as described in ZIP 224 [#zip-0224]_.
+The character § is used when referring to sections of the Zcash Protocol Specification. [#protocol]_
 
-The terms "Asset", "Custom Asset" and "Wrapped Asset" in this document are to be interpreted as described in ZIP 227 [#zip-0227]_.
+The terms "Orchard" and "Action" in this document are to be interpreted as described in ZIP 224. [#zip-0224]_
+
+The terms "Asset", "Custom Asset" and "Wrapped Asset" in this document are to be interpreted as described in ZIP 227. [#zip-0227]_
 
 We define the following additional terms:
 
@@ -90,7 +92,7 @@ An OrchardZSA note differs from an Orchard note [#protocol-notes]_ by additional
 where
 
 - $\mathsf{AssetBase} : \mathbb{P}^*$ is the unique element of the Pallas group [#protocol-pallasandvesta]_ that identifies each Asset in the Orchard protocol, defined as the Asset Base in ZIP 227 [#zip-0227-assetidentifier]_, a valid group element that is not the identity and is not $\bot$. The byte representation of the Asset Base is defined as $\mathsf{asset\_base} : \mathbb{B}^{[\ell_{\mathbb{P}}]} := \mathsf{repr}_{\mathbb{P}}(\mathsf{AssetBase})$.
-- The remaining terms are as defined in §3.2 of the protocol specification [#protocol-notes]_.
+- The remaining terms are as defined in §3.2 ‘Notes’ [#protocol-notes]_.
 
 Note that the above assumes a canonical encoding, which is true for the Pallas group, but may not hold for future shielded protocols.
 
@@ -98,7 +100,7 @@ Let $\mathsf{Note^{OrchardZSA}}$ be the type of a OrchardZSA note, i.e.
 
 .. math:: \mathsf{Note^{OrchardZSA}} := \mathbb{B}^{[\ell_{\mathsf{d}}]} \times \mathsf{KA}^{\mathsf{Orchard}}.\mathsf{Public} \times \{0 .. 2^{\ell_{\mathsf{value}}} - 1\} \times \mathbb{P}^* \times \mathbb{F}_{q_{\mathbb{P}}} \times \mathbb{F}_{q_{\mathbb{P}}} \times \mathsf{NoteCommit^{Orchard}.Trapdoor}, 
 
-where $\mathbb{P}^*$ is the Pallas group excluding the identity element, and the other types are as defined in §3.2 of the protocol specification [#protocol-notes]_.
+where $\mathbb{P}^*$ is the Pallas group excluding the identity element, and the other types are as defined in §3.2 ‘Notes’ [#protocol-notes]_.
 
 **Non-normative note:** 
 The type and definition of the OrchardZSA note reflect that it is a tuple of all the components of an Orchard note, with the addition of the Asset Base into the tuple. 
@@ -113,8 +115,8 @@ We define the note commitment scheme $\mathsf{NoteCommit^{OrchardZSA}_{rcm}}$ as
   $\hspace{1em}\times\, \mathbb{F}_{q_{\mathbb{P}}}\hspace{-1em}$
   $\hspace{1em}\times\, \mathbb{P}^* \to \mathsf{NoteCommit^{Orchard}.Output}$
 
-where $\mathbb{P}, \ell_{\mathbb{P}}, q_{\mathbb{P}}$ are as defined for the Pallas curve [#protocol-pallasandvesta]_, and where $\mathsf{NoteCommit^{Orchard}.\{Trapdoor, Output\}}$ are as defined in the Zcash protocol specification [#protocol-abstractcommit]_.
-This note commitment scheme is instantiated using the Sinsemilla Commitment [#protocol-concretesinsemillacommit]_ as follows:
+where $\mathbb{P}, \ell_{\mathbb{P}}, q_{\mathbb{P}}$ are as defined for the Pallas curve [#protocol-pallasandvesta]_, and where $\mathsf{NoteCommit^{Orchard}.\{Trapdoor, Output\}}$ are as defined in §4.1.8 ‘Commitment’ [#protocol-abstractcommit]_.
+This uses the note commitment scheme defined in §5.4.8.4 ‘Sinsemilla Commitments’ [#protocol-concretesinsemillacommit]_ as follows:
 
 .. math::
     \mathsf{NoteCommit^{OrchardZSA}_{rcm}}(\mathsf{g_d}\star, \mathsf{pk_d}\star, \mathsf{v}, \text{ρ}, \text{ψ}, \mathsf{AssetBase}) :=
@@ -130,9 +132,9 @@ where:
   $\hspace{6em}\,||\, \mathsf{I2LEBSP}_{\ell^{\mathsf{Orchard}}_{\mathsf{base}}}(\text{ψ}) \,||\, \mathsf{asset\_base})\hspace{-4em}$
   $\hspace{4em}\,+\; [\mathsf{rcm}]\,\mathsf{GroupHash}^{\mathbb{P}}(\texttt{“z.cash:Orchard-NoteCommit-r”}, \texttt{“”})$
 
-Note that $\mathsf{repr}_{\mathbb{P}}$ and $\mathsf{GroupHash}^{\mathbb{P}}$ are as defined for the Pallas curve [#protocol-pallasandvesta]_, $\ell^{\mathsf{Orchard}}_{\mathsf{base}}$ is as defined in §5.3 [#protocol-constants]_, and $\mathsf{I2LEBSP}$ is as defined in §5.1 [#protocol-endian]_ of the Zcash protocol specification.
+Note that $\mathsf{repr}_{\mathbb{P}}$ and $\mathsf{GroupHash}^{\mathbb{P}}$ are as defined for the Pallas curve [#protocol-pallasandvesta]_, $\ell^{\mathsf{Orchard}}_{\mathsf{base}}$ is as defined in §5.3 ‘Constants’ [#protocol-constants]_, and $\mathsf{I2LEBSP}$ is as defined in §5.1 ‘Integers, Bit Sequences, and Endianness’ [#protocol-endian]_.
 
-The nullifier is generated in the same manner as in the Orchard protocol [#protocol-commitmentsandnullifiers]_.
+The nullifier is generated in the same manner as in the Orchard protocol §4.16 ‘Computing ρ values and Nullifiers’ [#protocol-rhoandnullifiers]_.
 
 The OrchardZSA note plaintext also includes the Asset Base in addition to the components in the Orchard note plaintext [#protocol-notept]_.
 It consists of
@@ -265,7 +267,7 @@ For Split Notes, the nullifier is generated as follows:
 
 .. math:: \mathsf{nf_{old}} = \mathsf{Extract}_{\mathbb{P}} ([(\mathsf{PRF^{nfOrchard}_{nk}} (\text{ρ}^{\mathsf{old}}) + \text{ψ}^{\mathsf{nf}}) \bmod q_{\mathbb{P}}]\,\mathcal{K}^\mathsf{Orchard} + \mathsf{cm^{old}} + \mathcal{L}^\mathsf{Orchard})
 
-where $\text{ψ}^{\mathsf{nf}}$ is sampled uniformly at random on $\mathbb{F}_{q_{\mathbb{P}}}$, $\mathcal{K}^{\mathsf{Orchard}}$ is the Orchard Nullifier Base as defined in [#protocol-commitmentsandnullifiers]_, and $\mathcal{L}^{\mathsf{Orchard}} := \mathsf{GroupHash^{\mathbb{P}}}(\texttt{“z.cash:Orchard”}, \texttt{“L”})$.
+where $\text{ψ}^{\mathsf{nf}}$ is sampled uniformly at random on $\mathbb{F}_{q_{\mathbb{P}}}$, $\mathcal{K}^{\mathsf{Orchard}}$ is the Orchard Nullifier Base as defined in §4.16 ‘Computing ρ values and Nullifiers’ [#protocol-rhoandnullifiers]_, and $\mathcal{L}^{\mathsf{Orchard}} := \mathsf{GroupHash^{\mathbb{P}}}(\texttt{“z.cash:Orchard”}, \texttt{“L”})$.
 
 Rationale for Split Notes
 `````````````````````````
@@ -423,7 +425,7 @@ References
 .. [#protocol-abstractcommit] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.1.8: Commitment <protocol/protocol.pdf#abstractcommit>`_
 .. [#protocol-orcharddummynotes] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.8.3: Dummy Notes (Orchard) <protocol/protocol.pdf#orcharddummynotes>`_
 .. [#protocol-orchardbalance] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.14: Balance and Binding Signature (Orchard) <protocol/protocol.pdf#orchardbalance>`_
-.. [#protocol-commitmentsandnullifiers] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.16: Computing ρ values and Nullifiers <protocol/protocol.pdf#commitmentsandnullifiers>`_
+.. [#protocol-rhoandnullifiers] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.16: Computing ρ values and Nullifiers <protocol/protocol.pdf#rhoandnullifiers>`_
 .. [#protocol-actionstatement] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.18.4: Action Statement (Orchard) <protocol/protocol.pdf#actionstatement>`_
 .. [#protocol-endian] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.1: Integers, Bit Sequences, and Endianness <protocol/protocol.pdf#endian>`_
 .. [#protocol-constants] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.3: Constants <protocol/protocol.pdf#constants>`_
diff --git a/zips/zip-0227-asset-identifier-relation-orchard-zsa.svg b/zips/zip-0227-asset-identifier-relation-orchard-zsa.svg
index 200c2be19..897586a4d 100644
--- a/zips/zip-0227-asset-identifier-relation-orchard-zsa.svg
+++ b/zips/zip-0227-asset-identifier-relation-orchard-zsa.svg
@@ -25,11 +25,11 @@
      borderopacity="1.0"
      inkscape:pageopacity="0.0"
      inkscape:pageshadow="2"
-     inkscape:zoom="0.5"
-     inkscape:cx="631"
-     inkscape:cy="218"
+     inkscape:zoom="0.60419345"
+     inkscape:cx="734.86398"
+     inkscape:cy="79.444754"
      inkscape:document-units="px"
-     inkscape:current-layer="layer1"
+     inkscape:current-layer="g481-4"
      showgrid="false"
      inkscape:window-width="1068"
      inkscape:window-height="916"
@@ -360,14 +360,14 @@
          style="fill:#ffeeaa;fill-opacity:1;stroke:#000000;stroke-width:1.1017;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" /><text
          id="text3755-4-4-7"
          y="908.06061"
-         x="585.96448"
+         x="566.94745"
          style="font-style:normal;font-weight:normal;font-size:20.9503px;line-height:125%;font-family:Sans;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.06667"
          xml:space="preserve"><tspan
            y="908.06061"
-           x="585.96448"
+           x="566.94745"
            sodipodi:role="line"
            style="font-size:20.9503px;stroke-width:1.06667"
-           id="tspan310-1-3">ik</tspan></text><text
+           id="tspan310-1-3">issuer</tspan></text><text
          id="text3755-4-4-7-8"
          y="861.14099"
          x="605.17181"
@@ -378,7 +378,7 @@
            x="605.17181"
            sodipodi:role="line"
            style="font-size:13.9668px;stroke-width:1.12713"
-           id="tspan310-1-3-3">[32 bytes]</tspan></text><text
+           id="tspan310-1-3-3">[33 bytes]</tspan></text><text
          id="text3759-9-8-1-3"
          y="906.77618"
          x="557.94751"
@@ -468,4 +468,4 @@
          sodipodi:role="line"
          id="tspan833"
          x="273.71552"
-         y="976.58667">[65 bytes]</tspan></text></g></svg>
+         y="976.58667">[66 bytes]</tspan></text></g></svg>
diff --git a/zips/zip-0227-key-components-zsa.svg b/zips/zip-0227-key-components-zsa.svg
index eb38e4dcb..4f30b6b0a 100644
--- a/zips/zip-0227-key-components-zsa.svg
+++ b/zips/zip-0227-key-components-zsa.svg
@@ -26,7 +26,7 @@
      inkscape:pageopacity="0.0"
      inkscape:pageshadow="2"
      inkscape:zoom="0.80392436"
-     inkscape:cx="183.47497"
+     inkscape:cx="220.16997"
      inkscape:cy="176.63353"
      inkscape:document-units="px"
      inkscape:current-layer="layer1"
@@ -34,7 +34,7 @@
      inkscape:window-width="1068"
      inkscape:window-height="916"
      inkscape:window-x="222"
-     inkscape:window-y="102"
+     inkscape:window-y="38"
      inkscape:window-maximized="0"
      inkscape:showpageshadow="2"
      inkscape:pagecheckerboard="0"
@@ -167,13 +167,13 @@
        inkscape:export-filename="zip-0227-key-components-zsa.png"
        inkscape:export-xdpi="179.99957"
        inkscape:export-ydpi="179.99957" /><rect
-       ry="24.761904"
-       y="876.77173"
-       x="77.849838"
-       height="51.809525"
-       width="80.000008"
+       ry="24.685884"
+       y="876.85126"
+       x="63.758682"
+       height="51.650463"
+       width="105.96281"
        id="rect2985-9-7-8"
-       style="fill:#fdb341;fill-opacity:1;stroke:#000000;stroke-width:1.06667;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" /><text
+       style="fill:#fdb341;fill-opacity:1;stroke:#000000;stroke-width:1.22574;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" /><text
        id="text3850"
        y="909.8241"
        x="184.16003"
@@ -206,14 +206,13 @@
          style="stroke-width:1.06667">isk</tspan></text><text
        id="text3755-6-6"
        y="911.11285"
-       x="106.69933"
-       style="font-style:normal;font-weight:normal;font-size:25.6px;line-height:125%;font-family:Sans;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.06667"
+       x="104.69933"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:25.6px;line-height:125%;font-family:Sans;-inkscape-font-specification:'Sans, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1.06667"
        xml:space="preserve"><tspan
-         y="911.11285"
-         x="106.69933"
-         id="tspan3757-7-0"
          sodipodi:role="line"
-         style="stroke-width:1.06667">ik</tspan></text><text
+         id="tspan200"
+         x="104.69933"
+         y="911.11285">ik</tspan></text><text
        id="text3850-3-0"
        y="1019.9116"
        x="184.15979"
diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst
index 0fd1f6eb5..859edacb5 100644
--- a/zips/zip-0227.rst
+++ b/zips/zip-0227.rst
@@ -25,6 +25,8 @@ The key words "MUST", "MUST NOT", "SHOULD", "RECOMMENDED", and "MAY" in this doc
 
 The term "network upgrade" in this document is to be interpreted as described in ZIP 200 [#zip-0200]_.
 
+The character § is used when referring to sections of the Zcash Protocol Specification. [#protocol]_
+
 The terms "Orchard" and "Action" in this document are to be interpreted as described in
 ZIP 224 [#zip-0224]_.
 
@@ -78,14 +80,17 @@ Requirements
 - Every "issuance action" should contain a $\mathsf{finalize}$ boolean that defines whether the specific Custom Asset can have further tokens issued or not.
 
 
-Specification: Issuance Keys and Issuance Authorization Signature Scheme
-========================================================================
+Specification: Issuance Keys, Issuer Identifier, and Issuance Authorization Signature Scheme
+============================================================================================
+
+Issuance Keys
+-------------
 
-The OrchardZSA Protocol adds the following keys to the key components [#protocol-addressesandkeys]_ [#protocol-orchardkeycomponents]_:
+The OrchardZSA Protocol adds the following keys used for issuance:
 
 1. The issuance authorizing key, denoted as $\mathsf{isk}$, is the key used to authorize the issuance of Asset Identifiers by a given issuer, and is only used by that issuer.
 
-2. The issuance validating key, denoted as $\mathsf{ik}$, is the key that is used to validate issuance transactions. This key is used to validate the issuance of Asset Identifiers by a given issuer, and is used by all blockchain users (specifically the owners of notes for that Asset, and consensus validators) to associate the Asset in question with the issuer.
+2. The issuance validating key, denoted as $\mathsf{ik}$, is the key that is used to validate issuance transactions. This key is used to validate the issuance of Asset Identifiers by a given issuer.
 
 The relations between these keys are shown in the following diagram:
 
@@ -97,11 +102,22 @@ The relations between these keys are shown in the following diagram:
     Diagram of Issuance Key Components for the OrchardZSA Protocol
 
 
+Issuer Identifier
+-----------------
+
+The identifier for a particular issuer is denoted by $\mathsf{issuer}$. This identifier is used by all blockchain users (specifically the owners of notes for that Asset, and consensus validators) to associate the Asset in question with the issuer.
+
+$\mathsf{issuer}$ is equal to the encoding $\mathsf{ik\_encoding}$ (specified below in `Derivation of issuance validating key`_) of the issuance validating key $\mathsf{ik}$ used to validate the issuance of Asset Identifiers by that issuer.
+
+Note: the equality of $\mathsf{issuer}$ and $\mathsf{ik\_encoding}$ might not hold in future when key rotation is specified for issuance key pairs.
+
+
 Issuance Authorization Signature Scheme
 ---------------------------------------
 
-The issuance authorization signature $\mathsf{issueAuthSig}$ is used to authorize the issuance of Custom Assets by the issuer.
-The issuance authorization signature scheme, $\mathsf{IssueAuthSig}$, comprises of all the associated types and algorithms defined in the protocol specification [#protocol-abstractsig]_.
+The issuance authorization signature, encoded in the ``issueAuthSig`` field of an issuance bundle, is used to authorize the issuance of Custom Assets by the issuer.
+
+The issuance authorization signature scheme, $\mathsf{IssueAuthSig}$, comprises all the associated types and algorithms required for a signature scheme in §4.1.7 ‘Signature’ [#protocol-abstractsig]_.
 
 Batch verification MAY be used. Precomputation MAY be used if and only if it produces equivalent results.
 
@@ -110,13 +126,12 @@ Orchard ZSA Issuance Authorization Signature Scheme
 
 In the OrchardZSA protocol, we instantiate the issuance authorization signature scheme $\mathsf{IssueAuthSig}$ as a BIP-340 Schnorr signature over the secp256k1 curve.
 We define the constants as per the secp256k1 standard parameters, as described in BIP 340.
-The encodings of the signature and the public key differ slightly from that of BIP 340, and we specify the changes in what follows. 
 
-The associated types of the $\mathsf{IssueAuthSig}$ signature scheme are as follows:
+The associated types of the $\mathsf{IssueAuthSig}$ signature scheme, which are identical to BIP 340, are as follows:
 
 * $\mathsf{IssueAuthSig.Message} = \mathbb{B}^{\mathbb{Y}^{[\mathbb{N}]}}$
-* $\mathsf{IssueAuthSig.Signature} = \mathbb{B}^{\mathbb{Y}^{[65]}} \cup \{\bot\}$
-* $\mathsf{IssueAuthSig.Public} = \mathbb{B}^{\mathbb{Y}^{[33]}} \cup \{\bot\}$
+* $\mathsf{IssueAuthSig.Signature} = \mathbb{B}^{\mathbb{Y}^{[64]}} \cup \{\bot\}$
+* $\mathsf{IssueAuthSig.Public} = \mathbb{B}^{\mathbb{Y}^{[32]}} \cup \{\bot\}$
 * $\mathsf{IssueAuthSig.Private} = \mathbb{B}^{\mathbb{Y}^{[32]}}$
 
 where $\mathbb{B}^{\mathbb{Y}^{[k]}}$ denotes the set of sequences of $k$ bytes, and $\mathbb{B}^{\mathbb{Y}^{[\mathbb{N}]}}$ denotes the type of byte sequences of arbitrary length, as defined in the Zcash protocol specification [#protocol-notation]_.
@@ -157,16 +172,19 @@ Derivation of issuance validating key
 
 Define $\mathsf{IssueAuthSig.DerivePublic} \;{\small ⦂}\; (\mathsf{isk} \;{\small ⦂}\; \mathsf{IssueAuthSig.Private}) \to \mathsf{IssueAuthSig.Public}$ as:
 
-* $\mathsf{ik} := \mathtt{0x00} || \textit{PubKey}(\mathsf{isk})$
+* $\mathsf{ik} := \textit{PubKey}(\mathsf{isk})$
 * Return $\bot$ if the $\textit{PubKey}$ algorithm invocation fails, otherwise return $\mathsf{ik}$.
 
 where the $\textit{PubKey}$ algorithm is defined in BIP 340 [#bip-0340]_, and the output of the algorithm is in big-endian order as defined in BIP 340.
-The encoding of $\mathsf{ik}$ begins with a version byte that is $\mathtt{0x00}$. This enables future ZIPs to specify alternative signature schemes.
+
+The encoding of this validating key, $\mathsf{ik\_encoding}$, includes an initial byte indicating the signature scheme, which MUST be $\mathtt{0x00}$ indicating BIP 340.
+That is, $\mathsf{ik\_encoding} = \mathtt{0x00} \,||\, \mathsf{ik}$. This enables future ZIPs to specify alternative signature schemes.
+Note that this encoding currently only appears in the ``issuer`` field of an issuance bundle.
 
 It is possible for the $\textit{PubKey}$ algorithm to fail with very low probability, which means that $\mathsf{IssueAuthSig.DerivePublic}$ could return $\bot$ with very low probability.
 If this happens, discard the keys and repeat with a different $\mathsf{isk}$.
 
-This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, generate a multi-signature protocol) while the rest of the keys remain in the wallet safe.
+This allows the issuer to use the same wallet it usually uses to transfer Assets, while keeping a disconnect from the other keys. Specifically, this method is aligned with the requirements and motivation of ZIP 32 [#zip-0032]_. It provides further anonymity and the ability to delegate issuance of an Asset (or in the future, use a multi-signature protocol) while the rest of the keys remain safe in the wallet.
 
 Issuance Authorization Signing and Validation
 ---------------------------------------------
@@ -174,23 +192,23 @@ Issuance Authorization Signing and Validation
 Define $\mathsf{IssueAuthSig.Sign} \;{\small ⦂}\; (\mathsf{isk} \;{\small ⦂}\; \mathsf{IssueAuthSig.Private}) \times (M \;{\small ⦂}\; \mathsf{IssueAuthSig.Message}) \to \mathsf{IssueAuthSig.Signature}$ as:
 
 * Let the auxiliary data $a = [\mathtt{0x00}]^{32}$.
-* Let $\text{σ} = \mathtt{0x00} || \mathsf{Sign}(\mathsf{isk}, M)$.
+* Let $\text{σ} = \mathsf{Sign}(\mathsf{isk}, M)$ with auxiliary data $a$.
 * Return $\bot$ if the $\mathsf{Sign}$ algorithm fails in the previous step, otherwise return $\text{σ}$.
 
-where the $\mathsf{Sign}$ algorithm is defined in BIP 340 and $a$ denotes the auxiliary data used in BIP 340 [#bip-0340]_.
+where the $\mathsf{Sign}$ algorithm is defined in BIP 340 [#bip-0340]_.
 Note that $\mathsf{IssueAuthSig.Sign}$ could return $\bot$ with very low probability.
-Note that the initial $\mathtt{0x00}$ byte in the signature is a version byte, enabling future ZIPs to
-specify alternative issuance authorization signature schemes.
-
 
 Define $\mathsf{IssueAuthSig.Validate} \;{\small ⦂}\; (\mathsf{ik} \;{\small ⦂}\; \mathsf{IssueAuthSig.Public}) \times (M \;{\small ⦂}\; \mathsf{IssueAuthSig.Message}) \times (\text{σ} \;{\small ⦂}\; \mathsf{IssueAuthSig.Signature}) \to \mathbb{B}$ as:
 
 * Return $0$ if $\text{σ} = \bot$.
-* Parse $\text{σ}$ as $\mathtt{0x00} || \mathsf{sig}$ and parse $\mathsf{ik}$ as $\mathtt{0x00} || \mathsf{key}$. Return $0$ if the parsing fails.
-* Return $1$ if $\mathsf{Verify}(\mathsf{key}, M, \mathsf{sig})$ succeeds, otherwise $0$.
+* Return $1$ if $\mathsf{Verify}(\mathsf{key}, M, \text{σ})$ succeeds, otherwise $0$.
 
 where the $\mathsf{Verify}$ algorithm is defined in BIP 340 [#bip-0340]_.
 
+The $\mathtt{issueAuthSig}$ field of an issuance bundle encodes the signature with an initial byte indicating the signature scheme, which MUST be $\mathtt{0x00}$ indicating BIP 340.
+That is, $\mathtt{issueAuthSig} = \mathtt{0x00} \,||\, \text{σ}$. This enables future ZIPs to specify alternative signature schemes.
+
+
 Specification: Asset Identifier, Asset Digest, and Asset Base
 =============================================================
 
@@ -208,8 +226,8 @@ For context, the relations between the Asset Identifier, Asset Digest, and Asset
 **Note:** To keep notations light and concise, we may omit $\mathsf{AssetId}$ in the subscript when the Asset Identifier is clear from the context.
 
 
-Asset Identifiers
------------------
+Asset Identifier
+----------------
 
 Every Asset has a globally-unique Asset Identifier, denoted $\mathsf{AssetId}$. A given
 Asset Identifier is used across all Zcash protocols that support ZSAs -- that is, the
@@ -218,7 +236,7 @@ OrchardZSA protocol and potentially future Zcash shielded protocols.
 ZIP 227 Asset Identifiers
 `````````````````````````
 
-Assets issued using the protocol specified in this ZIP are scoped to the $\mathsf{ik}$
+Assets issued using the protocol specified in this ZIP are scoped to the $\mathsf{issuer}$
 that issued them. Within that scope, Asset Identifier uniqueness is obtained by way of an
 asset description, $\mathsf{asset\_desc}$, which includes any information pertaining to
 the issuance. $\mathsf{asset\_desc}$ is a non-empty byte sequence which SHOULD be a
@@ -230,19 +248,18 @@ Define
 
 We define Asset Identifiers for Assets issued under this ZIP as
 
-.. math:: \mathsf{AssetId} := (\mathsf{ik}, \mathsf{assetDescHash})
+.. math:: \mathsf{AssetId} := (\mathsf{issuer}, \mathsf{assetDescHash})
 
 and define their canonical encoding as
 
-.. math:: \mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}((\mathsf{ik}, \mathsf{assetDescHash})) := \mathtt{0x00} || \mathsf{ik} || \mathsf{assetDescHash}
+.. math:: \mathsf{EncodeAssetId}(\mathsf{AssetId}) = \mathsf{EncodeAssetId}((\mathsf{issuer}, \mathsf{assetDescHash})) := \mathtt{0x00} \,||\, \mathsf{issuer}\,||\,\mathsf{assetDescHash}
 
-Note that the initial $\mathtt{0x00}$ byte is a version byte, enabling future ZIPs to
-specify alternative issuance protocols and Asset Identifiers.
+Note that the initial $\mathtt{0x00}$ byte is a version byte, enabling future ZIPs to specify alternative issuance protocols and Asset Identifiers. (This should not be confused with the first byte of $\mathsf{issuer}$, currently equal to the first byte of $\mathsf{ik\_encoding}$, that indicates the issuance signature scheme.)
 
 Wallets MUST NOT display just the $\mathsf{asset\_desc}$ string to their users as the name of the Asset. Some possible alternatives include:
 
-- Wallets could allow clients to provide an additional configuration file that stores a one-to-one mapping of names to Asset Identifiers via a petname system. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients.
-- The Asset Digest could be used as a more compact bytestring to uniquely determine an Asset, and wallets could support clients scanning QR codes to load Asset information into their wallets.
+- Wallets could allow clients to provide an additional configuration file that stores a one-to-one mapping of names to Asset Identifiers via a petname system [#petnames]_. This allows clients to rename the Assets in a way they find useful. Default versions of this file with well-known Assets listed can be made available online as a starting point for clients.
+- The Asset Digest could be used as a more compact byte sequence to uniquely determine an Asset, and wallets could support clients scanning QR codes to load Asset information into their wallets.
 
 Asset Digests
 -------------
@@ -278,7 +295,7 @@ where $\mathsf{GroupHash}^\mathbb{P}$ is defined as in [#protocol-concretegrouph
     :align: center
     :figclass: align-center
 
-    Diagram relating the Issuance validating key, asset description, asset description hash, Asset Identifier, Asset Digest, and Asset Base for the OrchardZSA Protocol.
+    Diagram relating the Issuer identifier, asset description, asset description hash, Asset Identifier, Asset Digest, and Asset Base for the OrchardZSA Protocol.
 
 
 Specification: Issue Note, Issuance Action, Issuance Bundle and Issuance Protocol
@@ -287,19 +304,19 @@ Specification: Issue Note, Issuance Action, Issuance Bundle and Issuance Protoco
 Issue Note
 ----------
 
-Let $\ell_{\mathsf{value}}$ be as defined in §5.3 of the protocol specification [#protocol-constants]_.
+Let $\ell_{\mathsf{value}}$ be as defined in §5.3 ‘Constants’ [#protocol-constants]_.
 An Issue Note represents that a value $\mathsf{v} : \{0 .. 2^{\ell_{\mathsf{value}}} - 1\}$ of a specific Custom Asset is issued to a recipient.
 An Issue Note is a tuple $(\mathsf{d}, \mathsf{pk_d}, \mathsf{v}, \mathsf{AssetBase}, \text{ρ}, \mathsf{rseed})$, where:
 
-- $\mathsf{d}: \mathbb{B}^{[\ell_{\mathsf{d}}]}$ is the diversifier of the recipient's shielded payment address, as in §3.2 of the protocol specification [#protocol-notes]_.
-- $\mathsf{pk_d}: \mathsf{KA}^{\mathsf{Orchard}}.\mathsf{Public}$ is the recipient's diversified transmission key, as in §3.2 of the protocol specification [#protocol-notes]_.
+- $\mathsf{d}: \mathbb{B}^{[\ell_{\mathsf{d}}]}$ is the diversifier of the recipient's shielded payment address, as in §3.2 ‘Notes’ [#protocol-notes]_.
+- $\mathsf{pk_d}: \mathsf{KA}^{\mathsf{Orchard}}.\mathsf{Public}$ is the recipient's diversified transmission key, as in §3.2 ‘Notes’ [#protocol-notes]_.
 - $\mathsf{v} : \{0 .. 2^{\ell_{\mathsf{value}}} - 1\}$ is the value of the note in terms of the number of Asset tokens.
 - $\mathsf{AssetBase}: \mathbb{P}^*$ is the Asset Base corresponding to the ZSA being issued in the Issue Note.
 - $\text{ρ}: \mathbb{F}_{q_{\mathbb{P}}}$ is used to derive the nullifier of the note, and is computed as in `Computation of ρ`_.
 - $\mathsf{rseed}: \mathbb{B}^{[\mathbb{Y}^{32}]}$ MUST be sampled uniformly at random by the issuer.
 
 ZIP 230 [#zip-0230-issue-note]_ defines, in ``IssueNote``, field encodings which together with
-$\mathsf{ik}$ from the parent `Issuance Bundle`_ and $\mathsf{AssetDescHash}$ from the parent
+$\mathsf{issuer}$ from the parent `Issuance Bundle`_ and $\mathsf{AssetDescHash}$ from the parent
 `Issuance Action`_, specify an Issue Note.
 
 Let $\mathsf{Note^{Issue}}$ be the type of an Issue Note, i.e.
@@ -333,9 +350,9 @@ An issuance bundle is the aggregate of all the issuance-related information.
 Specifically, contains all the issuance actions and the issuer signature on the transaction SIGHASH that validates the issuance itself.
 It contains the following fields:
 
-- $\mathsf{ik}$: the issuance validating key, that allows the validators to verify that the $\mathsf{AssetId}$ is properly associated with the issuer.
+- ``issuer``: the issuer identifier, that allows the validators to verify that the $\mathsf{AssetId}$ is properly associated with the issuer.
 - ``vIssueActions``: an array of issuance actions, of type ``IssueAction``.
-- $\mathsf{issueAuthSig}$: the signature of the transaction SIGHASH, signed by the issuance authorizing key, $\mathsf{isk}$, that validates the issuance.
+- ``issueAuthSig``: the encoding of a signature of the transaction SIGHASH, signed by the issuance authorizing key, $\mathsf{isk}$, that validates the issuance.
 
 The issuance bundle is added within the transaction format as a new bundle. 
 The detailed encoding of the issuance bundle as a part of the V6 transaction format is defined in ZIP 230 [#zip-0230-transaction-format]_.
@@ -345,9 +362,9 @@ Computation of ρ
 
 We define a function $\mathsf{DeriveIssuedRho} : \mathbb{F}_{q_{\mathbb{P}}} \times \{0 .. 2^{32} - 1\} \times \{0 .. 2^{32} - 1\} \to \mathbb{F}_{q_{\mathbb{P}}}$ for Issue Notes in the OrchardZSA Protocol as follows:
 
-.. math:: \mathsf{DeriveIssuedRho}(\mathsf{nf}, \mathsf{i_{A}}, \mathsf{i_{N}}) := \mathsf{ToBase}^{\mathsf{Orchard}}(\mathsf{PRF}^{\mathsf{expand}}(\mathsf{I2LEOSP}_{256}(\mathsf{nf}), [\mathtt{0x84}] \| \mathsf{I2LEOSP}_{32}(\mathsf{i_{A}}) \| \mathsf{I2LEOSP}_{32}(\mathsf{i_{N}}))),
+.. math:: \mathsf{DeriveIssuedRho}(\mathsf{nf}, \mathsf{i_{A}}, \mathsf{i_{N}}) := \mathsf{ToBase}^{\mathsf{Orchard}}\big(\mathsf{PRF}^{\mathsf{expand}}\big(\mathsf{I2LEOSP}_{256}(\mathsf{nf}), [\mathtt{0x84}] \,||\, \mathsf{I2LEOSP}_{32}(\mathsf{i_{A}}) \,||\, \mathsf{I2LEOSP}_{32}(\mathsf{i_{N}})\big)\big),
 
-where $\mathsf{ToBase}^{\mathsf{Orchard}}$ is defined in §4.2.3 of the protocol specification [#protocol-orchardkeycomponents]_, and $\mathsf{PRF}^{\mathsf{expand}}$ is defined in §5.4.2 of the protocol specification [#protocol-concreteprfs]_.
+where $\mathsf{ToBase}^{\mathsf{Orchard}}$ is defined in §4.2.3 ‘Orchard Key Components’ [#protocol-orchardkeycomponents]_, and $\mathsf{PRF}^{\mathsf{expand}}$ is defined in §5.4.2 ‘Pseudo Random Functions’ [#protocol-concreteprfs]_.
 
 The $\text{ρ}$ field of an Issue Note is computed as 
 
@@ -356,7 +373,7 @@ The $\text{ρ}$ field of an Issue Note is computed as
 where $\mathsf{nf}_{0,0}$ is the nullifier for the input note in the first Action in the first Action Group of the OrchardZSA Bundle of the transaction, $\mathsf{index_{Action}}$ is the zero-based index of the Issuance Action in the Issuance Bundle, and $\mathsf{index_{Note}}$ is the zero-based index of the Issue Note in the Issuance Action.
 
 **NOTE:** This implicitly requires that there always is an Action Group in the OrchardZSA bundle of the transaction.
-This is enforced by the sixth consensus rule in the `Specification: Consensus Rule Changes`_ section.
+This is enforced by a consensus rule in the `Specification: Consensus Rule Changes`_ section.
 
 Issuance Protocol
 -----------------
@@ -366,7 +383,7 @@ For all actions ``IssueAction``:
 
 - encode $\mathsf{asset\_desc}$ as a UTF-8 byte string.
 - compute $\mathsf{assetDescHash}$
-- compute $\mathsf{AssetDigest}$ from the issuance validating key $\mathsf{ik}$ and $\mathsf{assetDescHash}$ as decribed in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section.
+- compute $\mathsf{AssetDigest}$ from the issuer identifier $\mathsf{issuer}$ and $\mathsf{assetDescHash}$ as decribed in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section.
 - compute $\mathsf{AssetBase}$ from $\mathsf{AssetDigest}$ as decribed in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section.
 - set the $\mathsf{finalize}$ boolean as desired (if more issuance actions are to be created for this $\mathsf{AssetBase}$, set $\mathsf{finalize} = 0$, otherwise set $\mathsf{finalize} = 1$).
 - for each recipient $i$:
@@ -376,10 +393,10 @@ For all actions ``IssueAction``:
 
 - encode the ``IssueAction`` into the vector ``vIssueActions`` of the bundle.
 
-For the ``IssueBundle``:
+For the ``IssueBundle`` (see “ZSA Issuance Bundle Fields” in [#zip-0230-transaction-format]_):
 
 - encode the ``vIssueActions`` vector.
-- encode the $\mathsf{ik}$ as 32 byte-string.
+- fill the ``issuerLength`` and ``issuer`` fields using $\mathsf{issuer}$.
 - sign the SIGHASH transaction hash with the issuance authorizing key, $\mathsf{isk}$, using the $\mathsf{IssueAuthSig}$ signature scheme. The signature is then added to the issuance bundle.
 
 
@@ -393,7 +410,7 @@ Reference Notes
 
 A reference note for a Custom Asset MUST be included by the issuer as the first Note in the Action of the Issuance Bundle where that Custom Asset is being issued for the first time.
 
-A reference note for a Custom Asset is an Issue Note where the value $\mathsf{v}$ is set to $0$, the Asset Base ($\mathsf{AssetBase}$) corresponds to that of the Custom Asset, and the recipient address $(\mathsf{d}, \mathsf{pk}_{\mathsf{d}})$ is set to the default diversified payment address (i.e. the diversified payment address with diversifier index $0$) derived from the all-zero Orchard spending key using the algorithm specified in §4.2.3 of the protocol specification [#protocol-orchardkeycomponents]_. This corresponds to a 43 byte ``u8`` array with the following entries::
+A reference note for a Custom Asset is an Issue Note where the value $\mathsf{v}$ is set to $0$, the Asset Base ($\mathsf{AssetBase}$) corresponds to that of the Custom Asset, and the recipient address $(\mathsf{d}, \mathsf{pk}_{\mathsf{d}})$ is set to the default diversified payment address (i.e. the diversified payment address with diversifier index $0$) derived from the all-zero Orchard spending key using the algorithm specified in §4.2.3 ‘Orchard Key Components’ [#protocol-orchardkeycomponents]_. This corresponds to a 43-byte ``u8`` array with the following entries::
 
   [
     204, 54, 96, 25, 89, 33, 59, 107, 12, 219, 150, 167, 92, 23, 195, 166, 104, 169, 127, 13, 106,
@@ -405,7 +422,8 @@ A reference note for a Custom Asset is an Issue Note where the value $\mathsf{v}
 Global Issuance State
 ---------------------
 
-The maximum total supply of any issued Custom Asset is denoted by the constant $\mathsf{MAX\_ISSUE} := 2^{64} - 1$. 
+The maximum total supply of any issued Custom Asset is denoted by the constant $\mathsf{MAX\_ISSUE} := 2^{64} - 1$.
+
 Issuance requires the following additions to the global state:
 
 A map, $\mathsf{issued\_assets} : \mathbb{P}^* \to \{0 .. \mathsf{MAX\_ISSUE}\} \times \mathbb{B} \times \mathsf{Note^{Issue}}$, from the Asset Base, $\mathsf{AssetBase} : \mathbb{P}^*$, to a tuple $(\mathsf{balance}, \mathsf{final}, \mathsf{note_{ref}})$, for every Asset that has been issued.
@@ -418,8 +436,6 @@ For any Asset represented by $\mathsf{AssetBase}$:
 - $\mathsf{issued\_assets}(\mathsf{AssetBase}).\mathsf{final} : \mathbb{B}$ is a Boolean that stores the finalization status of the Asset (i.e.: whether the $\mathsf{finalize}$ flag has been set to $1$ in any preceding issuance transaction for the Asset). The value of $\mathsf{issued\_assets}(\mathsf{AssetBase}).\mathsf{final}$ for any $\mathsf{AssetBase}$ cannot be changed from $1$ to $0$.
 - $\mathsf{issued\_assets}(\mathsf{AssetBase}).\mathsf{note_{ref}} : \mathsf{Note^{Issue}}$ stores the reference note for the Asset, as defined in the `Reference Notes`_ section.
 
-The maximum total supply of any issued Custom Asset is denoted by the constant $\mathsf{MAX\_ISSUE} := 2^{64} - 1$. 
-
 
 Management of the Global Issuance State
 ---------------------------------------
@@ -439,30 +455,35 @@ We use $\mathsf{issued\_assets}_{\mathsf{IN}}$ and $\mathsf{issued\_assets}_{\ma
 Specification: Consensus Rule Changes
 =====================================
 
+Let $\mathsf{SigHash}$ be the SIGHASH transaction hash of this transaction, as defined in §4.10 ‘SIGHASH Transaction Hashing’ [#protocol-sighash]_ with the modifications described in ZIP 226 [#zip-0226-txiddigest]_, using $\mathsf{SIGHASH\_ALL}$.
+
 For every transaction:
 
 - The ``nActionGroupsOrchard`` field MUST have a value of either ``0`` or ``1`` and the ``nAGExpiryHeight`` field MUST have a value of ``0``.
 - The output issuance state of the transaction MUST be initialized to be the same as the input issuance state, $\mathsf{issued\_assets}_{\mathsf{OUT}} = \mathsf{issued\_assets}_{\mathsf{IN}}$.
 - The $\mathsf{assetBurn}$ set MUST satisfy the consensus rules specified in ZIP 226 [#zip-0226-assetburn]_.
 - It MUST be the case that for all $(\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{assetBurn}$, $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{balance} \geq \mathsf{v}$. The node then MUST update $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase})$ prior to processing the issuance bundle in the following manner. For every $(\mathsf{AssetBase}, \mathsf{v}) \in \mathsf{AssetBurn}$, $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{balance} = \mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{balance} - \mathsf{v}$.
-- Let $\mathsf{SigHash}$ be the SIGHASH transaction hash of this transaction, as defined in §4.10 of the protocol specification [#protocol-sighash]_ with the modifications described in ZIP 226 [#zip-0226-txiddigest]_, using $\mathsf{SIGHASH\_ALL}$.
-- If the transaction contains an Issuance Bundle, it MUST also contain at least one OrchardZSA Action Group.
-- The issuance authorization signature, $\mathsf{issueAuthSig}$, MUST be a valid $\mathsf{IssueAuthSig}$ signature over $\mathsf{SigHash}$, i.e. $\mathsf{IssueAuthSig}.\!\mathsf{Validate}(\mathsf{ik}, \mathsf{SigHash}, \mathsf{issueAuthSig}) = 1$. 
+
+If the transaction contains an issuance bundle:
+
+- It MUST also contain at least one OrchardZSA Action Group.
+- The encoding $\mathsf{ik\_encoding}$ of the issuance key $\mathsf{ik}$ used to validate the issuance authorization signature MUST be taken from the ``issuer`` field, and MUST start with the byte value $\mathtt{0x00}$ indicating a BIP 340 public key.
+- The issuance authorization signature, $\mathsf{issueAuthSig}$, MUST be a valid $\mathsf{IssueAuthSig}$ signature over $\mathsf{SigHash}$, i.e. $\mathsf{IssueAuthSig}.\!\mathsf{Validate}(\mathsf{ik}, \mathsf{SigHash}, \mathsf{issueAuthSig}) = 1$.
 - For every issuance action description ($\mathsf{IssueAction}_\mathsf{i},\ 1 \leq i \leq \mathtt{nIssueActions}$) in the issuance bundle:
 
   - Every Issue Note in ``IssueAction`` MUST be a valid encoding of the $\mathsf{Note^{Issue}}$ type, and MUST encode the same $\mathsf{AssetBase}$. 
-  - This $\mathsf{AssetBase}$ MUST satisfy the derivation from the issuance validating key and asset description described in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section.
+  - This $\mathsf{AssetBase}$ MUST satisfy the derivation from the issuer identifier and asset description described in the `Specification: Asset Identifier, Asset Digest, and Asset Base`_ section.
   - It MUST be the case that $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{final} \neq 1$.
-  - If $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{note_{ref}} = \bot$, then let $\mathsf{note}_1$ be the first Issue Note in the Issuance Action.
+  - If $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{note_{ref}} = \bot$, then let $\mathsf{new\_note_{ref}}$ be the first Issue Note in the Issuance Action.
 
-      - The recipient address $(\mathsf{d}, \mathsf{pk}_{\mathsf{d}})$ of $\mathsf{note}_1$ MUST be the default diversified payment address derived from the all-zero Orchard spending key, as described in the `Reference Notes`_ section.
-      - The value $\mathsf{v}_0$ of $\mathsf{note}_1$ MUST be $0$.
-      - The node MUST update $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{note_{ref}} = \mathsf{note}_1$.
+      - The recipient address $(\mathsf{d}, \mathsf{pk}_{\mathsf{d}})$ of $\mathsf{new\_note_{ref}}$ MUST be the default diversified payment address derived from the all-zero Orchard spending key, as described in the `Reference Notes`_ section.
+      - The value of $\mathsf{new\_note_{ref}}$ MUST be $0$.
+      - The node MUST update $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{note_{ref}} = \mathsf{new\_note_{ref}}$.
 
-  - For every issue note description ($\mathsf{note}_{\mathsf{j}},\ 1 \leq j \leq \mathtt{nNotes}$) in ``IssueAction``:
+  - For every issue note description, $\mathsf{note}_j$ for $1 \leq j \leq \mathtt{nNotes}$ in ``IssueAction``:
 
     - The $\text{ρ}$ field of the issue note MUST have been computed as described in the `Computation of ρ`_ section.
-    - It MUST be the case that $\mathsf{issued\_assets}_{\mathsf{OUT}}.\mathsf{balance} + \mathsf{v} \leq \mathsf{MAX\_ISSUE}$, where $\mathsf{v}$ is the value of $\mathsf{note}_{\mathsf{j}}$. The node then MUST update $\mathsf{issued\_assets}_{\mathsf{OUT}}.\mathsf{balance} = \mathsf{issued\_assets}_{\mathsf{OUT}}.\mathsf{balance} + \mathsf{v}$.
+    - It MUST be the case that $\mathsf{issued\_assets}_{\mathsf{OUT}}.\mathsf{balance} + \mathsf{v}_j \leq \mathsf{MAX\_ISSUE}$, where $\mathsf{v}_j$ is the value of $\mathsf{note}_j$. The node then MUST update $\mathsf{issued\_assets}_{\mathsf{OUT}}.\mathsf{balance} = \mathsf{issued\_assets}_{\mathsf{OUT}}.\mathsf{balance} + \mathsf{v}_j$.
     - The node MUST compute the note commitment, $\mathsf{cm}_{\mathsf{i,j}}$, as defined in the Note Structure and Commitment section of ZIP 226 [#zip-0226-notestructure]_.
   - If $\mathsf{finalize} = 1$ within the ``flagsIssuance`` field of ``IssueAction``, the node MUST set $\mathsf{issued\_assets}_{\mathsf{OUT}}(\mathsf{AssetBase}).\mathsf{final} = 1$.
 
@@ -485,7 +506,7 @@ Rationale
 The following is a list of rationale for different decisions made in the proposal:
 
 - The issuance key structure is independent of the original key tree, but derived in an analogous manner (via ZIP 32). This keeps the issuance details and the Asset Identifiers consistent across multiple shielded pools. It also separates the issuance authority from the spend authority, allowing for the potential transfer of issuance authority without compromising the spend authority.
-- The Custom Asset is described via a combination of the issuance validating key and an asset description string, to preclude the possibility of two different issuers creating colliding Custom Assets.
+- The Custom Asset is described via a combination of the issuer identifier and an asset description string, to preclude the possibility of two different issuers creating colliding Custom Assets.
 - The requirement of at least one OrchardZSA Action Group in the presence of an issue bundle is both to allow for the computation of the $\text{ρ}$ field of the issue notes, as well as to prevent replay attacks. 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.
 
 Hash of the asset description
@@ -507,7 +528,7 @@ asset description, for the following reasons:
   rules had required it to be a Unicode string instead of only recommending it).
 
 - The lack of key rotation in this issuance protocol means that it is not sufficient to
-  mark an $\mathsf{ik}$ as trusted and then accept whatever asset descriptions are issued
+  mark an $\mathsf{issuer}$ as trusted and then accept whatever asset descriptions are issued
   by it. Each Asset Identifier needs to be independently verified, which requires some
   out-of-band protocol that can also convey the corresponding asset description.
 
@@ -605,7 +626,7 @@ Issuance Key Compromise
 
 The design of this protocol does not currently allow for rotation of the issuance validating key that would allow for replacing the key of a specific Asset. In case of compromise, the following actions are recommended:
 
-- If an issuance validating key is compromised, the $\mathsf{finalize}$ boolean for all the Assets issued with that key should be set to $1$ and the issuer should change to a new issuance authorizing key, and issue new Assets, each with a new $\mathsf{AssetId}$.
+- If an issuer identifier is compromised, the $\mathsf{finalize}$ boolean for all the Assets issued with that key should be set to $1$; then the issuer should change to a new issuance authorizing key (hence a new issuer identifier), and issue new Assets, each with a new $\mathsf{AssetId}$.
 
 Bridging Assets
 ---------------
@@ -664,8 +685,8 @@ References
 .. [#zip-0317-fee-calculation] `ZIP 317: Proportional Transfer Fee Mechanism - Fee calculation <zip-0317.html#fee-calculation>`_
 .. [#bip-0043] `BIP 43: Purpose Field for Deterministic Wallets <https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki>`_
 .. [#bip-0340] `BIP 340: Schnorr Signatures for secp256k1 <https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki>`_
+.. [#protocol] `Zcash Protocol Specification, Version 2024.5.1 [NU6] or later. <protocol/protocol.pdf>`_
 .. [#protocol-notation] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 2: Notation <protocol/protocol.pdf#notation>`_
-.. [#protocol-addressesandkeys] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.1: Payment Addresses and Keys <protocol/protocol.pdf#addressesandkeys>`_
 .. [#protocol-notes] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 3.2: Notes <protocol/protocol.pdf#notes>`_
 .. [#protocol-abstractsig] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.1.7: Signature <protocol/protocol.pdf#abstractsig>`_
 .. [#protocol-orchardkeycomponents] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.2.3: Orchard Key Components <protocol/protocol.pdf#orchardkeycomponents>`_
@@ -675,3 +696,4 @@ References
 .. [#protocol-concretegrouphashpallasandvesta] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.4.9.8: Group Hash into Pallas and Vesta <protocol/protocol.pdf#concretegrouphashpallasandvesta>`_
 .. [#protocol-orchardpaymentaddrencoding] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 5.6.4.2: Orchard Raw Payment Addresses <protocol/protocol.pdf#orchardpaymentaddrencoding>`_
 .. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
+.. [#petnames] `An Introduction to Petname Systems. Marc Stiegler, updated June 2010. <HTTP://www.skyhunter.com/marcs/petnames/IntroPetNames.html>`_
diff --git a/zips/zip-0230.rst b/zips/zip-0230.rst
index a0917276c..e3a946132 100644
--- a/zips/zip-0230.rst
+++ b/zips/zip-0230.rst
@@ -120,13 +120,12 @@ Transaction Format
 | varies                      |``nSpendsSapling``            |``compactSize``                                 |Number of Sapling Spend descriptions in ``vSpendsSapling``.          |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | 96 × ``nSpendsSapling``     |``vSpendsSapling``            |``SpendDescriptionV5[nSpendsSapling]``          |A sequence of Sapling Spend descriptions, encoded per                |
-|                             |                              |                                                |protocol §7.3 ‘Spend Description Encoding and Consensus’             |
-|                             |                              |                                                |(unchanged from V5).                                                 |
+|                             |                              |                                                |§7.3 ‘Spend Description Encoding and Consensus’ (unchanged from V5). |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | varies                      |``nOutputsSapling``           |``compactSize``                                 |Number of Sapling Output Decriptions in ``vOutputsSapling``.         |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | 276 × ``nOutputsSapling``   |``vOutputsSapling``           |``OutputDescriptionV6[nOutputsSapling]``        |A sequence of Sapling Output descriptions, encoded per               |
-|                             |                              |                                                |protocol §7.4 ‘Output Description Encoding and Consensus’.           |
+|                             |                              |                                                |§7.4 ‘Output Description Encoding and Consensus’.                    |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | 8                           |``valueBalanceSapling``       |``int64``                                       |The net value of Sapling Spends minus Outputs                        |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
@@ -152,21 +151,22 @@ Transaction Format
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | 64                          |``bindingSigOrchard``         |``byte[64]``                                    |An OrchardZSA binding signature on the SIGHASH transaction hash.     |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
-| **ZSA Issuance Fields**                                                                                                                                                           |
+| **ZSA Issuance Bundle Fields**                                                                                                                                                    |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | varies                      |``nIssueActions``             |``compactSize``                                 |The number of issuance actions in the bundle.                        |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | varies                      |``vIssueActions``             |``IssueAction[nIssueActions]``                  |A sequence of issuance action descriptions.                          |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
-| varies                      |``ikLength``                  |``compactSize``                                 |The length of the issuance validating key of the issuer.             |
+| varies                      |``issuerLength``              |``compactSize``                                 |The length of the issuer identifier.                                 |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
-| varies                      |``ik``                        |``byte[ikLength]``                              |The issuance validating key of the issuer, used to validate the      |
-|                             |                              |                                                |signature.                                                           |
+| varies                      |``issuer``                    |``byte[issuerLength]``                          |The issuer identifier as defined in [#zip-0227-issuer-identifier]_.  |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
-| varies                      |``issueAuthSigLength``        |``compactSize``                                 |The length of the issuance authorization signature.                  |
+| varies                      |``issueAuthSigLength``        |``compactSize``                                 |The length of the issuance authorization signature, including the    |
+|                             |                              |                                                |initial byte indicating a BIP 340 signature.                         |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | varies                      |``issueAuthSig``              |``byte[issueAuthSigLength]``                    |The signature of the transaction SIGHASH, signed by the issuer,      |
-|                             |                              |                                                |validated as in Issuance Authorization Signature Scheme [#zip-0227]_.|
+|                             |                              |                                                |preceded by a :math:`\mathtt{0x00}` byte indicating a BIP 340        |
+|                             |                              |                                                |signature. It is validated as specified in [#zip-0227-issuance-sig]_.|
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | **Memo Bundle Fields**                                                                                                                                                            |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
@@ -203,7 +203,7 @@ Transaction Format
   only if $\mathtt{nActionGroupsOrchard} > 0$. If ``valueBalanceOrchard`` is not present,
   then $\mathsf{v^{balanceOrchard}}$ is defined to be $0$.
 
-* The fields ``ikLength``, ``ik``, ``issueAuthSigLength``, and ``issueAuthSig`` are present if and only if $\mathtt{nIssueActions} > 0$.
+* The fields ``issuerLength``, ``issuer``, ``issueAuthSigLength``, and ``issueAuthSig`` are present if and only if $\mathtt{nIssueActions} > 0$.
 
 * For coinbase transactions, the ``enableSpendsOrchard`` and ``enableZSAs`` bits MUST be set to $0$.
 
@@ -254,8 +254,7 @@ Sapling Output Description (``OutputDescriptionV6``)
 |                             |                              |                                                |of the transmission key with the ephemeral secret key.               |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 
-The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding
-and Consensus’ of the Zcash Protocol Specification [#protocol-outputdesc]_.
+The encodings of each of these elements are defined in §7.4 ‘Output Description Encoding and Consensus’ [#protocol-outputdesc]_.
 
 OrchardZSA Action Group Description
 -----------------------------------
@@ -270,10 +269,10 @@ The OrchardZSA Action Group Description is encoded in a transaction as an instan
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | 372 × ``nActionsOrchard``   |``vActionsOrchard``           |``OrchardZSAAction[nActionsOrchard]``           |A sequence of OrchardZSA Action descriptions in the Action Group.    |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
-| 1                           |``flagsOrchard``              |``byte``                                        |As defined in Section 7.1 of the Protocol Specification              |
+| 1                           |``flagsOrchard``              |``byte``                                        |As defined in §7.1 ‘Transaction Encoding and Consensus’              |
 |                             |                              |                                                |[#protocol-txnencoding]_.                                            |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
-| 32                          |``anchorOrchard``             |``byte[32]``                                    |As defined in Section 7.1 of the Protocol Specification              |
+| 32                          |``anchorOrchard``             |``byte[32]``                                    |As defined in §7.1 ‘Transaction Encoding and Consensus’              |
 |                             |                              |                                                |[#protocol-txnencoding]_.                                            |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | 4                           |``nAGExpiryHeight``           |``uint32``                                      |A block height in the range {1 .. 499999999} after which any         |
@@ -283,9 +282,9 @@ The OrchardZSA Action Group Description is encoded in a transaction as an instan
 | varies                      | ``nAssetBurn``               | ``compactSize``                                |The number of Assets burnt.                                          |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | 40 × ``nAssetBurn``         | ``vAssetBurn``               | ``AssetBurn[nAssetBurn]``                      |A sequence of Asset Burn descriptions, encoded per                   |
-|                             |                              |                                                | encoded per `OrchardZSA Asset Burn Description`_.                   |
+|                             |                              |                                                |`OrchardZSA Asset Burn Description`_.                                |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
-| varies                      |``sizeProofsOrchard``         |``compactSize``                                 |As defined in Section 7.1 of the Protocol Specification              |
+| varies                      |``sizeProofsOrchard``         |``compactSize``                                 |As defined in §7.1 ‘Transaction Encoding and Consensus’              |
 |                             |                              |                                                |[#protocol-txnencoding]_.                                            |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | ``sizeProofsOrchard``       |``proofsOrchard``             |``byte[sizeProofsOrchard]``                     |The aggregated zk-SNARK proof for all Actions in the Action Group.   |
@@ -300,7 +299,7 @@ The encodings of ``OrchardZSAAction`` and ``AssetBurn`` are described below.
   ``vSpendAuthSigsOrchard``, each have a 1:1 correspondence to the elements of
   ``vActionsOrchard`` and MUST be ordered such that the proof or signature at a given
   index corresponds to the ``OrchardZSAAction`` at the same index.
-* If thee value of ``nAGExpiryHeight`` is nonzero, it MUST be consistent with
+* If the value of ``nAGExpiryHeight`` is nonzero, it MUST be consistent with
   the ``nExpiryHeight`` of the overall transaction. 
 * In NU7, ``nExpiryHeight`` MUST be set to ``0``; this restriction is expected
   to be lifted in a future network upgrade.
@@ -346,8 +345,7 @@ OrchardZSA Action Description (``OrchardZSAAction``)
 |                             |                              |                                                |of the transmission key with the ephemeral secret key.               |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 
-The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding
-and Consensus’ of the Zcash Protocol Specification [#protocol-actiondesc]_.
+The encodings of each of these elements are defined in §7.5 ‘Action Description Encoding and Consensus’ [#protocol-actiondesc]_.
 
 OrchardZSA Asset Burn Description
 ----------------------------------
@@ -404,16 +402,16 @@ An issuance note, ``IssueNote`` contains the following fields:
 |                             |                              |                                                |(\mathsf{pk}_\mathsf{d}))\!`, where :math:`\mathsf{d}` is the        |
 |                             |                              |                                                |diversifier and :math:`\mathsf{pk_d}` is the diversified             |
 |                             |                              |                                                |transmission key. **Non Normative Note**: This is the same as the    |
-|                             |                              |                                                |encoding of an Orchard Raw Payment Address, as defined in the        |
-|                             |                              |                                                |protocol specification §5.6.4.2 ‘Orchard Raw Payment Addresses’.     |
+|                             |                              |                                                |encoding of an Orchard Raw Payment Address, as defined in            |
+|                             |                              |                                                |§5.6.4.2 ‘Orchard Raw Payment Addresses’.                            |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | 8                           |``value``                     |``uint64``                                      |The amount being issued in this note.                                |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | 32                          |``rho``                       |``byte[32]``                                    |This is defined and encoded in the same manner as for Orchard notes  |
-|                             |                              |                                                |in protocol §3.2.1 'Note Plaintexts and Memo Fields'.                |
+|                             |                              |                                                |in §3.2.1 ‘Note Plaintexts and Memo Fields’.                         |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 | 32                          |``rseed``                     |``byte[32]``                                    |The ``rseed`` field of the note, encoded as for Orchard notes in     |
-|                             |                              |                                                |protocol §3.2.1 'Note Plaintexts and Memo Fields'.                   |
+|                             |                              |                                                |§3.2.1 ‘Note Plaintexts and Memo Fields’.                            |
 +-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
 
 
@@ -443,6 +441,8 @@ References
 .. [#zip-0225] `ZIP 225: Version 5 Transaction Format <zip-0225.html>`_
 .. [#zip-0226] `ZIP 226: Transfer and Burn of Zcash Shielded Assets <zip-0226.html>`_
 .. [#zip-0227] `ZIP 227: Issuance of Zcash Shielded Assets <zip-0227.html>`_
+.. [#zip-0227-issuer-identifier] `ZIP 227: Issuance of Zcash Shielded Assets — Issuer Identifier <zip-0227.html#issuer-identifier>`_
+.. [#zip-0227-issuance-sig] `ZIP 227: Issuance of Zcash Shielded Assets — Issuance Authorization Signature Scheme <zip-0227.html#issuance-authorization-signature-scheme>`_
 .. [#zip-0228] `ZIP 228: Asset Swaps for Zcash Shielded Assets <zip-0228.html>`_
 .. [#zip-0244] `ZIP 244: Transaction Identifier Non-Malleability <zip-0244.html>`_
 .. [#zip-0254] `ZIP 254: Deployment of the NU7 Network Upgrade <zip-0254.rst>`_
diff --git a/zips/zip-0246.rst b/zips/zip-0246.rst
index 46a04852d..88bb78ba0 100644
--- a/zips/zip-0246.rst
+++ b/zips/zip-0246.rst
@@ -342,7 +342,7 @@ T.5: issuance_digest
 A BLAKE2b-256 hash of the following values ::
 
    T.5a: issue_actions_digest    (32-byte hash output)
-   T.5b: issuanceValidatingKey   (field encoding bytes)
+   T.5b: issuerIdentifier        (field encoding bytes)
 
 The personalization field of this hash is set to::
 
@@ -468,7 +468,7 @@ Identical to that specified for the transaction identifier.
 
 S.5: issuance_digest
 ````````````````````
-Identical to the ``issuance_digest`` specified for the transaction identifier in ZIP 227 [zip-0227-txiddigest]_.
+Identical to the ``issuance_digest`` specified for the transaction identifier.
 
 S.6: memo_digest
 ````````````````
@@ -578,7 +578,6 @@ References
 .. [#protocol-actiondesc] `Zcash Protocol Specification, Version 2024.5.1 [NU6]. Section 4.6: Action Descriptions <protocol/protocol.pdf#actiondesc>`_
 .. [#protocol-txnencoding] `Zcash Protocol Specification, Version 2022.3.8. Section 7.1: Transaction Encoding and Consensus <protocol/protocol.pdf#txnencoding>`_
 .. [#zip-0200] `ZIP 200: Network Upgrade Mechanism <zip-0200.html>`_
-.. [#zip-0227-txiddigest] `ZIP 227: Issuance of Zcash Shielded Assets: TODO (issuance digest anchor missing) <zip-0227.html>`_
 .. [#zip-0230-transaction-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: Transaction Format <zip-0230.html#transaction-format>`_
 .. [#zip-0230-orchard-action-group-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: OrchardZSA Action Group Description  <zip-0230.html#orchardzsa-action-group-description>`_
 .. [#zip-0230-orchard-action-field-encodings] `ZIP 230: Version 6 Transaction Format. Specification: OrchardZSA Action Description <zip-0230.html#orchardzsa-action-description>`_