zcash · daira · Jan 11, 2026 · Jan 19, 2026 · Jan 19, 2026 · Jan 20, 2026
diff --git a/README.rst b/README.rst
@@ -182,6 +182,7 @@ written.
     <tr> <td><span class="reserved">240</span></td> <td class="left"><a class="reserved" href="zips/zip-0240.md">Standard Transaction Rules</a></td> <td>Reserved</td> <td class="left"><a href="https://github.com/zcash/zips/issues/648">zips#648</a></td>
     <tr> <td>245</td> <td class="left"><a href="zips/zip-0245.rst">Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions</a></td> <td>Draft</td> <td class="left"><a href="https://github.com/zcash/zips/issues/384">zips#384</a></td>
     <tr> <td>246</td> <td class="left"><a href="zips/zip-0246.rst">Digests for the Version 6 Transaction Format</a></td> <td>Draft</td> <td class="left"></td>
+    <tr> <td>248</td> <td class="left"><a href="zips/zip-0248.rst">Extensible Transaction Format</a></td> <td>Draft</td> <td class="left"><a href="https://github.com/zcash/zips/pull/1163">zips/pull/1163</a></td>
     <tr> <td><span class="reserved">260</span></td> <td class="left"><a class="reserved" href="zips/zip-0260.md">Extending Block Messages with Additional Authentication Data</a></td> <td>Reserved</td> <td class="left"><a href="https://github.com/zcash/zips/issues/522">zips#522</a></td>
     <tr> <td><span class="reserved">270</span></td> <td class="left"><a class="reserved" href="zips/zip-0270.md">Key Rotation for Tracked Signing Keys</a></td> <td>Reserved</td> <td class="left"><a href="https://github.com/zcash/zips/issues/1047">zips#1047</a></td>
     <tr> <td>302</td> <td class="left"><a href="zips/zip-0302.rst">Standardized Memo Field Format</a></td> <td>Draft</td> <td class="left"><a href="https://github.com/zcash/zips/issues/366">zips#366</a></td>
@@ -325,6 +326,7 @@ Index of ZIPs
     <tr> <td>244</td> <td class="left"><a href="zips/zip-0244.rst">Transaction Identifier Non-Malleability</a></td> <td>Final</td>
     <tr> <td>245</td> <td class="left"><a href="zips/zip-0245.rst">Transaction Identifier Digests & Signature Validation for Transparent Zcash Extensions</a></td> <td>Draft</td>
     <tr> <td>246</td> <td class="left"><a href="zips/zip-0246.rst">Digests for the Version 6 Transaction Format</a></td> <td>Draft</td>
+    <tr> <td>248</td> <td class="left"><a href="zips/zip-0248.rst">Extensible Transaction Format</a></td> <td>Draft</td>
     <tr> <td>250</td> <td class="left"><a href="zips/zip-0250.rst">Deployment of the Heartwood Network Upgrade</a></td> <td>Final</td>
     <tr> <td>251</td> <td class="left"><a href="zips/zip-0251.rst">Deployment of the Canopy Network Upgrade</a></td> <td>Final</td>
     <tr> <td>252</td> <td class="left"><a href="zips/zip-0252.rst">Deployment of the NU5 Network Upgrade</a></td> <td>Final</td>

diff --git a/zips/zip-0226.rst b/zips/zip-0226.rst
diff --git a/zips/zip-0227.rst b/zips/zip-0227.rst
diff --git a/zips/zip-0231.md b/zips/zip-0231.md
@@ -204,6 +204,154 @@ Since this proposal is defined only for v6 and later transactions, it is not
 necessary to consider Sprout JoinSplit outputs. The following sections apply
 to both Sapling and Orchard outputs in v6-onward transactions.
 
+## Changes to ZIP 248
+
+This ZIP proposes to register a new bundle type for Memos and new versions of
+the Sapling and Orchard bundle types in the V6 transaction bundle type registry
+defined in ZIP 248 [^zip-0248]:
+
+| BundleType | BundleVariant | `mValuePoolDeltas` | `mEffectBundles` | `mAuthBundles` | Bundle kind          |
+|------------|---------------|--------------------|------------------|----------------|----------------------|
+| TBD        | 0             |❌                  |✅                |❌              | Memos                |
+| 2          | TBD           |✅                  |✅                |✅              | Sapling-post-ZIP 231 |
+| 3          | TBD           |✅                  |✅                |✅              | Orchard-post-ZIP 231 |
+
+The Memos bundle has no value pool deltas (memo data does not involve value
+transfers) and no authorizing data. The effecting data consists of the encoded
+memo bundle as defined in [Encoding in transactions].
+
+The Sapling-post-ZIP 231 and Orchard-post-ZIP 231 entries are new variants of
+the existing Sapling (``bundleType`` 2) and Orchard (``bundleType`` 3) bundle
+types respectively. Because ZIP 248 requires that each bundle map is keyed by
+``bundleType`` alone, a transaction that includes a Sapling-post-ZIP 231 bundle
+cannot also include a pre-ZIP 231 Sapling bundle, and similarly for Orchard.
+
+If this ZIP is activated in the same network upgrade as ZIP 248, the encoding
+of the Sapling and Orchard bundles described in this ZIP will be used for
+bundle type 2 variant 0 and bundle type 3 variant 0, respectively, and
+ZIP 248's definition of the Sapling and Orchard bundles must be updated
+accordingly. If this ZIP is activated in a network upgrade AFTER the network
+upgrade in which ZIP 248 is activated, the encodings it describes will be
+assigned distinct bundle variant identifiers for their respective bundle types.
+
+## Sapling-post-ZIP 231 Bundle
+
+The Sapling-post-ZIP 231 bundle replaces the Sapling bundle defined in
+ZIP 248 [^zip-0248]. The only change is that the note plaintext in each
+Sapling output is shortened: the 512-byte memo field is replaced by a
+32-byte $\mathsf{K^{memo}}$, reducing `encCiphertext` from 580 bytes to
+100 bytes.
+
+### Sapling-post-ZIP 231 Effecting Data
+
+The effecting data for the Sapling-post-ZIP 231 bundle describes the Sapling
+spends and outputs.
+
+| Bytes                    | Name               | Data Type                                   | Description                                                                  |
+|--------------------------|--------------------|---------------------------------------------|------------------------------------------------------------------------------|
+| varies                   | `nSpendsSapling`   | `compactSize`                               | Number of Sapling Spend descriptions.                                        |
+| 96 \* nSpendsSapling     | `vSpendsSapling`   | `SaplingSpendEffecting[nSpendsSapling]`     | Effecting data for each Sapling Spend.                                       |
+| varies                   | `nOutputsSapling`  | `compactSize`                               | Number of Sapling Output descriptions.                                       |
+| 276 \* nOutputsSapling   | `vOutputsSapling`  | `SaplingOutputPostZIP231[nOutputsSapling]`  | Sapling Output descriptions.                                                 |
+| 32                       | `anchorSapling`    | `byte[32]`                                  | A root of the Sapling note commitment tree at some block height in the past. |
+
+* The field `anchorSapling` is present if and only if $\mathtt{nSpendsSapling} > 0$.
+
+`SaplingSpendEffecting` is unchanged from ZIP 248 [^zip-0248].
+
+#### SaplingOutputPostZIP231
+
+| Bytes | Name            | Data Type   | Description                                                                                                               |
+|-------|-----------------|-------------|---------------------------------------------------------------------------------------------------------------------------|
+| 32    | `cv`            | `byte[32]`  | A value commitment to the net value of the output note.                                                                   |
+| 32    | `cmu`           | `byte[32]`  | The $u$-coordinate of the note commitment for the output note.                                                            |
+| 32    | `ephemeralKey`  | `byte[32]`  | An encoding of an ephemeral Jubjub public key.                                                                            |
+| 100   | `encCiphertext` | `byte[100]` | The encrypted contents of the note plaintext, which contains $\mathsf{K^{memo}}$ in place of the 512-byte memo field.     |
+| 80    | `outCiphertext` | `byte[80]`  | The encrypted contents of the byte string created by concatenation of the transmission key with the ephemeral secret key. |
+
+### Sapling-post-ZIP 231 Authorizing Data
+
+The authorizing data is unchanged from the Sapling bundle defined in
+ZIP 248 [^zip-0248].
+
+| Bytes                    | Name                     | Data Type                         | Description                                                  |
+|--------------------------|--------------------------|-----------------------------------|--------------------------------------------------------------|
+| 192 \* nSpendsSapling    | `vSpendProofsSapling`    | `byte[192 * nSpendsSapling]`      | Encodings of the zk-SNARK proofs for each Sapling Spend.     |
+| 64 \* nSpendsSapling     | `vSpendAuthSigsSapling`  | `byte[64 * nSpendsSapling]`       | Authorizing signatures for each Sapling Spend.               |
+| 192 \* nOutputsSapling   | `vOutputProofsSapling`   | `byte[192 * nOutputsSapling]`     | Encodings of the zk-SNARK proofs for each Sapling Output.    |
+| 64                       | `bindingSigSapling`      | `byte[64]`                        | A Sapling binding signature on the SIGHASH transaction hash. |
+
+* The values of `nSpendsSapling` and `nOutputsSapling` are not re-encoded in
+  the authorizing data; they are taken from the corresponding effecting data.
+* The field `bindingSigSapling` is present if and only if
+  $\mathtt{nSpendsSapling} + \mathtt{nOutputsSapling} > 0$.
+* The elements of `vSpendProofsSapling` and `vSpendAuthSigsSapling` have a
+  1:1 correspondence to the elements of `vSpendsSapling` in the effecting data
+  and MUST be ordered such that the element at a given index corresponds to the
+  `SaplingSpendEffecting` at the same index.
+* The elements of `vOutputProofsSapling` have a 1:1 correspondence to the
+  elements of `vOutputsSapling` in the effecting data and MUST be ordered such
+  that the proof at a given index corresponds to the `SaplingOutputPostZIP231`
+  at the same index.
+
+## Orchard-post-ZIP 231 Bundle
+
+The Orchard-post-ZIP 231 bundle replaces the Orchard bundle defined in
+ZIP 248 [^zip-0248]. As with Sapling, the only change is that the note
+plaintext in each Orchard action is shortened: the 512-byte memo field is
+replaced by a 32-byte $\mathsf{K^{memo}}$, reducing `encCiphertext` from
+580 bytes to 100 bytes.
+
+### Orchard-post-ZIP 231 Effecting Data
+
+The effecting data for the Orchard-post-ZIP 231 bundle describes the Orchard
+actions.
+
+| Bytes                    | Name               | Data Type                                 | Description                                                                                                                                            |
+|--------------------------|--------------------|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|
+| varies                   | `nActionsOrchard`  | `compactSize`                             | The number of Orchard Action descriptions.                                                                                                             |
+| 340 \* nActionsOrchard   | `vActionsOrchard`  | `OrchardActionPostZIP231[nActionsOrchard]` | Effecting data for each Orchard Action.                                                                                                                |
+| 1                        | `flagsOrchard`     | `byte`                                    | An 8-bit value representing a set of flags. Ordered from LSB to MSB: `enableSpendsOrchard`, `enableOutputsOrchard`. The remaining bits are set to $0$. |
+| 32                       | `anchorOrchard`    | `byte[32]`                                | A root of the Orchard note commitment tree at some block height in the past.                                                                           |
+
+* The fields `flagsOrchard` and `anchorOrchard` are present if and only if
+  $\mathtt{nActionsOrchard} > 0$.
+* For coinbase transactions, the `enableSpendsOrchard` bit MUST be set to $0$.
+
+#### OrchardActionPostZIP231
+
+| Bytes | Name            | Data Type   | Description                                                                                                               |
+|-------|-----------------|-------------|---------------------------------------------------------------------------------------------------------------------------|
+| 32    | `cv`            | `byte[32]`  | A value commitment to the net value of the input note minus the output note.                                              |
+| 32    | `nullifier`     | `byte[32]`  | The nullifier of the input note.                                                                                          |
+| 32    | `rk`            | `byte[32]`  | The randomized validating key for this Action.                                                                            |
+| 32    | `cmx`           | `byte[32]`  | The $x$-coordinate of the note commitment for the output note.                                                            |
+| 32    | `ephemeralKey`  | `byte[32]`  | An encoding of an ephemeral Pallas public key.                                                                            |
+| 100   | `encCiphertext` | `byte[100]` | The encrypted contents of the note plaintext, which contains $\mathsf{K^{memo}}$ in place of the 512-byte memo field.     |
+| 80    | `outCiphertext` | `byte[80]`  | The encrypted contents of the byte string created by concatenation of the transmission key with the ephemeral secret key. |
+
+### Orchard-post-ZIP 231 Authorizing Data
+
+The authorizing data is unchanged from the Orchard bundle defined in
+ZIP 248 [^zip-0248].
+
+| Bytes                    | Name                     | Data Type                         | Description                                                                                |
+|--------------------------|--------------------------|-----------------------------------|--------------------------------------------------------------------------------------------|
+| varies                   | `sizeProofsOrchard`      | `compactSize`                     | Length in bytes of `proofsOrchard`. Value is $2720 + 2272 \cdot \mathtt{nActionsOrchard}$. |
+| sizeProofsOrchard        | `proofsOrchard`          | `byte[sizeProofsOrchard]`         | Encoding of aggregated zk-SNARK proofs for Orchard Actions.                                |
+| 64 \* nActionsOrchard    | `vSpendAuthSigsOrchard`  | `byte[64 * nActionsOrchard]`      | Authorizing signatures for each Orchard Action.                                            |
+| 64                       | `bindingSigOrchard`      | `byte[64]`                        | An Orchard binding signature on the SIGHASH transaction hash.                              |
+
+* The value of `nActionsOrchard` is not re-encoded in the authorizing data; it
+  is taken from the corresponding effecting data.
+* The fields `sizeProofsOrchard`, `proofsOrchard`, and `bindingSigOrchard` are
+  present if and only if $\mathtt{nActionsOrchard} > 0$.
+* The proofs aggregated in `proofsOrchard`, and the elements of
+  `vSpendAuthSigsOrchard`, each have a 1:1 correspondence to the elements of
+  `vActionsOrchard` in the effecting data and MUST be ordered such that the
+  proof or signature at a given index corresponds to the
+  `OrchardActionPostZIP231` at the same index.
+
 ## Memo bundle
 
 A memo bundle consists of a sequence of 272-byte memo chunks, each encrypting
@@ -386,6 +534,9 @@ transaction.
 
 ## Encoding in transactions
 
+The following describes the effecting data for the memo bundle. This data
+appears in `mEffectBundles` with the memo bundle type identifier.
+
 | Bytes    | Name                   | Data Type                                         | Description                                                            |
 |----------|------------------------|---------------------------------------------------|------------------------------------------------------------------------|
 |   1      | $\mathtt{fAllPruned}$  | $\mathtt{uint8}$                                  | 1 if the memo bundle has been pruned, otherwise 0.                     |
@@ -403,13 +554,21 @@ If $\mathtt{fAllPruned} = 0$, then:
 If $\mathtt{fAllPruned} = 1$, then:
 
 - $\mathtt{saltOrHash}$ contains the $\mathsf{memo\_bundle\_digest}$ as defined in
-  [Transaction sighash].
+  [Transaction Digest].
 - The $\mathtt{nMemoChunks}$ and $\mathtt{vMemoChunks}$ fields will be absent.
 
-## Transaction sighash
+## Transaction Digest
+
+The memo bundle contributes to the transaction identifier via the
+`effects_bundles_digest` defined in ZIP 248 [^zip-0248].
 
-$\mathsf{memo\_chunk\_digest}[i] = H(\mathtt{vMemoChunks}[i]) \\$
-$\mathsf{memo\_bundle\_digest} = H(\mathsf{concat}(\mathsf{memo\_chunk\_digests}))$
+The memo bundle's effect digest is computed as follows:
+
+$\mathsf{memo\_chunk\_digest}[i] = \mathsf{BLAKE2b\text{-}256}(\texttt{"ZTxIdMemoChunkHs"}, \mathtt{vMemoChunks}[i]) \\$
+$\mathsf{memo\_bundle\_digest} = \mathsf{BLAKE2b\text{-}256}(\texttt{"ZTxIdMemoBundHsh"}, \mathsf{concat}(\mathsf{memo\_chunk\_digests}))$
+
+For pruned chunks, the $\mathsf{memo\_chunk\_digest}$ stored in the transaction
+encoding is used directly.
 
 The memo bundle digest is used in place of the full memo bundle when
 the bundle has been pruned.
@@ -784,9 +943,11 @@ TBD
 
 [^zip-0200]: [ZIP 200: Network Upgrade Mechanism](zip-0200.rst)
 
+[^zip-0248]: [ZIP 248: Extensible Transaction Format](zip-0248.rst)
+
 [^draft-arya-deploy-nu7]: [draft-arya-deploy-nu7: Deployment of the NU7 Network Upgrade](draft-arya-deploy-nu7.md)
 
-[^zip-0230-orchard-note-plaintext]: [ZIP 230: Version 6 Transaction Format — Orchard Note Plaintext](zip-0230.rst#orchard-note-plaintext)
+[^zip-0230-note-plaintexts]: [ZIP 230: Version 6 Transaction Format — Note Plaintexts](zip-0230.rst#note-plaintexts)
 
 [^zip-0248]: [ZIP 248: Extensible Transaction Format (PR: zcash/zips#1156)](https://github.com/zcash/zips/pull/1156)