NU6.2 activated at block height 3,364,600 and made exactly 2 changes to the Zcash consensus rules. One of them fixed the soundness bug that forced the upgrade. The other closed a gap that had been open since the shielded protocol shipped and had nothing to do with the bug at all.
Four separate searches around this upgrade return no ranking pages whatsoever, including a search for the name of the shielded protocol it corrected. The material exists in a Final specification and in two Rust crate releases, and nowhere else.
what follows covers the rules. Our guide to Zcash orchard vulnerability 2026 covers the incident that produced them, and the two do not overlap.
What NU6.2 changed, stated as rules
The deployment specification lists the consensus changes with no preamble at all. Reading them as rules rather than as a narrative is the fastest route into what this upgrade actually did to the network, which is a different question entirely from why it happened at the time it did.
The first change corrects one gadget inside the Orchard Action circuit, the variable-base scalar multiplication routine, which fixes the soundness vulnerability and changes the Orchard verifying key as a consequence.
The second is separate and easy to miss: "from the activation of NU6.2, an Orchard Action proof MUST have the canonical length for the corrected circuit. Before NU6.2, this length was not enforced as a consensus rule" (source: ZIP 257).
A third item is a consequence rather than a change in its own right. The temporary mitigation that had disabled Orchard ceases to apply, so transactions containing Orchard Action descriptions must again be accepted, with their proofs verified under the corrected circuit and subject to the new length rule.
Two rules and one consequence is the whole of it, which is a small footprint for an upgrade that arrived under emergency conditions.
Both changes take effect at the same height, which is the only way consensus changes can be deployed: there is no partial activation and no opt-in period.
Our guide to Zcash network upgrades covers what a network upgrade is and how activation works. For the general mechanism, see how a chain's rules get changed, and for who has to act, nodes, miners and wallets.
The corrected circuit, and how small the correction was
The most interesting property of the fix is its size, stated directly in a single clause of the specification, and almost nothing written about the incident afterwards mentions it, despite that detail settling how far a reader's distrust ought to extend.
"The two circuits differ only in the additional copy constraints added to ensure soundness."
Copy constraints are the arithmetic-circuit equivalent of asserting that two wires carry the same value. This is a different kind of proof from the one securing blocks, which proof of work covers. Adding some does not restructure the computation, it constrains what the computation is permitted to claim, and the difference between the vulnerable circuit and the corrected one is entirely of that kind.
That is worth sitting with, because it cuts against the intuition that a soundness failure implies a design flaw. The protocol specification's own disclosure note says as much, confining the defect to the circuit implementation and affirming that the Action statement itself was always what it was meant to be (source: Zcash protocol specification). The statement being proven was never wrong. The circuit proving it permitted a witness it should have rejected, and the repair was to forbid that witness rather than to rethink anything.
The reference implementation carries both versions under names that make the distinction unmissable, exposing an enumeration whose variants are InsecurePreNu6_2 and FixedPostNu6_2.
Naming a shipped circuit version Insecure in a public API is a choice worth noticing. The alternative would have been a neutral label, and a neutral label would have made it easier for an implementer to select the wrong one by accident.
The changed verifying key, and why nothing can mix
This is the part carrying the largest practical consequence for anyone running a node, and it follows mechanically from the correction described in the previous section rather than being a separate design decision that anybody made deliberately at any point.
Correcting the circuit changes the verifying key derived from it, and the specification is explicit about what that means for proofs on either side of the boundary: pre-NU6.2 Action proofs verify only under the historical, insecure key, and NU6.2-onward proofs only under the corrected one.
So the chain must retain both keys permanently. Every historical Orchard transaction was proven against the original circuit, and validating the chain from genesis requires verifying those proofs exactly as they were made. The insecure key cannot be deleted without making the chain's own history unverifiable.
That produces an arrangement worth naming clearly. A block height partitions the chain into two verification regimes, and a node must implement both to be a full node at all. Nothing about that is unusual for a consensus change, and it is the concrete reason upgrades accumulate complexity rather than replacing it.
The reference libraries expose exactly that: separate constructors for building a proving or verifying key against a chosen circuit version, so software can produce and check proofs on either side of the boundary (source: zcash_protocol).
The general relationship between public and private keys sits underneath this, and our guide to How Zcash mining works covers what a proving system does in the first place.
The length rule that nobody was enforcing
The second consensus change is the one that would have been worth making even in the absence of any vulnerability at all, which arguably makes it the more durable half of this upgrade despite having received essentially none of the attention.
Before this upgrade, an Orchard Action proof's length was not a consensus rule. A proof of non-canonical length, padded with arbitrary data, would still validate. After activation, the canonical length is required.
The reference library treats this as its own security issue rather than as part of the circuit fix, carrying a separate advisory identifier for the change that rejects a proof "whose length is not the canonical size for the bundle's number of actions", and making the checked constructor the only way to build an authorized bundle (source: librustzcash changelog).
Why it matters is transaction malleability. Data that a transaction carries but that nothing constrains is data an intermediary can alter, and in some designs altering it changes the transaction's identifier while leaving it valid. Closing an unconstrained field closes that class of possibility.
So NU6.2 did two different kinds of work. One change repaired a specific defect. The other tightened something that had been loose since Orchard shipped, and the emergency simply provided the occasion to ship it.
That pattern is common in consensus changes and is worth recognizing, because an upgrade forced by one problem is the cheapest opportunity to fix others. Coordinating a network upgrade is expensive; adding a second rule to one already happening is nearly free.
Activation, constants and the client releases
The deployment specification names everything required to identify this upgrade on the wire and in running software. Reproducing that here is worth the space, because no other page anywhere assembles the constants and the release versions together in one place.
The consensus branch identifier is 0x5437F330. Activation height is 3,364,600 on Mainnet and 4,052,000 on Testnet. The minimum network protocol version is 170150 on both networks, and nodes compatible with the activation must announce at least that.
The project's upgrade record puts activation at that height on June 3, 2026 (source: Zcash).
Those constants are what a node actually keys on. A block is valid under NU6.2 rules only after the activation height, and peers that cannot speak the minimum protocol version are not upgrade-compatible at all.
On the software side, NU6.2 was deployed in zcashd v6.20.0 and zebra v5.0.0, while the underlying fix was published in halo2_gadgets v0.5.0 and orchard v0.14.0. Two node implementations and two cryptographic libraries, which is the ordinary shape of a Zcash upgrade rather than anything specific to this one. The specification's discussion history for the deployment is public in the same repository as every other proposal (source: zcash/zips).
The specification changes themselves are versioned: they are stated relative to version 2026.6.4 of the protocol specification and applied in version 2026.7.0. That versioning is what makes an upgrade auditable after the fact, since the diff between two numbered specification releases is the complete record of what changed. Checking any of these heights against the chain yourself takes a block explorer and a minute.
What stayed the same after NU6.2
Four limits, and together they describe an upgrade considerably narrower in scope than its circumstances would suggest to anybody who read only the coverage written about it at the time. Each is a thing a reader could reasonably assume an emergency upgrade would have touched.
It did not change the Orchard statement. The specification's disclosure note, quoted earlier, draws that line explicitly. Nothing about what an Orchard transaction proves was revised, only what a proof of it is permitted to look like.
It did not touch any other pool. Sapling, transparent and the historical pools were unaffected by both changes, because both were specific to the Orchard Action circuit and its proofs.
It did not end the story. A further upgrade followed, and our guide to Zcash network upgrades covers the ladder including what came after. The independent node implementation maintained by the Zcash Foundation shipped its own release for this activation (source: Zebra), which is what having two implementations means in practice.
And it does not tell you what happened. The audit that found the bug, the disclosure, the two-stage response and the coordination difficulty all belong to our guide to Zcash orchard vulnerability 2026, which is a narrative rather than a set of rules and is deliberately absent from this page.
That division is worth defending rather than apologizing for. An upgrade's rules outlive the circumstances that produced them, and mixing the two produces a page that goes stale as soon as the story does.
Anyone running their own node should keep a security checklist alongside an upgrade schedule.
BloFin runs the same client software as any other operator, which is why an upgrade of this kind is invisible to anyone holding there.
What a holder had to do, and when
The operational picture from a holder's side is narrower than the specification work behind it, and separating the two prevents the usual over-reaction.
During the period the affected pool was disabled, funds in it could not be moved. They were not lost, not stolen and not at risk from the defect itself, but they were immobile, and that is the only consequence most holders experienced directly.
After the corrected circuit activated, spending resumed under the new rules. Wallets that had updated handled this transparently; wallets that had not were unable to construct valid proofs, which presented as an inability to send rather than as an error message about consensus rules.
Following the later upgrade that moved the network onto a fresh pool, funds in the older pool needed migrating. That is an ordinary transaction from the holder's side, usually prompted by the wallet, and the prompt is the remedy rather than a warning.
What none of that required was any action taken quickly or under pressure. The sequence took months, each step was announced, and the only holders who had a genuinely difficult time were those running software that had stopped being maintained. That is the durable lesson from the episode: the risk that materialized for individuals was software abandonment rather than cryptography.
There is a second lesson about how the response was structured. The disabling change came first and was deliberately blunt, because stopping the affected mechanism entirely is a smaller and more reviewable change than correcting it under time pressure. The correction followed once it could be reviewed properly, and the migration to a fresh pool came later still, once the corrected circuit had been in service long enough to be trusted. Sequencing a response that way costs users availability in the short term and buys correctness, and the trade is the right one when the alternative is an unreviewed fix to a supply-integrity defect.
A final point concerns what the episode says about auditability rather than about this upgrade specifically. The defect was found by an audit rather than by an attacker, and the response was published in enough detail that anyone can reconstruct it from primary sources years later. Neither of those is guaranteed by anything, and both are properties of how the project chooses to work rather than of its cryptography. When judging a protocol's safety record, the behavior around a defect is at least as informative as the defect count.
What an emergency consensus change requires
The response to the 2026 defect is a useful case study in what a network has to do to change its own rules quickly, because every step of it was public.
A defect has to be characterized precisely before anything can be written. The distinction between a flaw that permits theft and one that permits an accounting violation determines what the fix must prevent, and getting that wrong produces a fix that does not fix.
A rule change has to be specified in enough detail for independent implementations to agree. Two implementations that interpret an urgent specification differently would produce a chain split on top of the original problem, which is materially worse than the problem.
Implementations have to ship and operators have to deploy them before the activation height. This is the step that fails, and it failed here: the first activation attempt did not take because some mining operations had not upgraded in time. That is not a defect in the process so much as a demonstration of what the process depends on.
And the change has to be narrow. An emergency specification that touches more than the defect requires expands the review burden at exactly the moment review capacity is scarcest.
Why the correction was small and the consequences were not
The gap between the size of the change and the size of its effects is the part worth carrying away from this episode.
The corrected circuit differs from its predecessor by very little, because the defect was a missing constraint rather than a structural error. In terms of what the design was trying to express, almost nothing changed.
The verifying key changed completely, however, because it is derived from the circuit and any difference in the circuit produces a different key. That is what makes the two generations non-interchangeable: a proof constructed against one cannot verify against the other, regardless of how similar the underlying statements are.
That non-interchangeability is a property rather than a defect, and it is the property that makes the fix trustworthy. If proofs from the old circuit could still verify, the old defect would still be reachable. Because they cannot, the boundary between before and after is enforced by the mathematics rather than by anyone's diligence.
Frequently asked questions
What did NU6.2 actually change in the Zcash consensus rules?
Two things. It corrected the Orchard Action circuit's variable-base scalar multiplication gadget, which fixed a soundness vulnerability and changed the Orchard verifying key as a side effect. Separately, it made canonical proof length a consensus requirement, which it had not been before. A third item follows from the first: the temporary mitigation that had disabled Orchard stopped applying, so Orchard transactions became valid again under the corrected circuit.
Why can't old and new Orchard proofs verify under the same key?
Because correcting the circuit changes the verifying key derived from it. The specification states that pre-NU6.2 proofs verify only under the historical, insecure key and NU6.2-onward proofs only under the corrected one. The consequence is that a full node must retain both, since every historical Orchard transaction was proven against the original circuit and validating the chain from genesis requires verifying those proofs as they were originally made.
How large was the actual fix to the circuit?
Small, in a specific sense. The specification states that the two circuits differ only in additional copy constraints added to ensure soundness. Copy constraints assert that two parts of a computation carry the same value, so the repair restricted what a proof was permitted to claim rather than changing what was being computed. The statement being proven was never incorrect; the circuit proving it accepted a witness it should have rejected.
What is the canonical proof length rule?
A requirement, new at NU6.2, that an Orchard Action proof must have the canonical length for the corrected circuit. Before the upgrade this was not enforced by consensus, so a proof padded to a non-canonical length would still validate. The reference library treats the change as its own security issue with its own advisory, and the concern is transaction malleability: an unconstrained field is one an intermediary can alter.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources are the Zcash Improvement Proposals repository, the Zcash protocol specification, the project's own upgrade record, and the reference libraries' published changelogs. All facts independently verified against cited documentation current as of August 2026. what follows describes consensus rules and deliberately omits the incident narrative, which is covered separately.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Do your own research before making any decision.