Trusted Setup Ceremonies: What Can Go Wrong
A zero-knowledge proof system lets one party convince another that a statement is true without revealing why it is true. That property is powerful enough to underpin private payments, identity systems, verifiable computation, and rollup validity proofs. But several of the most widely deployed ZK proof systems carry a hidden precondition: before a single proof can be generated, a setup phase must produce a piece of structured cryptographic material. If that material was produced honestly, the whole system works as advertised. If it was not, an attacker can forge proofs for statements that are entirely false — and no one, not the verifier, not the protocol, not any on-chain audit, will be able to tell.
This article examines the full lifecycle of a trusted setup ceremony: the cryptographic reasons it exists, the mechanics of the Powers of Tau construction, the multi-party computation model that distributes trust, the precise ways a compromise manifests, the distinction between circuit-specific and universal setups, and the practical checklist any protocol team should run through before committing to an existing ceremony’s output.
Why Some Proof Systems Require a Trusted Setup
The Role of a Common Reference String
Most practical ZK proof systems — particularly those targeting succinct, constant-size proofs — are defined in terms of a common reference string (CRS). The CRS is a structured set of group elements that both the prover and verifier use. It encodes the rules of the proving system in a form that makes proof generation efficient and proof verification cheap.
In systems based on bilinear pairings — the family that includes Groth16, PLONK, Marlin, and their descendants — the CRS must satisfy a specific algebraic structure. Concretely, it typically contains powers of some secret scalar τ (tau) evaluated inside an elliptic curve group: the elements [τ]G, [τ²]G, [τ³]G, and so on up to a degree sufficient to encode the largest circuit the system will support. Because elliptic curve discrete logarithm is hard, anyone who receives only the group elements cannot recover τ. But whoever generated τ knows it.
That secret scalar τ is called toxic waste. If any party retains it after the ceremony, they can use it to construct fake proofs.
The Soundness Argument
The security of a pairing-based SNARK reduces to a number of hardness assumptions — typically some variant of the Knowledge of Exponent assumption or the algebraic group model — combined with the assumption that τ is unknown to the prover. The moment τ is known, the prover can compute a valid-looking proof for any statement in the circuit’s language, regardless of whether a valid witness exists. The verifier’s equation still balances because the attacker has full control over the algebraic relationships.
This is not a theoretical edge case. It is a complete break of soundness. Every proof produced by such a system from that point forward must be treated as untrustworthy, because valid and forged proofs are computationally indistinguishable.
Why the Setup Cannot Simply Be Run by the Developer
A naive approach would be for the protocol team to generate τ themselves, publish the CRS, and promise to delete τ. This is the single-party trusted setup. It is essentially unusable in adversarial environments because it requires unconditional trust in a single entity. Users have no way to verify deletion, and regulators or attackers could compel disclosure. Any system built on a single-party setup is only as trustworthy as its creator.
The solution is multi-party computation.
The Powers of Tau Ceremony
Construction
The Powers of Tau ceremony is the canonical method for generating a structured reference string that requires trust in no single participant. It is named after the sequence of group elements it produces: [τ⁰]G₁, [τ¹]G₁, ..., [τⁿ]G₁ along with the corresponding elements in G₂ and the cross-terms needed for the proving system.
The ceremony proceeds as a sequential chain of contributions. A coordinator publishes an initial transcript — often seeded with the identity element or a verifiably random starting point. Each participant downloads the current transcript, samples their own secret scalar sᵢ, updates the transcript by raising all existing group elements to the power of sᵢ, and publishes the updated transcript along with a proof of correct computation. The ceremony’s final τ is the product of all individual secrets: τ = s₁ · s₂ · ... · sₙ.
No participant ever sees τ. Each participant only ever raises existing group elements to their own secret power. The composed result encodes [τ]G without any single party having computed τ directly.
The Proof of Correct Computation
Each contributor must convince subsequent participants — and ultimately the public — that they applied a consistent scalar throughout the transcript and did not tamper with existing entries. The standard technique is a proof of knowledge of exponent: the contributor publishes a new group element representing their scalar in a separate group, and a verifier can check via pairing equations that the ratio between consecutive transcript entries is consistent with a single applied scalar. This check can be performed by anyone who downloads the transcript at any point.
Entropy and Its Importance
The security of an individual contribution depends entirely on the secrecy and unpredictability of the contributor’s scalar. If sᵢ is guessable — because it was derived from a weak random number generator, a predictable seed, or a compromised machine — it is as if that participant did not contribute at all. For this reason, ceremony best practices require that participants generate entropy from multiple independent hardware and software sources, preferably on air-gapped machines that are destroyed or wiped after the contribution is complete. The ceremony tooling should incorporate verifiable randomness: dice rolls, atmospheric noise, radioactive decay timings, and similar physical sources have all been used in production ceremonies.
Multi-Party Computation and the 1-of-n Trust Model
The Core Security Guarantee
The Powers of Tau ceremony achieves a 1-of-n trust model: the final CRS is cryptographically sound as long as at least one participant in the entire ceremony honestly generated and deleted their secret scalar. If every single participant colluded or was compromised, the toxic waste could be reconstructed and the setup would be broken. But if even one participant acted honestly, τ remains secret.
This guarantee is asymmetric in a useful way. An attacker who wishes to compromise the ceremony must corrupt every single participant without exception. A defender only needs to ensure that one participant is honest. This means that as the number of contributors grows, the ceremony becomes progressively harder to attack.
Participant Diversity and Threat Modeling
A ceremony with a thousand participants is meaningfully more secure than one with five — not because the math changes, but because the attack surface for a global adversary grows proportionally. Effective ceremonies therefore seek diversity across multiple dimensions:
- Organizational affiliation: independent companies, academic institutions, anonymous individuals, and competing protocols
- Geographic distribution: participants across different legal jurisdictions reduce the impact of state-level coercion
- Technical environment: different operating systems, hardware architectures, and entropy sources reduce the impact of supply-chain attacks on any single platform
- Identity type: a mix of public figures (who accept reputational accountability) and anonymous contributors (who cannot be individually targeted) creates layered resilience
No single threat model justifies any of these dimensions in isolation. A ceremony designed only with anonymous contributors is resilient against coercion but harder to audit for liveness and correctness. One with only prominent public figures is highly auditable but potentially vulnerable to coordinated legal pressure.
Sequential vs. Concurrent Participation
The canonical Powers of Tau construction is sequential: participant N+1 cannot begin until participant N has published their contribution. This introduces practical latency — large ceremonies with hundreds of participants may take weeks to complete — but it preserves the simplest possible verification model. Concurrent participation protocols exist that allow multiple contributors to work in parallel, but they require more complex coordination and proof structures to maintain the same security guarantees.
What Happens When a Setup Is Compromised
Silent, Permanent, Undetectable Forgery
A compromised trusted setup does not degrade gracefully. There is no error message, no on-chain alert, no statistical anomaly in proof sizes. A prover who holds τ can produce a proof for any statement in the circuit’s relation in exactly the same time and with exactly the same format as a legitimate proof. The verifier’s check will pass. Smart contracts will accept the proof. Funds can be stolen, identity claims can be fabricated, and rollup state transitions can be falsified — all without any observable difference from legitimate usage.
This is the property that makes trusted setup security so critical compared to, say, a bug in a smart contract. A contract bug is typically observable after the fact, allows forensic reconstruction, and may be recoverable. A setup compromise is none of these things.
Attack Vectors
Malicious coordinator: In ceremonies with a central coordinator, the coordinator controls which participants are invited, in what order, and whether their contributions are included. A malicious coordinator could substitute their own contribution for a legitimate one, effectively running a single-party setup. Robust ceremonies minimize coordinator trust by publishing the full contribution chain so that any observer can verify that no entry was replaced.
Participant key compromise: If an attacker compromises a participant’s machine during the contribution window — before the participant’s scalar has been deleted — they can extract that scalar. Combined with the previous transcript state, this yields the composed τ up to that point. If the participant was the last contributor, the attacker has the full τ. This motivates the use of ephemeral, air-gapped hardware that is physically destroyed post-contribution.
Weak entropy at scale: If the random number generator used by every participant in a large ceremony has a shared flaw — a vulnerability in the system RNG, a compromised entropy pool seeded by a shared library — then all contributions may be effectively correlated, and the composed τ may be recoverable even without access to any individual machine.
Post-ceremony recovery: If a participant failed to delete their scalar but did not use it, the scalar remains a latent vulnerability. An attacker who later gains access to backups, cold storage, or decommissioned hardware could recover the scalar. This motivates explicit and verifiable destruction of ephemeral environments.
The Impossibility of Proof
If a compromise occurs, it may be practically impossible to prove. The attacker does not need to publish anything, alter any chain state, or leave any forensic trace prior to using the toxic waste. Detection would require either the attacker to make a mistake — generating a proof for a statement that is clearly false in a way that raises suspicion — or for an independent party to independently reconstruct τ and confirm it matches the known CRS. Neither is likely.
This is why the security argument for a trusted setup ceremony must be made prospectively, through transparency of process and diversity of participants, rather than retrospectively through anomaly detection.
Circuit-Specific vs. Universal Setups
Circuit-Specific Setups
Early pairing-based SNARKs — most notably Groth16 — require a two-phase setup. Phase 1 produces the Powers of Tau output, which is independent of any particular circuit. Phase 2 takes the Phase 1 output and performs a circuit-specific transformation that encodes the constraints of a particular program. Phase 2 also produces toxic waste, and it too must be run as a multi-party ceremony.
This means that every new circuit — every new version of a smart contract or verification program — requires its own ceremony. The Phase 1 output can be shared across all circuits (as long as it is large enough), but Phase 2 must be rerun for each circuit individually. For protocols that iterate rapidly or support a large number of distinct circuits, this is operationally expensive.
The security implication is symmetric: a compromised Phase 2 only affects the specific circuit for which it was run. An attacker who holds the Phase 2 toxic waste for circuit A cannot forge proofs for circuit B. This containment property is a silver lining of circuit-specificity.
Universal Setups
Proof systems designed around universal polynomial commitments — PLONK, Marlin, SONIC, and their descendants — require only a single Phase 1 ceremony whose output can be used for any circuit up to a given size. There is no circuit-specific Phase 2. Any new circuit can be deployed with only a transparent, public compilation step from the universal CRS.
This dramatically reduces operational overhead: run one large, diverse, well-publicized ceremony, and every circuit built on that proving system inherits its security. The Ethereum community’s Perpetual Powers of Tau initiative, for example, was designed explicitly as an ever-growing universal CRS that any project could use without running their own ceremony.
The security implication is also symmetric: a compromised universal CRS compromises every circuit and every proof built on it. The blast radius of a single setup failure is the entire ecosystem of applications that use it.
Choosing Between Them
The practical tradeoff is between proof efficiency and ceremony overhead. Groth16 proofs are typically smaller and faster to verify than PLONK-based proofs, which is why it remains widely used for high-throughput applications like payment circuits. But every application update requires a new Phase 2. PLONK-based systems sacrifice some proof efficiency for the operational convenience of a universal setup, which makes them attractive for systems that evolve frequently or support many diverse circuits.
Evaluating the Security of a Past Ceremony
What to Look For
When a protocol team is considering adopting an existing ceremony’s output — rather than running their own — they must evaluate several properties of the ceremony’s historical record.
Transcript completeness and public availability: The full contribution chain should be archived and publicly accessible. Each contribution should include the updated transcript and the proof of correct computation. If any portion of the chain is missing, redacted, or available only from the coordinator, the ceremony’s verifiability is weakened.
Verification tooling: There should be publicly available, independently implemented tools to verify the transcript. A ceremony that can only be verified using the coordinator’s own code has a single point of trust in the verification path.
Participant count and diversity: The team should assess both the raw number of contributors and their organizational and geographic diversity. A ceremony with fifty contributors from a single country and a single technical community is materially weaker than one with two hundred contributors drawn from across the global ecosystem.
Entropy documentation: Reputable ceremonies publish participant attestations describing the entropy sources they used. While these attestations are self-reported and unverifiable in the cryptographic sense, a culture of detailed public attestation makes it harder for a compromised participant to falsely claim correct procedure.
Coordination transparency: How was the ceremony coordinated? Was there a central server that could have silently dropped or substituted contributions? Were contribution windows enforced by the coordinator, or by cryptographic means? The more the ceremony’s integrity depends on coordinator honesty, the weaker the trust model.
Known incidents: Has any participant publicly disclosed that their machine was compromised? Has the coordinator flagged any contribution as anomalous or replaced? Any known incident should be treated as grounds for either further investigation or running a supplementary ceremony.
The Verification Process
Verifying a ceremony transcript is a concrete computation. A verifier downloads the full transcript, checks that each consecutive pair of entries satisfies the pairing consistency equation — confirming that the same scalar was applied throughout — and checks that the final output is consistent with the starting point. This computation can be parallelized and is practically feasible for any party with moderate computing resources.
Protocol teams should not outsource this verification to the ceremony coordinator or to the team that runs the proof system. Independent verification is the only meaningful verification.
Alternatives to Trusted Setups
Transparent Proof Systems
A transparent proof system is one whose CRS — if it has one at all — can be generated from publicly verifiable randomness. No toxic waste is produced because the structured reference string does not encode any secret. Anyone can verify that the CRS was generated correctly by rerunning the generation procedure.
The most common source of public randomness for transparent setups is a hash function applied to a public seed: a block hash, a publicly committed random beacon, or simply the string “nothing up my sleeve.” Because the generation is deterministic and public, no ceremony is required, no participants need to coordinate, and no trust is placed in any individual actor.
The tradeoff is in proof size and verifier complexity. Transparent proof systems typically produce larger proofs and require more computational work to verify than their pairing-based counterparts. For applications where verification cost is the primary constraint — like Ethereum mainnet, where calldata and gas costs are scarce — this tradeoff can be significant.
STARKs
Scalable Transparent ARguments of Knowledge (STARKs) are the most widely deployed transparent proof system. They rely on hash functions and error-correcting codes rather than elliptic curve pairings, which means they require no structured reference string at all. Their security assumptions reduce to the collision resistance of the hash function, which is a much more conservative and well-studied assumption than the algebraic assumptions underlying pairing-based systems.
STARKs produce proofs that are larger than Groth16 proofs — typically hundreds of kilobytes compared to a few hundred bytes — but the gap has narrowed considerably with recursive proof composition, proof compression, and specialized hash functions designed for STARK efficiency. Several production systems, including StarkWare’s StarkEx and StarkNet, are built entirely on STARKs and carry no trusted setup assumption at all.
The post-quantum dimension is also relevant: the hardness of elliptic curve discrete logarithm collapses under a sufficiently powerful quantum computer, which would invalidate all pairing-based proofs retroactively. Hash-based systems like STARKs are conjectured to be quantum-resistant, making them a more conservative long-term choice.
Lattice-Based and Other Post-Quantum SNARKs
Active research is exploring ZK proof systems built on lattice hardness assumptions, which are conjectured to resist quantum attacks. Some of these constructions are transparent; others require a setup but use post-quantum-hard parameters. These systems are not yet production-ready at the scale of pairing-based SNARKs, but they represent the long-term direction for applications where quantum resistance is a requirement.
Hybrid Approaches
Some systems use a universal CRS for the commitment scheme — which requires a ceremony — but combine it with a transparent argument for the polynomial evaluation step. The net result is that the ceremony covers only a small component of the overall security argument, reducing (though not eliminating) the trusted setup surface area.
What Protocol Teams Should Verify Before Using an Existing Setup
Building on an existing ceremony rather than running your own is common and often reasonable. The Powers of Tau output from large, well-run ceremonies is a genuine public good. But adoption is not free of responsibility. The following checklist represents the minimum due diligence for any team deploying a proof system that depends on a setup.
Identify exactly which ceremony your proving key derives from. Trace the Phase 1 output, and if applicable the Phase 2 output, back to the original ceremony transcript. Know the version, the date, and the coordinator.
Download and independently verify the ceremony transcript. Do not rely on the proving key supplier’s assertion that the transcript is valid. Run the verification yourself using independently implemented tooling. Document the result.
Assess the contribution count and diversity. Apply the criteria discussed above. If the ceremony had fewer than a few dozen contributors, or if the contributors are homogeneous in organization or geography, treat the setup as weaker and consider contributing to a supplementary ceremony or running your own.
Check for any disclosed compromises. Search for public disclosures by participants of key compromise, machine infection, or entropy failure. Check the coordinator’s historical communications for any anomaly reports.
Understand the threat model your application requires. If your protocol handles hundreds of millions of dollars in value, the standard for ceremony quality is higher than for a research prototype. The acceptable risk is a function of the consequences of a compromise.
Verify that the proving system version you use matches the ceremony parameters. Circuits compiled with updated constraint systems must not be used with a Phase 2 output from a different constraint system. This is a source of silent mismatch that can produce a nonfunctional or insecure setup even when the ceremony itself was run perfectly.
Have an incident response plan for setup compromise. Know in advance what your protocol will do if the ceremony is retroactively found to be compromised. This likely means a protocol upgrade with a new proving key, a migration of state, and communication to users. Teams that have not thought through this scenario will be unprepared to act quickly if the situation arises.
Consider running an additional Phase 2 ceremony for circuit-specific setups. Even if you adopt a shared Phase 1, running your own Phase 2 ceremony — even a small one — gives you a setup that no party outside your ceremony can compromise without corrupting at least one of your participants. For high-value circuits, this is almost always worth the operational cost.
Conclusion
The trusted setup ceremony is one of the more unusual requirements in applied cryptography: a one-time, high-stakes event whose outcome is permanently embedded in every proof generated by the system it serves. Unlike a software vulnerability that can be patched, a compromised setup cannot be corrected after the fact without replacing the entire proving infrastructure and migrating all dependent state.
Understanding what a ceremony actually guarantees — and what it does not — is not optional for teams building on pairing-based SNARKs. The 1-of-n model is powerful, but it is only as strong as the ceremony’s participant set and the integrity of the process that produced it. Transparent alternatives like STARKs eliminate this concern entirely at the cost of proof size; the right choice depends on the application’s constraints and threat model.
For teams that do adopt a ceremony-dependent system, the path to confidence is concrete: verify the transcript independently, evaluate participant diversity honestly, plan for compromise, and understand the full dependency chain from ceremony output to deployed circuit. The ceremony happened in the past and cannot be rerun. Due diligence, done now, is the only recourse.