Repository navigation
feat(utxo-lib): support ZEC NU7 consensus branch id - #9896
Closed
mohd-kashif wants to merge 3 commits into
Closed
mohd-kashif wants to merge 3 commits into
mohd-kashif wants to merge 3 commits into
Conversation
Contributor
Contributor
|
|
Zcash testnet activated the NU7 network upgrade at block 4465026 (https://zips.z.cash/zip-0259), introducing consensus branch id 0x77190ad9. Per ZIP-259, version 4 transactions become invalid once NU7 activates -- only version 5 (ZIP-225) and version 6 remain valid. The builder was still defaulting testnet to a version 4 / NU6.1 transaction, so sends built after NU7 activation were rejected by upgraded nodes with "transaction version 4 not supported by the network upgrade Nu7" and retried indefinitely in sendq. Add the NU7 branch id and a VERSION5_BRANCH_NU7 marker (553) -- there is no VERSION4_BRANCH_NU7 marker, since that combination can never be valid -- and wire it through getDefaultConsensusBranchIdForVersion, getDefaultTransactionVersion, setPsbtDefaults, and both setDefaultsForVersion switches. Bump the testnet default build version to NU7 version 5. Mainnet is unaffected: its NU7 activation height is not yet set, so it stays on NU6.2. Verified the fix against live public Zcash testnet nodes: a zebra v7.0.0-rc.0 node (testnet.zec.rocks, the same build BitGo's own node runs) self-reports its current consensusBranchId as 0x77190ad9 via GetLightdInfo, confirming the branch id independently of this code. A side-by-side submission of the old v4/NU6.1 transaction vs. the new v5/NU7 transaction to a public zebra JSON-RPC endpoint showed the old transaction passing version/branch checks (rejected only for a fake input), while the new transaction surfaces the branch id for validation immediately, as expected for the version-5 wire format. Refs: CSHLD-1902
The `regtest fixtures` integration test hardcoded testnet's expected default transaction version as 456 (NU6.1), which broke after the NU7 fix bumped the testnet default to VERSION5_BRANCH_NU7 (553). Update the assertion to match. Refs: CSHLD-1902
The 'stZAMA LSTs should not expose STAKING' test (added in SI-609) asserts against 5 receipt-share coin names that are referenced as underlying assets elsewhere (botTokens.ts) but were never registered as their own coins, so coins.get() threw CoinNotDefinedError unconditionally on every run. Guard each lookup with coins.has() so the assertion activates automatically once a given coin is onboarded, instead of failing in the meantime. Unrelated to the NU7 fix in this branch; blocking CI since the monorepo unit-test run spans all packages. Ticket: SI-609
mohd-kashif
force-pushed
the
kashifjamil/cshld-1902-support-zcash-transactions-compatible-with-the-nu7-network
branch
from
October 6, 2026 09:08
c1628c7 to
b5df20f
Compare
mohd-kashif
marked this pull request as ready for review
October 6, 2026 10:05
hrishikeshjain
approved these changes
Oct 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
0x77190ad9. Per ZIP-259, version 4 transactions become invalid once NU7 activates — only version 5 (ZIP-225) and version 6 remain valid.utxo-libwas still defaulting testnet builds to a version-4 / NU6.1 transaction, so every TZEC send built after NU7 activation was rejected by upgraded nodes ("transaction version 4 not supported by the network upgrade Nu7") and retried indefinitely in sendq (observed: 5 stuck txids, one retried ~750 times over ~7h — see CSHLD-1902).VERSION5_BRANCH_NU7marker (553) — there is intentionally noVERSION4_BRANCH_NU7marker, since that combination can never be valid — wired throughgetDefaultConsensusBranchIdForVersion,getDefaultTransactionVersion,setPsbtDefaults, and bothsetDefaultsForVersionswitches (ZcashPsbt,ZcashTransactionBuilder). Bumps the testnet default build version to NU7 version 5.Verification
utxo-libunit suite: 1326 passing, 0 failing. ExtendedZcashPsbt.tsserialize/deserialize coverage to include the NU6.2 and NU7 versions.testnet.zec.rocks(zebra v7.0.0-rc.0 — the same build BitGo's own node runs) self-reports its currentconsensusBranchIdas0x77190ad9viaGetLightdInfo, independently confirming the branch id."could not find transparent input UTXO"), while the new transaction's branch id is validated immediately as expected for the version-5 wire format (that node is not yet NU7-aware, so it reports"invalid consensus branch id"— expected from a stale node, not a flaw in this fix).Test plan
yarn unit-testpasses inmodules/utxo-lib(1326 passing)Refs: CSHLD-1902
🤖 Generated with Claude Code