ZCash

Recent Commits

• Kris Nuttycombe (09 Jul 26)

  Merge pull request #7212 from pacu/fix-end-of-life doc: update NU6.3 activation dates in End of Life timeline

• Pacu (09 Jul 26)

  doc: update NU6.3 activation dates in End of Life timeline Testnet activation moved from July 3rd to July 4th 2026, and mainnet activation from July 21st to July 28th 2026. Update the README banner, the End of Life timeline, and the deprecation pages accordingly. Co-Authored-By: Claude Fable 5 <[email protected]>

• Kris Nuttycombe (02 Jul 26)

  Merge pull request #7203 from pacu/doc-zcashd-end-of-life doc: add End of Life section to the zcashd book

• Francisco Gindre (02 Jul 26)

  Fix timeline with testnet activation and address PR review comments

• Francisco Gindre (01 Jul 26)

  doc: revise zcashd End of Life around a single End-of-Support milestone Recalculating the block height 3417100 halt at the current block rate puts the estimated End-of-Support halt around July 18th 2026. This also decouples the halt from NU6.3 mainnet activation: the halt is now targeted to precede activation (estimated July 21st 2026) so that every un-upgraded zcashd node has shut down and the network is Zebra-only before NU6.3 takes effect. Drop the separate July 15th "Deprecation" (maintainer-support-ends) date and reframe the docs around a single zcashd milestone (the End-of-Support halt) plus the later NU6.3 activation, across the End of Life page, README, and the deprecation/release-support pages. The per-release table in release-support.md is left unchanged, since it records the historical estimate captured at each release time and is regenerated by make-release.py. Co-Authored-By: Claude Opus 4.8 <[email protected]>

• Francisco Gindre (30 Jun 26)

  doc: add End of Life section to the zcashd book Add a dedicated "End of Life" page to the zcashd book documenting the July 15th 2026 deprecation and the path forward to Zebra + Zallet, and link to it from the places where it is relevant (README, release-support, and the user/dev deprecation pages). The page disambiguates two distinct milestones that were previously conflated: - Deprecation (July 15th 2026): maintainer support ends; not enforced by the binary. - End-of-Support halt (~July 21st 2026, block height 3417100): the automatic on-chain shutdown driven by DEPRECATION_HEIGHT in src/deprecation.h, coinciding with NU6.3 mainnet activation. Co-Authored-By: Claude Opus 4.8 <[email protected]>

• Kris Nuttycombe (18 Jun 26)

  Merge pull request #7187 from daira/5960-orchard-divergence-graceful Improve robustness of Orchard note commitment tree consistency checks

• John (17 Jun 26)

  Merge pull request #7197 from nullcopy/feat/qa/wallet-builder qa(wallet-builder): Add ancient pre-Sapling, non-deterministic wallet mode

• John Boyd (17 Jun 26)

  qa(wallet-builder): Add ancient pre-Sapling, non-deterministic wallet mode Add a new `make ancient` target to build an "ancient" regtest wallet.dat, simulating a pre-sapling non-deterministic zcashd wallet. This is achieved by aborting the multi-phase wallet builder after it completes the pre-sapling phases, leaving a wallet from the earliest era. This is useful for testing importing the oldest zcashd wallets.

• Kris Nuttycombe (17 Jun 26)

  wallet: refuse spends during shutdown in the caller, not the spend-info getter Move the ShutdownRequested() check out of CWallet::GetOrchardSpendInfo — a const accessor — and into its sole production caller, TransactionEffects::ApproveAndBuild, where it returns a TransactionBuilderResult error rather than throwing. The check stays under the same cs_wallet hold that guards the witness/anchor reads, so it retains the happens-before against the divergence detector (which requests the shutdown while holding cs_wallet in CWallet::IncrementNoteWitnesses): a spend that observes no request has read a tree that was consistent at that point. This restores GetOrchardSpendInfo to an idempotent getter and turns the refusal into a returned error instead of an exception. The check now also covers the Sapling witness gathering in the same block, refusing the whole shielded spend during shutdown. Co-Authored-By: Claude Opus 4.8 <[email protected]>

• Kris Nuttycombe (17 Jun 26)

  doc: clarify the Orchard checkpoint-before-append convention The spend-path gtests checkpoint each block's height *before* appending that block's commitments, mirroring CWallet::IncrementNoteWitnesses: the checkpoint identified by H records the tree state at the end of block H-1. Spell this out where the comments previously read as if the checkpoint belonged to the block whose commitments are appended next, and note that GetSpendInfo resolves an anchor at absolute height H to checkpoint id H+1 via depth = lastCheckpointHeight - H. Also correct the GetAnchorAtCheckpointDepth header comment: depth 0 is the current frontier (the state after the most recent append), not the most recent checkpoint (which is at depth 1). Co-Authored-By: Claude Opus 4.8 <[email protected]>

• Kris Nuttycombe (17 Jun 26)

  Merge pull request #7194 from zcash/avoid-wtx-copy-in-setbestchain Avoid copying each CWalletTx in SetBestChain's flush loop

• Kris Nuttycombe (16 Jun 26)

  Avoid copying each CWalletTx in SetBestChain's flush loop SetBestChainINTERNAL iterates all of mapWallet on every flush and copied each CWalletTx by value (`auto wtx = wtxItem.second`) only to read its note-data maps and hand it to WriteTx, which takes a `const CWalletTx&`. For wallets with very large transaction histories -- e.g. mining pools, whose coinbase outputs must pass through a shielded pool by consensus and so accumulate substantial shielded history -- this performs a deep copy of a heavy CWalletTx for every wallet transaction on every flush. Bind a const reference instead. This is a non-functional change; the set of transactions written is unchanged. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

• Daira-Emma Hopwood (07 Jun 26)

  qa: wait for the wallet to catch up before the Orchard spend in p2p_duplicate test p2p_duplicate_block_clobbers_chain_value.py activated NU5 with node.generate(11) and immediately built an Orchard shielding transaction. The wallet's Orchard note commitment tree is updated on the asynchronous wallet notification thread, so under load the wallet could still be catching up when the spend was built, leaving its latest checkpoint below the spend anchor's height. GetSpendInfo then correctly reports that the wallet has not reached the anchor's block (a known limitation documented there), and the test failed spuriously. Wait for the wallet to process the generated blocks —observed via the wallet's coinbase transaction count, which is updated in the same block-connect step that extends the Orchard tree— before spending. Refs #5960, #7150. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

• Daira-Emma Hopwood (06 Jun 26)

  test: cover the Orchard divergence clean-shutdown recovery Add an OrchardDivergenceTest fixture with two gtests asserting that a detected Orchard note commitment tree divergence requests a clean shutdown (via OrchardNoteCommitmentTreeDiverged) and notifies the operator, rather than aborting the node: - ForwardConsistencyCheckRequestsCleanShutdown covers the forward check on the connect path (IncrementNoteWitnesses with performConsistencyCheck = true). - DisconnectRequestsCleanShutdown covers the disconnect path (DecrementNoteWitnesses), the original #5960 crash loop. Each records a consensus Orchard root that the wallet's tree will not match, then asserts the handler requested a shutdown (ShutdownRequested()) and notified the operator via ThreadSafeMessageBox. The fixture connects the shared mock in SetUp and disconnects it / clears the shutdown request in TearDown, so cleanup runs even on an early return. Refs #5960. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

• Daira-Emma Hopwood (06 Jun 26)

  refactor: share the ThreadSafeMessageBox mock between gtests Move MockUIInterface out of test_deprecation.cpp into gtest/utils and add ConnectMockUIInterface / DisconnectMockUIInterface helpers there, so other gtests that exercise code which notifies the user via uiInterface.ThreadSafeMessageBox can reuse them. The gtest harness connects no slot to that signal, so without a mock its signals2 combiner throws on zero slots; DisconnectMockUIInterface also clears any shutdown the test requested. No behaviour change: test_deprecation.cpp now connects and disconnects the shared mock via these helpers instead of its own local copy. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

• Daira-Emma Hopwood (06 Jun 26)

  wallet: run the Orchard forward consistency check on every connected block Verifying that the wallet's Orchard note commitment tree root matches the connected block's consensus root catches a tree divergence (#5960) at the point it occurs, rather than only later —fatally— on the disconnect path during a reorg. #6052 disabled this per-block check because computing the wallet's anchor re-folded the commitment tree frontier on every block, slowing bulk scanning by an order of magnitude. bridgetree now memoizes the frontier root and recomputes it only when the tree changes, so the anchor is O(1) for any block that appends no Orchard commitments — the common case at the tip. The check is therefore cheap enough to run on every block connected through CWallet::ChainTip, including during offline catch-up; it is no longer gated on a brittle block-time "near the tip?" proxy that could leave a divergence undetected while a node caught up after being offline. Thread a performConsistencyCheck flag through ChainTipAdded to IncrementNoteWitnesses. ChainTip passes true; the bulk-rescan caller in ScanForWalletTransactions passes false, since a rescan rebuilds the tree from the consensus frontier and so cannot have diverged from it. On a mismatch, request a clean shutdown via OrchardNoteCommitmentTreeDiverged —the same recovery as the disconnect path— prompting the operator to restart with `-rescan`. The frontier-root memoization is provided by bridgetree 0.7.1 (zcash/incrementalmerkletree#146). Refs #5960, #6052. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

• Daira-Emma Hopwood (06 Jun 26)

  wallet: address the wallet's Orchard tree by absolute height when spending The spend anchor is the consensus Orchard tree root at a fixed block height, chosen some confirmations behind the chain tip (anchorHeight, in wallet_tx_builder). GetSpendInfo, however, validated that anchor and fetched witnesses using a checkpoint depth measured relative to the wallet's latest checkpoint (`anchorConfirmations - 1`). Those two coordinate systems coincide only when the wallet's latest checkpoint sits at exactly the chain height the caller read. Wallet scanning runs asynchronously from the chain tip, so a block connecting between anchor selection and spend construction advances the wallet's latest checkpoint and makes the relative-depth lookup resolve to a different checkpoint than the anchor — a spurious mismatch with no actual divergence (#7150). The anchor is kept approximately the given anchor depth behind the tip (for reorg resilience, while still keeping most notes in the traceability set), but need not be exactly that depth behind. In particular, a newer block arriving before the spend is built, or a short reorg, are expected cases that should not change which checkpoint is used. Pass the anchor's absolute height to GetSpendInfo, derive the checkpoint depth from it (`lastCheckpointHeight - anchorHeight`), and use that depth for both the root check and the witness fetch. As the wallet advances, the depth grows to keep pointing at the same checkpoint, so the originally-selected anchor stays valid as long as it remains within the wallet's retained checkpoints — handling the common race with no retry. This lets the spend path tell apart causes that the bare anchor check conflated: - the wallet has no checkpoint at the anchor height (it has not scanned that far yet, or the anchor has aged out of the retained checkpoints): the spend cannot be built against this anchor, but the tree is not corrupt; - a checkpoint exists but its root differs from consensus: the tree has genuinely diverged, and only this case directs the operator to `-rescan`. GetOrchardSpendInfo and GetSpendInfo now take an absolute anchorHeight rather than a confirmation count. The old count and the new height are both integers, so leaving them in the same argument position would let a missed call site compile with the wrong meaning; the anchor and height arguments are therefore reordered to make any missed site a compile error. A depth-based GetAnchorAtCheckpointDepth accessor replaces the now-unused GetAnchorWithConfirmations. Closes #7150. Refs #5960. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

• Daira-Emma Hopwood (06 Jun 26)

  wallet: throw instead of aborting on an Orchard spend anchor mismatch OrchardWallet::GetSpendInfo asserted that the wallet's Orchard anchor equalled the anchor the caller selected from the consensus state, aborting the whole node if they differed. That assertion is reachable on the ordinary spend path (for example z_sendmany), so a wallet-level anchor mismatch could take the node off the network. Convert the assertion to a thrown error, so the spend operation fails (the async-operation runner reports the error to its caller) instead of crashing the node. The message stays neutral: an anchor mismatch here does not by itself distinguish a genuine divergence (which would warrant `-rescan`) from a benign race against a newly connected block, so it prescribes no remedy. This complements the shutdown-time refusal in CWallet::GetOrchardSpendInfo, which closes the spend window once a divergence has been detected. Refs #5960, #7150. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

• Daira-Emma Hopwood (06 Jun 26)

  wallet: refuse Orchard spends while a shutdown is in progress StartShutdown only requests an asynchronous shutdown, so between the request and the node actually stopping, an RPC or async-operation thread can still begin an Orchard spend. Refuse one, for two reasons: - Orchard proof construction is slow relative to the shutdown process, so a spend started during shutdown is unlikely to complete before the node stops. - When the shutdown was triggered by a detected Orchard note commitment tree divergence (OrchardNoteCommitmentTreeDiverged), the wallet's tree is known to be inconsistent, so reading it to select an anchor and witnesses would build a spend against bad state. Check ShutdownRequested() in CWallet::GetOrchardSpendInfo and return a clean error. This runs under cs_wallet, which the divergence detector also holds when it requests the shutdown, so any spend that begins after detection observes the request — closing the window in which a spend could read the diverged tree. Refs #5960, #7150. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

• Daira-Emma Hopwood (05 Jun 26)

  wallet: fail cleanly instead of aborting when the Orchard tree diverges on disconnect CWallet::DecrementNoteWitnesses rewinds the wallet's Orchard note commitment tree on a block disconnect, then asserts that the rewound tree's anchor equals the disconnected block's parent's hashFinalOrchardRoot. If the wallet's tree has silently diverged from consensus, that assertion aborts the node. Because the diverged tree is durable on disk, the node comes back up still diverged and re-aborts on the next reorg — a restart-proof crash loop (#5960), made worse because each abort is itself an unclean shutdown. Replace the fatal assertion with a recovery path: a new helper, OrchardNoteCommitmentTreeDiverged, logs the divergence, notifies the operator, and requests a clean shutdown (via StartShutdown, not throw, since this runs on the wallet notification thread where an escaping exception would terminate the process). Restarting with `-rescan` rebuilds the wallet's Orchard state from the consensus note commitment tree. StartShutdown is asynchronous: it sets ShutdownRequested() synchronously, but the node keeps running until the main loop polls it. Without a further guard, the notification thread would continue processing the remaining blocks of a multi-block reorg, re-reaching the sibling rewind/witness assertions (which remain fatal) and further mutating the already-diverged tree. So also return at the top of CWallet::ChainTip once ShutdownRequested() is set. Guarding at the ChainTip level —rather than inside Increment/DecrementNoteWitnesses— skips the whole block, keeping the note commitment trees and the persisted best block (written by SetBestChain in ChainTipAdded) in lockstep, and stops further corruption synchronously at detection rather than waiting for the asynchronous shutdown. The Orchard tree is only mutated on this path and the rescan path (which already checks ShutdownRequested). This changes behaviour only when the tree was already inconsistent; a normal reorg of a healthy wallet rewinds and replays unchanged. It converts the abort into a clean, operator-actionable shutdown; rebuilding the Orchard tree (e.g. with `-rescan`) remains the operator's to perform. Refs #5960. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

• John (09 Jun 26)

  Merge pull request #7136 from nullcopy/feat/qa/wallet-builder qa: Add historical regtest wallet builder

• John (08 Jun 26)

  Update qa/zcash/wallet-builder/lib/constants.py Co-authored-by: Daira-Emma Hopwood <[email protected]>

• John (08 Jun 26)

  Update qa/zcash/wallet-builder/lib/constants.py Co-authored-by: Daira-Emma Hopwood <[email protected]>

• John Boyd (08 Jun 26)

  qa(wallet-builder): Use magic awk to generate Make help

• John Boyd (07 Apr 26)

  qa: Add historical regtest wallet builder Add a Docker-based QA tool that builds a regtest chain with wallet state spanning all 9 network upgrades (Sprout through NU6.1). The tool switches between zcashd versions at each NU boundary, creating a wallet.dat test fixture containing transparent UTXOs, Sprout/Sapling/Orchard shielded notes, cross-pool transfers, foreign key imports, and per-phase manifests. Moved over from https://github.com/nullcopy/zcash-regtest-wallet-builder Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

• Kris Nuttycombe (04 Jun 26)

  Merge pull request #7172 from zcash/dependabot/github_actions/docker/login-action-4.2.0 build(deps): bump docker/login-action from 4.1.0 to 4.2.0

• Kris Nuttycombe (04 Jun 26)

  Merge pull request #7178 from zcash/dependabot/github_actions/actions/checkout-6.0.3 build(deps): bump actions/checkout from 6.0.2 to 6.0.3

• John (04 Jun 26)

  Merge pull request #7184 from daira/7182-gtest-orchard-assert-no-fatal-failure qa: Guard BuildOrchardSpend test-helper calls with ASSERT_NO_FATAL_FAILURE

• Daira-Emma Hopwood (04 Jun 26)

  qa: Guard BuildOrchardSpend test-helper calls with ASSERT_NO_FATAL_FAILURE The BuildOrchardSpend and MakeOrchardProofNonCanonicalBytes helpers in test_orchard_wallet.cpp use ASSERT_* macros internally. A googletest ASSERT_* in a void subroutine expands to `return;`, which returns only from the helper, not from the calling TEST: a failed assumption is registered but the test keeps running. BuildOrchardSpend's call sites invoked it unguarded, so a violated assumption would leave the caller's CTransaction default-constructed and let the test continue against an empty/invalid transaction (a confusing failure cascade or undefined behaviour, rather than a clean abort at the real cause). Wrap all five BuildOrchardSpend calls in ASSERT_NO_FATAL_FAILURE(...), matching the existing MakeOrchardProofNonCanonicalBytes call sites. Also correct the comment on MakeOrchardProofNonCanonicalBytes, which claimed the out-parameter plus `return;` pattern aborts the test (it does not; the abort comes from the caller's ASSERT_NO_FATAL_FAILURE), and document the same call-site requirement on BuildOrchardSpend. Closes #7182. Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>