The standard account runs roughly like this: Zcash adopted Halo 2, which removed the trusted setup and brought recursive proofs to the protocol. The first half is accurate. The second half is contradicted by the consensus specification that introduced it, in a sentence sitting directly beneath the one everybody quotes.
That discrepancy is worth more than a correction, because it illustrates how cleanly a proving system's headline property and its deployed use can come apart. What follows is what the consensus specification actually says, what the original research actually claimed, and which parts of the popular story survive contact with both of them.
What was replaced, and with what
Proving systems are not interchangeable components that slot into a fixed socket. Changing one changes the arithmetization, meaning the form a computation must be expressed in before it can be proved about, which in turn changes how circuits are written and what they cost.
The specification records the substitution in a single clause: Orchard "uses the Halo 2 proving system with the PLONKish arithmetization, instead of Groth16 and R1CS" (source: ZIP 224).
Four names appear there and each half of the sentence pairs a proving system with an arithmetization. Groth16 and R1CS were the outgoing pair, used by the earlier shielded pools. Halo 2 and PLONKish are the incoming pair.
The pairing matters because arithmetization is where the practical differences live. R1CS expresses a computation as rank-one constraints; PLONKish permits custom gates and lookup arguments, which lets a circuit designer express certain operations far more compactly than a constraint system that offers only one shape.
None of that is visible to somebody spending ZEC, and it is most of what an engineer means when they say the protocol changed proving systems. The user-facing consequence is narrower and is covered below.
It is worth registering how unusual a substitution of this size is in a live consensus protocol. A proving system sits underneath the circuits, the circuits sit underneath the transaction format, and the transaction format sits underneath every wallet. Replacing the bottom layer meant introducing a new pool rather than modifying an existing one, which is why the change arrived as a third shielded pool instead of as an upgrade to the second.
Why removing the setup was the headline
The property that made this transition worth performing at all had little to do with efficiency. It was the elimination of a procedure that had generated the protocol's most persistent external criticism for roughly half a decade, and whose removal could not be achieved by improving the procedure itself.
The company that developed the system put the claim directly: Halo 2 "eliminates the trusted setup, reducing the attack surface of the Zcash protocol and improving assurance about ZEC supply integrity" (source: Electric Coin Company).
Read that as three distinct claims rather than one. The setup requirement is gone for this circuit. The attack surface shrinks accordingly. And the specific assurance improved is about supply integrity, which is the correct scope, because the parameter risk was always a counterfeiting risk rather than a privacy risk.
Our guide to Zcash trusted setup covers what the removed procedure was, why it worried people, and why its elimination does not reach backwards into the circuits that still depend on it. The scope limitation is the part most worth carrying: removal applies to one pool's circuit and to nothing else.
The research this rests on is older than the deployment and states its own contribution more narrowly than the marketing did. Previous constructions of this kind "have required a trusted setup and cycles of expensive pairing-friendly elliptic curves"; the paper reports "the first practical example of recursive proof composition without a trusted setup, using the discrete log assumption over normal cycles of elliptic curves" (source: Bowe, Grigg and Hopwood).
Recursion, and the part summaries get wrong
Notice what the underlying paper is actually about. Its title is Recursive Proof Composition without a Trusted Setup, in which the setup removal is grammatically the qualifying phrase and recursion is the subject. The property Zcash is famous for adopting was, in the research, the secondary contribution.
Which makes the next sentence in the deployment specification genuinely surprising. Immediately after naming the proving system, ZIP 224 states: "This proposal does not make use of Halo 2's support for recursive proofs, but this is expected to be leveraged by future protocol updates" (source: ZIP 224).
The deployed Orchard protocol does not use recursion. It uses a proving system capable of it, in a deployment that declines to.
Recursion, at reader depth, means a proof that verifies another proof. Rather than checking a long chain of work directly, a verifier checks one proof asserting that the previous proof was valid, and that proof asserts the same about its own predecessor. The chain collapses into a constant-sized object regardless of length. Independent surveys of the field note that constructions of this kind "can be used to create succinct blockchains, reducing the burden on light clients" (source: ZKProof).
That is a description of a capability the protocol has acquired and not yet spent. The specification says as much in its own forward-looking clause, and what the project intends to do with it belongs to our guide to Zcash roadmap nu7 and ironwood rather than here.
For a reader, this hardens into a precision rule worth carrying well beyond Zcash. Adopting a system that supports a property is not the same as deploying that property, and specifications distinguish the two even when announcements do not.
What an Orchard proof actually covers
The circuit design changed alongside the proving system, and the shape it took is unusual enough that paraphrasing it loses the detail that matters. The specification's own description is compact, so quoting it directly costs three sentences and preserves the structure exactly as the designers stated it.
Orchard "uses a single circuit for both spends and outputs", where an action "contains both a single (possibly dummy) note being spent, and a single (possibly dummy) note being created", and a transaction contains "a 'bundle' of actions, and a single Halo 2 proof that covers all of the actions in the bundle" (source: ZIP 224).
Three consequences follow from that construction.
One circuit rather than two means a single set of constraints covers both directions of value movement, which reduces the surface a reviewer has to audit and the surface a defect can hide in.
The dummy provision means an action can spend nothing or create nothing while remaining structurally identical to one that does. An observer counting actions therefore learns less than an observer counting inputs and outputs on a transparent output model would, because the count no longer tells them how many real movements occurred.
And one proof per bundle rather than one per action means verification cost does not scale linearly with the number of value movements in a transaction. That property is why this family of systems underpins so much scaling work outside privacy entirely, as our explainers on why Ethereum needs layer 2 networks and how a zkEVM works describe.
Where the code lives, and what that lets you check
A proving system's security argument is a claim about mathematics, while its deployment is a claim about software. The two fail independently of each other, they have failed independently in this protocol's own history, and only one of them is checkable by somebody who is not a cryptographer.
The implementation is published as an open repository under the project's own organization (source: zcash/halo2), which means the specification's claims about what the deployed circuit does are auditable against the code rather than accepted on assertion.
That distinction is not academic for this protocol. Both counterfeiting vulnerabilities in its history were implementation defects rather than failures of the underlying cryptography, and both were found by people reading code and papers rather than by attackers exploiting them.
The consequence for how a reader should weigh claims about Halo 2 is direct. A proof that the mathematics is sound, however strong, says nothing about whether the circuit encoding it contains an error. Those are separate propositions with separate evidence, and a published implementation is what makes the second one arguable at all rather than a matter of trusting an announcement.
Our guide to Zcash safe covers what the protocol's actual defect record shows and, more usefully, what it does not.
The practice generalizes. Verifying that the software you run is the software that was audited is the same discipline as verifying a client download before executing it, and it belongs in the same routine as everything else on our security checklist. Neither habit requires understanding the cryptography, which is the point of both.
What stayed the same after Halo 2
A proving system replacement is a substantial engineering event with a narrow user-visible footprint, and being specific about the limits serves a reader better than restating the headline a fourth time. Four things stayed exactly as they were, and at least two of them are routinely reported as having changed.
It did not make the earlier pools setup-free. Their circuits are unchanged, their parameters remain in the consensus rules, and value sitting in them depends on exactly what it depended on before. Our guide to Zcash shielded pools covers which pool holds what, and the answer is the only one that determines whether any of this reaches a given holder.
It did not change what a shielded transaction hides. The specification's definition of the job has not moved. A proving system of this kind establishes a statement while leaking nothing about the private inputs beyond whatever the statement itself gives away (source: Zcash Protocol Specification), and that description applied exactly as well before the transition as after it. Our guide to How Zcash privacy works covers what is actually concealed.
It did not deliver recursion. The capability is present in the system and unused in the deployed protocol, on the specification's own statement.
And it did not eliminate implementation risk. Removing a class of parameter risk does not remove the possibility of a defect in a circuit, a library or a node, which is the risk class that has actually materialized in this protocol rather than the one that has been argued about. Our guide to Zcash safe covers that record, and the security properties of any layer built on validity proofs inherit the same distinction.
Why the setup requirement mattered so much
The property that was removed generated more discussion than any other aspect of the protocol for years, and the reason is worth stating because it explains why its removal was treated as a milestone rather than as an optimization.
A setup procedure produces parameters that a proving system needs, and it produces intermediate material that must be destroyed. Anyone retaining that material could construct proofs of false statements, which on a monetary system means creating value that does not exist without any observable trace on the chain.
The procedure was designed so that a single honest participant is sufficient: the material is only useful if every participant colluded or was compromised. That is a strong construction and it was executed with unusual care and documentation.
It is nonetheless an assumption about people rather than a property of mathematics, and that distinction is the whole of the objection. A system whose supply integrity rests on a historical event that cannot be re-verified is different in kind from one whose integrity rests on assumptions anyone can check today.
The objection also had a practical edge that gets less attention. Because a setup is per-circuit, changing a circuit meant repeating the ceremony, with all the coordination and scrutiny that involved. That made circuit changes expensive in a way that had nothing to do with cryptography, and removing the requirement removed that cost as well.
Both consequences arrived together, and the second turned out to matter operationally in a way nobody was emphasizing at the time.
It is worth being precise about what the removal does not establish, since this is where coverage of the subject tends to overreach. Eliminating a setup requirement removes one assumption from the system; it does not make the construction unconditionally sound, and it says nothing about whether the circuits expressed in it are correct. The 2026 defect demonstrated that distinction directly: the proving system behaved exactly as specified while the circuit it was proving statements about contained a missing constraint. Trust assumptions and implementation correctness are separate axes, and improving one leaves the other precisely where it was.
What the construction actually removed, and at what cost
Replacing a proving system is not a like-for-like substitution, and the trade involved is worth stating in both directions.
What it removed is the requirement for a per-circuit setup procedure whose participants had to be trusted to discard material. That requirement had been the most-discussed property of the earlier design for years, it constrained how easily circuits could be changed, and its removal is the headline result.
What it costs is proof size and, in some configurations, verification work. Constructions that eliminate a setup requirement generally pay for it somewhere, and here the payment appears in the size of the objects carried in each transaction and in the arithmetic a verifier performs. Both were judged acceptable against the property gained.
What changed structurally is the ease of amending circuits. Under the earlier design, changing a circuit meant a fresh setup procedure with all the coordination and scrutiny that involved. Without that requirement, a circuit correction becomes an engineering task rather than a ceremony, which is precisely why the 2026 correction could ship as quickly as it did.
That last point connects two subjects that are usually discussed separately. The value of removing the setup requirement was argued in terms of trust assumptions, and its largest practical payoff turned out to be operational: the ability to fix a circuit defect on a timescale measured in weeks.
How to check any claim about the proving system
Three checks, all available to any reader, none requiring cryptographic background.
Check whether the claim names the construction or gestures at a family. Statements about a family of constructions are usually true of some members and false of others, and the difference matters more here than the shared name suggests.
Check whether the claim concerns the setup requirement or the proof itself. Those are separate properties, and coverage of this subject conflates them routinely, usually in the direction of overstating what removal of a setup requirement achieves.
And check what version the claim is about. The proving system in use has been corrected since it was introduced, and a statement true of the original circuit may not be true of the current one. Our page on the 2026 correction covers what changed.
Frequently asked questions
What is Halo 2 in Zcash?
The proving system used by the Orchard shielded pool, replacing the Groth16 system used by the earlier pools. The consensus specification records that Orchard uses it with the PLONKish arithmetization instead of Groth16 and R1CS. Its defining property for Zcash is that it requires no trusted setup, which removes the parameter-generation risk that applied to the earlier circuits without removing it retroactively from them.
Does Zcash use recursive proofs?
Not in the deployed Orchard protocol. ZIP 224 states directly that the proposal does not make use of Halo 2's support for recursive proofs, while noting that future protocol updates are expected to use it. The proving system supports recursion and the current deployment declines to use it, which is a distinction most summaries of the transition collapse entirely. The capability has been acquired and not yet spent, and what the project intends to do with it is a separate question from what the protocol does today.
What is the difference between Halo 2 and Groth16?
Groth16 requires a trusted setup that generates circuit-specific parameters, and it pairs with the R1CS arithmetization. Halo 2 requires no such setup and pairs with PLONKish, which permits custom gates and lookup arguments. The practical effect for Zcash was removing a parameter-generation risk for one pool and changing how circuits for that pool are expressed. It did not remove that risk from the earlier pools, whose circuits and parameters are unchanged and remain in the consensus rules.
Did Halo 2 make Zcash more private?
No. It changed how validity is proved, not what is concealed. A shielded transaction hid its amounts and parties before the transition and hides them afterwards. The improvement was to supply-integrity assurance, meaning confidence that coins cannot be counterfeited, which is a different property from confidentiality and is frequently confused with it. Confidentiality protects the parties to a payment; supply integrity protects everybody holding the asset.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources are ZIP 224 (Final status), the original Halo paper by Bowe, Grigg and Hopwood, an Electric Coin Company technical explainer, the Halo 2 implementation repository, and a ZKProof survey. All facts independently verified against cited documentation current as of August 2026. what follows covers the proving system; the procedure it replaced, the pools that still depend on that procedure, and the project's forward plans belong to the articles that own them.