feat(consensus): implement ZIP 233 behind a build feature

[evan-forbes]

Stacked on #856 (ZIP 2003) → #851 (ZIP 218). Third of the remaining NU7 consensus changes.

Implements ZIP 233 "Network Sustainability Mechanism: Removing Funds From Circulation" behind the off-by-default zip233 cargo feature. Ported from the merged upstream zebra#8930, extended here with the ZIP 244 commitment, the activation rule, and the build-flag guard.

ZIP 233 is one of the two ZIPs behind Q1 of the ZCAP and coinholder polls, and it is what makes ZIP 234's reissuance and ZIP 235's fee burning expressible.

Transaction format

Transaction::V6 gains zip233_amount, serialized as an 8-byte little-endian amount after nExpiryHeight and committed to by the ZIP 244 header digest as T.1f.

zakura-primitives already implements the same two changes behind its own zip-233 feature, which zip233 turns on, so the native ZIP 244 digests and librustzcash stay in lockstep. The existing native_zip244_matches_test_vectors, v6_zip244_sighash_matches_librustzcash, and script_code_commitment_is_version_specific cross-checks all pass with the feature on, which is what shows the two implementations agree byte for byte.

The build flag

The zakura-primitives half is also gated on cfg(zcash_unstable = "nu7"), which no cargo feature can set on a dependency. A zip233 build without RUSTFLAGS='--cfg zcash_unstable="nu7"' would disagree with librustzcash about the v6 wire format — a consensus split, not a compile error.

Cargo features have to be additive, so this cannot be a compile_error!: cargo check --all-features runs in CI and would fail. Instead ZIP233_ENABLED requires the cfg as well as the feature, so a build missing the flag follows today's consensus rather than half of ZIP 233. The two sides are on and off together by construction. The CI job sets the flag.

A zcash_unstable = "nu7" build also gives NU7 the branch ID zcash_protocol maps it to (0xffffffff) rather than Zakura's 0xfffffffe placeholder, because Transaction::to_librustzcash round-trips the branch ID through it. Any other build is unchanged.

Consensus

• zip233_amount_is_valid rejects a burn before NU7, which is when ZIP 233 activates. Amount<NonNegative> already bounds the amount to {0 .. MAX_MONEY}.
• miner_fee subtracts the burn from the transaction's remaining value. The coinbase is checked against the block subsidy plus these fees, so this one subtraction is what stops the coinbase reclaiming the burn: the block's net transparent pool change becomes subsidy − burn, and the money reserve ZIP 234 reads grows by the burned amount.
• has_inputs_and_outputs accepts a transaction whose only effect is a burn.

Tests

• zip233_amount_is_committed_to_by_the_txid — two transactions differing only in the burn must have different txids, and both must round-trip and match librustzcash. Without this commitment the amount would be malleable.
• The v6 serialization proptest now generates random burn amounts under the feature.
• zip233_amount_activates_at_nu7_and_is_not_a_fee — the activation boundary and the fee exclusion.
• A zip233 CI job mirroring the zip218 one, with the required RUSTFLAGS.

Default build: 1270 tests pass across zakura-chain, zakura-consensus, zakura-rpc, and zakura-state; clippy clean.

Follow-ups

• The RPC transaction JSON does not expose zip233Amount.
• A zip233 build changes the v6 wire format from NU6.3 onward, not from NU7, because that is what zakura-primitives does today (TxVersion::V6 => has_zip233() == true). A real deployment needs the format gated on the branch ID so NU6.3-era v6 transactions keep parsing, which is a change in the fork first.
• NU7's final branch ID (0x77190ad8) still needs coordinating across Zakura and librustzcash.

[evan-forbes]

The August 2026 NU7 poll explicitly excludes transaction-format changes and names ZIP 233 as inapplicable to NU7. Closing this superseded scope. PR #859 has been rebuilt without ZIP 233 or ZIP 235 and now stacks directly on #856.