Two things are usually asserted about the Zcash trusted setup, and they contradict each other. One is that it constituted an unacceptable backdoor at the foundation of the protocol. The other is that 6 participants in 2016 rendered the concern academic. Neither survives contact with the specification.
What the documentation actually describes is narrower, stranger and considerably more interesting than either summary: a specific cryptographic secret that, had it been reconstructed, would have permitted exactly one category of attack and no other, together with an elaborate physical procedure engineered to ensure that the secret was never assembled at all. The protocol's own designers have never claimed the procedure eliminated the risk.
What the parameters are, and why any had to be generated
The proving system underpinning the first two shielded pools does not operate on arbitrary inputs the way a general-purpose verifier might. It operates against one fixed circuit, and that circuit requires a set of public parameters generated in advance, before any transaction relying on it was ever constructed or validated.
The specification for the Orchard protocol states the constraint with unusual directness. The Sprout and Sapling circuits "are implemented using a proving system (Groth16) that requires a 'trusted setup': the circuit parameters are a Structured Reference String (SRS) with hidden structure, that if known could be used to create fake proofs and thus counterfeit funds" (source: ZIP 224).
Three separate claims are compressed into that sentence and each one matters independently.
The parameters have hidden structure. Rather than being arbitrary numbers. They are derived from secret values, and that derivation is what makes them work at all. This is structurally analogous to the relationship between a public and a private key in the key pairs securing an ordinary wallet, except that the private half was never meant to survive generation.
Knowing that hidden structure permits forged proofs. Not decryption of anyone's transactions, and not theft of anyone's funds. Forged proofs, which in a shielded system means counterfeit supply that the ledger cannot distinguish from the genuine article. Note how different that is from the failure modes catalogued in our guide to crypto privacy basics, none of which involve the ledger being lied to about its own supply.
And the parameters are per-circuit. Modify the circuit and the previous parameters become useless, which is why a second ceremony was required when the second pool arrived rather than the first ceremony's output being carried forward.
The toxic waste, and the precise harm it enables
The secret whose non-existence the entire exercise depends upon acquired a memorable name very early in the project's history, and that name has substantially outlived the specific risk it was coined to describe. Understanding what it actually denoted requires separating two capabilities that summaries habitually merge.
The company running the original ceremony was explicit about its scope. Should an attacker obtain the corresponding private key, "they could use it to create counterfeit Zcash. That is the only harm they could do with it, they could not violate anyone else's privacy nor steal other people's Zcash. We call the private key 'the toxic waste', and our protocol is designed to ensure that the toxic waste never comes into existence at all" (source: Electric Coin Company).
That scoping statement is the single most consequential fact on this subject, and it is routinely omitted from summaries in both directions. The people describing the setup as a backdoor into private transactions are describing a capability the toxic waste never conferred. The people describing the concern as hysteria are dismissing a genuine and undetectable counterfeiting vector.
Whether counterfeiting or surveillance is the more serious failure mode for a privacy chain, and how shielded supply can be audited at all, is a distinct question that our guide to Zcash does not have a backdoor takes on directly. Readers coming from Bitcoin will find the adjacent trade-offs in our guide to Bitcoin privacy basics. This article stays on the mechanism.
The phrasing in the last clause of the quotation is also worth registering precisely. The protocol was designed so the toxic waste would never exist, rather than being created and then destroyed. That distinction is the whole architecture of the ceremony.
How the 2016 ceremony was designed against it
If a single party generated the parameters. That party would necessarily hold the secret at some point, and every participant in the network would be trusting a deletion nobody could verify. The construction adopted instead distributes the secret so that no participant ever possesses it in full.
The implementation was published as "a multi-party computation protocol for the key-generation step of Pinocchio zkSNARKs, designed for use in the Zcash 'Sprout' public parameter ceremony" (source: zcash/mpc). Each participant contributes one shard and the composite parameters emerge from the combination.
The security property that arrangement buys is asymmetric in a way that favors the defender heavily. Reconstructing the toxic waste requires every single shard. Preventing its reconstruction requires only one participant to have deleted theirs honestly. A ceremony therefore fails only if all participants are compromised simultaneously, and succeeds if any one of them is not.
Around that mathematical core sat a set of physical safeguards. Each shard was computed on a machine bought new for the purpose and never connected to any network during its entire existence, with messages moved between machines through a separate networked node. The reasoning is the same reasoning behind air-gapped signing in ordinary custody practice, applied at considerably greater expense, and the underlying threat model is the one our comparison of wallet security models works through.
The proceedings were also recorded and archived, on the theory that evidence permitting later inspection is worth more than assurances issued at the time. That instinct, verifying rather than accepting, is the same one behind verifying software downloads before running them.
Six participants took part in that first ceremony.
The second ceremony, and why there was one
Because parameters are bound to one specific circuit, the arrival of the second shielded pool made generating an entirely new set unavoidable. What followed was a deliberate escalation rather than a repetition, since the organizers treated the participant count itself as the security parameter and set out to maximize it.
The foundation coordinating the effort described the result as "the largest multi-party computation (MPC) ceremony ever performed", concluded "after many months and many dozens of participants", and published the final parameters, the protocol transcript, a verification tool and a report of what took place (source: Zcash Foundation).
The specification quantifies the difference between the two: Zcash "had 6 participants in the Sprout MPC, and around 90 per round in the Sapling MPC two years later". Given that a single honest participant suffices, a fifteenfold increase in participants is a substantial change in the probability that at least one behaved correctly.
The same specification then declines to declare the problem solved, in the same paragraph: "it remains the case that generating these parameters is a point of risk within the protocol." That sentence appears in a Final-status consensus document authored by the protocol's own designers, which is a considerably stronger admission than anything a critic has published.
An unrelated defect in the original Sprout proving system was discovered later and is treated in our guide to Zcash does not have a backdoor. The flaw sat in the proving system rather than in the ceremony, and conflating the two produces a wrong account of both. It is worth keeping the distinction in view precisely because the two subjects share a vocabulary and a decade of argument.
Why Orchard retired the question
The eventual resolution arrived as a proving system requiring no ceremony whatsoever, rather than as a better-organized ceremony. That distinction determines what can honestly be claimed today, because a requirement removed by mathematics is categorically different from a requirement somebody has argued is acceptable.
Orchard, the third shielded pool, is built on a construction whose stated objective included "removing the trusted setup while hitting performance targets" (source: Zcash). No parameters with hidden structure are generated for that circuit, so there is no secret to distribute, no ceremony to run, and no toxic waste to fail to destroy. The specific proving system involved is our guide to Zcash halo2's subject. The same family of constructions now underpins scaling work far outside privacy, as our explainer on how a zkEVM works describes.
The precision required here is the difference between a risk being retired and a risk being argued away. The trusted setup requirement was eliminated for one pool by changing the mathematics underneath it. It was not eliminated for the earlier pools, whose parameters remain exactly what they were and whose circuits remain in the consensus rules.
This is also the correct framing for anyone weighing the concern today. Asking whether the ceremonies were adequate in the abstract produces an unanswerable argument. Asking which pool a given quantity of value currently occupies produces a factual answer, and our guide to Zcash shielded pools covers how to establish it.
The practical consequence is narrower than the historical debate suggests. Parameters generated in 2016 and 2018 remain in the consensus rules, they are used whenever value moves through the circuits they belong to, and no amount of subsequent engineering alters that. What changed is that a third option now exists which never depended on them.
What the ceremony leaves open
The strongest available defense of the trusted setup remains substantially weaker than most published claims about it imply, and the specific gaps are worth naming with precision rather than gestured at. Three of them are structural, and none has been closed by anything that has happened since.
It is a probabilistic argument, not a proof. The claim is that at least one of six people, or one of roughly ninety, deleted a value honestly. That claim cannot be verified from outside. It can only be made progressively less likely to be false by adding participants, which is exactly what the second ceremony did and exactly why it does not constitute a solution.
It does not apply retroactively. Orchard's independence from any setup does not reach backwards into the earlier circuits, which remain part of the protocol.
And alternatives existed the entire time. Constructions such as Bulletproofs and STARKs "do not require any trusted setup" at all (source: ZKProof), and Zcash's designers chose a system that did because the alternatives carried costs of their own in proof size or verification expense. The trusted setup was an engineering trade rather than an oversight, and describing it as either a scandal or a non-issue misstates what was actually decided.
What none of this establishes is that the ceremonies failed. No evidence has ever surfaced suggesting the toxic waste was assembled, and the design makes assembling it require universal compromise. The honest position is that the risk was never eliminated and was never observed to materialize, which is an uncomfortable place to leave an argument and also where the documentation leaves it.
What a multi-party ceremony actually achieves
The construction is worth stating carefully, because the security argument is stronger than most summaries convey and narrower than the objections assume.
Parameters are generated collaboratively rather than by any single party. Each participant contributes randomness, transforms the accumulated state, and destroys their own contribution. The final parameters depend on every contribution, and reconstructing the material that would enable forgery requires every participant's discarded input.
That produces the property the design rests on: a single honest participant is sufficient. If even one person genuinely destroyed their contribution, the material cannot be reassembled by anyone, regardless of what the others did. Security therefore does not require trusting the organizers, or a majority, or any identified individual.
Two things follow that are routinely conflated. The assumption is weak in the technical sense, meaning it requires very little to hold. And it is nonetheless an assumption about historical human behavior rather than a mathematical property, which means it cannot be verified after the fact by anyone.
The second point is the whole of the objection, and it is a fair one. A system whose supply integrity depends on an event that happened once and cannot be re-checked is different in kind from one whose integrity rests on assumptions any observer can evaluate today. Reasonable people weigh that differently, and both positions are coherent.
What is not defensible is either extreme: that the ceremony was a formality, or that it left a usable weakness. The first understates the engineering and the second overstates what a single honest participant leaves available.
Why it stopped mattering
The reason this subject moved from live controversy to history is worth stating, because it is a genuine engineering result rather than a change in opinion.
A later proving system removed the requirement entirely. Not by improving the ceremony, and not by arguing that the assumption was acceptable, but by constructing proofs that need no per-circuit setup at all. Once that shipped and the network moved onto it, the assumption stopped applying to anything newly created.
Two qualifications belong with that. The removal applies going forward rather than retroactively, so the historical parameters still govern whatever was created under them. And removing a setup requirement does not make the surrounding circuits correct, which the 2026 defect demonstrated directly on a proving system that had no setup requirement at all.
That last point is the useful one to carry away. Trust assumptions and implementation correctness are separate properties, they fail for different reasons, and improving one tells you nothing about the other.
How to evaluate a setup claim on any project
The pattern generalizes, and four questions separate a meaningful claim from a reassuring one on any system that uses a setup procedure.
Was the procedure multi-party, and how many participants were there? A single-party setup requires trusting one entity absolutely. A multi-party one requires only that one participant behaved, which is a categorically weaker assumption.
Was participation open, and is the participant list published? A ceremony whose participants are named and whose transcripts are archived can be scrutinized afterwards. One whose participants are unnamed cannot be assessed at all.
Is the procedure per-circuit or universal? A per-circuit setup has to be repeated whenever the circuit changes, which makes circuit corrections expensive and slow. A universal one is performed once for a family of circuits.
And is a setup required at all? Constructions exist that need none, and a project using one has removed the question rather than answering it.
Most projects answer the first two well and the third and fourth badly, which is where the useful scrutiny lives.
A final caution applies to reading any of it. The presence of a setup requirement is a fact about a construction rather than a verdict on a project, and a great deal of writing on this subject treats it as the latter. Systems with well-executed multi-party ceremonies have operated for years without incident, and systems without any setup requirement have shipped defects of their own. The requirement is one property among several, and weighing it correctly means holding it against the others rather than against nothing.
Frequently asked questions
What was the Zcash trusted setup?
A procedure that generated the public parameters for the Sprout and Sapling shielded circuits. The specification describes those parameters as a Structured Reference String with hidden structure, which if known could be used to create fake proofs and counterfeit funds. The procedure was designed as a multi-party computation so that no single participant ever held the complete secret, and so that one honest deletion was sufficient.
What is toxic waste in Zcash?
The name given to the secret value that would permit forged proofs if it were ever reconstructed. The company running the original ceremony stated that an attacker holding it could create counterfeit Zcash and that this was the only harm available to them, since it conferred no ability to violate anyone's privacy or steal anyone's funds. The protocol was designed so the value would never come into existence.
How many people took part in the Zcash ceremonies?
Six in the original Sprout ceremony in 2016. Around ninety per round in the Sapling ceremony two years afterwards, described by its coordinators as the largest multi-party computation ceremony performed at that time. Because a single honest participant is sufficient to make the hidden structure unrecoverable, the larger count represents a meaningful improvement rather than a cosmetic one. Both figures come from the Orchard specification, which states them while declining to describe the resulting risk as eliminated.
Does Zcash still require a trusted setup?
Not for Orchard, the third shielded pool, which uses a proving system built to remove the requirement. It does still apply to the earlier circuits, whose parameters were generated by the ceremonies and remain in the consensus rules. The requirement was retired for one pool by changing the underlying mathematics, which is a different thing from the concern having been dismissed.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources are ZIP 224 (Final status), the Electric Coin Company's own account of the ceremony's design, the Zcash multi-party computation repository, the Zcash Foundation's conclusion of the Powers of Tau ceremony, the Zcash project's zk-SNARK explainer, and a ZKProof survey of setup ceremonies. All facts independently verified against cited documentation current as of August 2026. what follows covers the ceremony and the parameter risk; the proving system that replaced the requirement, and the separate question of counterfeiting detection, belong to the articles that own them.