[ZIP TBD]: Define a forward-compatible, extensible transaction format. #1156

nuttycom · 2026-01-11T00:21:33Z

nuttycom

Flushing comments from ZIP editing.

nuttycom · 2026-01-20T21:43:41Z

zips/draft-core-extensible-tx-format.rst

+reduce the impact of future changes to the Zcash transaction format on the
+Zcash ecosystem. It defines a new typecode-length-value encoding for a sequence
+of protocol bundles, and a "value balance" map that describes the effect of
+each bundle on the transparent chain value balance, much in the same fashion


This should probably note that it's an effect on the transparent chain value balance(s) for potentially multiple assets.

nuttycom · 2026-01-20T21:53:54Z

zips/draft-core-extensible-tx-format.rst

+* Movement of value into and out of the transparent value pool(s) can be
+  understood with only partial knowledge of the Zcash payment protocols.


Reword this to make clear that there's a transparent value pool for each ZSA asset type, in addition to the ZEC transparent value pool.

zips/draft-core-extensible-tx-format.rst

nuttycom · 2026-01-20T22:15:31Z

zips/draft-core-extensible-tx-format.rst

+| varies                      |``bundleType``                |``compactSize``                                 |An encoding of the bundle type identifier.                           |
+-----------------------------+------------------------------+------------------------------------------------+---------------------------------------------------------------------+
+| 1                           |``assetClass``                |``uint8``                                       |An asset class identifier. 0x00 for the ZEC asset, 0x01 for ZSA      |
+|                             |                              |                                                |assets. All other values are reserved for future use.                |


@arya2 suggested that if we instead represented bundleType as a u8, we could represent assetClass as a flag bit within that value. This would restrict us to 128 possible bundle types within a transaction version (which is probably enough).

nuttycom · 2026-01-20T22:27:09Z

zips/draft-core-extensible-tx-format.rst

+------------+------------------------------------+----------------------------+-------------------------------------------------------------+
+|            |✅                                  |✅                          | ZSA Issuance                                                |
+------------+------------------------------------+----------------------------+-------------------------------------------------------------+
+|            |✅                                  |✅                          | OrchardZSA                                                  |


In the case that OrchardZSA is deployed separately from Orchard-post-ZIP 231 and/or Orchard(current), we will need a consensus rule that states that for a given transaction, only one Orchard bundle is permitted (and the same for Sapling pre/post ZIP 231).

nuttycom · 2026-01-20T22:48:16Z

zips/draft-core-extensible-tx-format.rst

+------------+------------------------------------+----------------------------+-------------------------------------------------------------+
+| 4\*        |✅                                  |❌                          | Transaction fee (\*if ZIP 2002 activated)                   |
+------------+------------------------------------+----------------------------+-------------------------------------------------------------+
+| 5\*        |✅                                  |❌                          | ZIP 233 NSM field (\*if ZIP 233 activated)                  |


In ZIP Sync, we discussed the possibility that NU7 be a truly minimal upgrade activating bundle types 0-5. This could be activated on testnet prior to the availability of zcashd deprecation, and subsequent additive network upgrades can be deployed on testnet; then, once zcashd deprecation is complete, everything that has activated on testnet is able to be deployed to mainnet. We might jump straight from NU6.1 to NU8 on mainnet.

daira · 2026-01-27T21:08:16Z

protocol/protocol.tex

 \DeclareFontFamily{U}{FdSymbolA}{}
 \DeclareFontShape{U}{FdSymbolA}{m}{n}{
-    <-> s*[.4] FdSymbolA-Regular
+    <-> s*[.4] FdSymbolA-Book


This should not be in this PR.

zips/draft-core-extensible-tx-format.rst

…ible transaction format.

…nce.

…ng data bundles.

…nt, Sapling, and Orchard. Specifies the effecting and authorizing data structures for each bundle type, with value balance moved to mValuePoolDeltas as per the extensible tx format design. Co-Authored-By: Claude Opus 4.5 <[email protected]>

… auth commitment. Specifies the V6 transaction digest algorithms: - TxId digest with separate value_pool_deltas_digest and dynamic effects_bundles_digest - Signature digest for transparent input signing with hash_type support - Authorizing data commitment for witness data Key design decisions: - Value balances committed via top-level value_pool_deltas_digest (not per-bundle) - effects_bundles_digest uses tagged concatenation (bundle_type_id || root_hash) - Unknown bundle types supported by accepting their root hash externally Co-Authored-By: Claude Opus 4.5 <[email protected]>

…ype registration process. Restructure the specification to begin with a comprehensive introduction to protocol bundles, explaining effecting data, authorizing data, and the transparent transaction value pool concepts. Define the bundle type registration process that ZIPs must follow when introducing new bundle types. Move the bundle type registry to appear before the transaction format specification for better readability. Co-Authored-By: Claude Opus 4.5 <[email protected]>

…ypes spec.

- Update PR URL to 1156 and fix email addresses - Use conformance language (MAY/MUST NOT) for registry column descriptions - Add constraint that map keys must be in increasing order - Change "ordered by" to "in increasing order of" throughout - Fix "transparent transaction value pool" terminology - Change AssetUuid subscript notation to function notation - Add registry update mechanism language - Add "Defining ZIP" column to bundle type registry table - Rephrase consensus rules section to clarify modifications to protocol spec - Add clarifying text for fee bundle semantics (coinbase collects, others pay) - Add mutual exclusion consensus rule for Sapling/Orchard bundle variants Co-Authored-By: Claude Opus 4.5 <[email protected]>

nuttycom force-pushed the draft/extensible_tx_format branch 3 times, most recently from 04ea4cc to 3f5566b Compare January 20, 2026 06:03

nuttycom commented Jan 21, 2026

View reviewed changes

nuttycom force-pushed the draft/extensible_tx_format branch 3 times, most recently from b26bc92 to c7a649b Compare January 26, 2026 17:32

daira reviewed Jan 27, 2026

View reviewed changes