---
title: "Running or reusing a trusted setup"
description: "A trusted setup produces public parameters from secret randomness that must then be destroyed."
type: "section"
url: "https://zkpick.com/ceremony/"
section: "04 Running or reusing a trusted setup"
authors:
  - "MarketComp"
publisher: "MarketComp"
version: "1.3"
updated: "2026-09-12"
license: "CC-BY-4.0"
json: "https://zkpick.com/data/ceremony.json"
---

*By MarketComp. Updated 2026-09-12. Version 1.3. CC BY 4.0.*

## 04. Running or reusing a trusted setup

> A trusted setup produces public parameters from secret randomness that must then be destroyed. If any single participant in the ceremony honestly destroys the secret behind their contribution, the parameters are sound; if every participant colludes or is compromised, forged proofs become possible while remaining indistinguishable from honest ones. The first question is therefore not how to run a ceremony but whether you need one at all — and if you do, whether you can reuse an existing public one instead.

**Read this first** — Many teams run a ceremony they did not need. Hash-based systems require none at all, and universal-setup systems can almost always reuse a large existing public transcript rather than convening participants. A small, hastily organised ceremony is *worse* than reusing a public one with thousands of contributors: the security argument rests on the diversity and independence of participants, and a project-run ceremony rarely matches what an established public ceremony already achieved.

**The residual risk never reaches zero** — A ceremony reduces a trust assumption; it does not eliminate one. Users are trusting that at least one participant behaved honestly and that the ceremony software did what it claimed. State this plainly in user-facing documentation rather than describing parameters as "trustless". If that residual assumption is unacceptable for your threat model, the correct response is to change proof system, not to run a larger ceremony.

### Decision criteria

1. **Do you need a setup at all** — This is determined entirely by the proof system and commitment scheme chosen in §01, and it is the cheapest decision to get right because it can eliminate the whole workstream.
   - *How to evaluate:* Check the commitment scheme first: FRI and Merkle/hash-based commitments need no setup; KZG does. If a setup is unavoidable, establish whether it is universal and updatable or circuit-specific, because that determines whether you repeat this exercise every time the circuit changes.
2. **Reuse versus run your own** — Reusing an established public SRS inherits a participant set larger and more independent than almost any project can assemble, at a fraction of the cost and coordination risk.
   - *How to evaluate:* Confirm three things in order: that the transcript can serve your *scheme* — Groth16 needs a phase 1 carrying alpha- and beta-shifted powers, which a pure powers-of-tau/KZG transcript does not have; that the curve matches; and that the degree bound covers your largest expected circuit with headroom. Then verify the published transcript yourself rather than trusting the claim. If you must run phase 2 for a circuit-specific system, you can still build it on a reused phase 1.
3. **Participant set: size, independence and legibility** — Security rests on at least one honest participant. What matters is not the raw count but whether an outside observer can believe that no single party controlled enough of the set to collude.
   - *How to evaluate:* Recruit across organisations, jurisdictions and interests, including parties with no stake in your project. Publish who contributed and when. A hundred contributors who all work for you is a weaker argument than five who visibly do not.
4. **Contribution integrity and attestation** — A contribution that cannot be verified is indistinguishable from one that was never made, and an unverified transcript quietly turns a 1-of-N assumption into a 1-of-fewer assumption.
   - *How to evaluate:* Require each contribution to be publicly verifiable against the previous state, have participants sign an attestation naming their randomness source and destruction method, and run the verifier over the full chain — not just the final file — before publishing.
5. **Randomness sourcing** — The security of a contribution is exactly the unpredictability of the secret it used. Weak or recoverable randomness makes a contribution worthless without making it look any different.
   - *How to evaluate:* Prefer the operating system CSPRNG, optionally mixed with additional entropy. Treat exotic entropy theatre — lava lamps, dice on camera, radio static — as public communication, not as a security control, and never as the sole source. Ensure the secret is destroyed with the machine state, ideally on an air-gapped or ephemeral machine.
6. **Transcript publication and independent verifiability** — A ceremony's value is the ability of a sceptical third party to check it years later. If the artefacts or instructions disappear, the security argument becomes an appeal to authority.
   - *How to evaluate:* Publish the full transcript, the verification tool, the exact commands to reproduce the check, and the hashes of every intermediate file, in durable locations under more than one party's control. Assume the person checking has no relationship with you.
7. **Final beacon** — Applying a public, unpredictable random value after the last contribution removes the possibility that the final participant chose their contribution adaptively to bias the result. It is a recommended control rather than a proven requirement: later analyses (Maller's generic-group proof for the Sapling MPC, and the Snarky Ceremonies analysis of Groth16 setups) show security holds without it, so treat it as defence in depth against a flaw in those analyses' assumptions, not as the thing that makes the ceremony sound.
   - *How to evaluate:* Use a beacon whose value was unknowable at ceremony time and is verifiable afterwards, publish the exact beacon value and how it was derived, and commit to the choice of beacon *before* it is known.
8. **Operational and communication plan** — Ceremonies are logistics exercises. Most failures are dropped participants, ambiguous instructions and unclear deadlines, not cryptography.
   - *How to evaluate:* Decide coordinator-driven versus queue-based participation, budget for participants who start and never finish, rehearse end to end on a small circuit, and write the user-facing explanation of the trust assumption before the ceremony rather than after.

### Reusable public setups

| Ceremony | Curve | Size / degree bound | Contributions | Usable for | Run | Adoption caveat |
| --- | --- | --- | --- | --- | --- | --- |
| Perpetual Powers of Tau | BN254 | up to 2^28 | 80+ recorded | Groth16 and PLONK-family | 2019 – 2024; repository archived Aug 2026 | No longer accepting contributions: the coordinating repository was archived read-only in August 2026, so treat it as a frozen artefact. The chain forked after contribution 0058; "we used PPOT" is ambiguous without naming a branch and index. Prepared .ptau files are published per power, so most projects download only what they need. |
| Hermez powers of tau (powersOfTau28_hez) | BN254 | 2^28 | PPOT contributions 1–54 plus a beacon | Groth16 and PLONK-family | 2020 | The artefact most Circom and snarkjs projects actually download: the first 54 Perpetual Powers of Tau contributions sealed with a beacon and prepared per power. Cite it as this branch, not as "PPOT", and verify the published Blake2b hashes of the file you use. |
| Filecoin powers of tau | BLS12-381 | 2^27 | 19 | Groth16 and PLONK-family | 2019 – 2020 | The only large reusable BLS12-381 phase 1 that carries the alpha- and beta-shifted powers Groth16 needs, sized for circuits of roughly 100 million constraints. A small participant set by today's standards, but named, attested and independently verifiable; it backed one of the largest Groth16 deployments in production. |
| Ethereum KZG ceremony | BLS12-381 | 2^12 – 2^15 G1, 65 G2 | 141,416 | KZG only — **not** Groth16 | 13 Jan – 8 Aug 2023 | By far the largest participant set, but sized for EIP-4844 blob commitments: it cannot back a PLONK circuit above its degree bound, and cannot back a Groth16 circuit *at any size*, because the transcript contains no alpha/beta-shifted powers. Audited before the run; more than ten independent client implementations exist. |
| Aztec Ignition | BN254 | ~100.8M G1 points | ~176 | KZG only — **not** Groth16 | 2019 – Jan 2020 | The largest KZG-only BN254 ceremony by participant count (Perpetual Powers of Tau is larger by degree bound), and reused by independent systems — though reuse reflects that availability rather than independent scrutiny. Custom binary transcript format needs a converter; an independent verification repository and a transcript specification are published. Verify what you can obtain before depending on it. |
| Zcash Sapling powers of tau | BLS12-381 | 2^21 | 88 entries | Groth16 and PLONK-family | Nov 2017 – early 2018 | The reference implementation of the two-phase design later ceremonies imitate, with unusually thorough operational-security documentation. Too small for most modern circuits; a historical record, not an ongoing ceremony. |
| Tornado Cash phase 2 | BN254 | Circuit-specific | 1,114 | Reference only — not reusable parameters | May 2020 | Not reusable parameters — a precedent for an open, browser-based phase 2 with a large anonymous contributor set (450 identified, 664 anonymous), built on Perpetual Powers of Tau contribution 30. The published participant list, artefact archive and generated verifier are the model later phase-2 platforms automated. |
| Penumbra summoning ceremony | BLS12-377 | Circuit-specific | 15,000+ in phase 1 | Reference only — not reusable parameters | 2023 | Not reusable parameters — a decentralised phase 2 run through the chain's own wallet software, with contribution slots allocated by bid rather than by a coordinator's queue. The precedent to study if you want a large, permissionless circuit-specific ceremony without a hosted platform. |
| Filecoin phase-2 attestations | BLS12-381 | Circuit-specific, very large | ~12–19 per circuit set | Reference only — not reusable parameters | 2020, 2021–22 | Not reusable parameters — a worked precedent for running phase 2 on very large circuits, with a clean separation of hash chain from signed attestations, and artefacts still reachable years later. |

***Check the "usable for" column before the size column.** Groth16's SRS contains alpha- and beta-shifted powers that a pure powers-of-tau/KZG transcript does not, so a KZG-only ceremony cannot back a Groth16 circuit at any size — this is the mistake most likely to cost a team a month. After that, match the curve, then the degree bound against the largest circuit you expect to need rather than the one you have today. Contribution counts are a weak proxy for independence: many contributions from linked parties are not stronger than fewer genuinely independent ones. Whatever you adopt, verify the transcript yourself and publish the hashes you verified.*

### Options

#### Avoid the setup entirely: transparent proof systems — *Avoidance strategy*

> Avoid the setup entirely: transparent proof systems: Avoidance strategy. Choose a proof system with a public-coin setup so there is no trapdoor to protect: FRI/STARK-based systems, Bulletproofs, Halo2 with IPA, and hash- or Pedersen-based multilinear commitments. Maturity: Production-used at scale. Maintained by: See the transparent families in §01: StarkWare, Polygon, RISC Zero, Succinct, Zcash and others ship transparent provers. Choose it when: Systems verifying off-chain, or on a chain tolerant of larger proofs, and any team for whom parameter lifecycle risk outweighs proof size.

Choose a proof system with a public-coin setup so there is no trapdoor to protect: FRI/STARK-based systems, Bulletproofs, Halo2 with IPA, and hash- or Pedersen-based multilinear commitments. This is the option most teams should evaluate first, because it removes the workstream rather than managing it.

**Strengths**

- Eliminates the entire class of ceremony risks, including the ones that have actually caused losses
- No parameter lifecycle burden when circuits change, and no artefact-persistence obligation
- Plausibly post-quantum for hash-based variants, unlike pairing-based SRS systems

**Tradeoffs**

- Larger proofs and higher verification cost: no transparent scheme in deployment matches a pairing-based SNARK's proof size and verifier cost, and the gap is what pays for the missing trapdoor
- On-chain verification cost often forces a final wrap in Groth16 or PLONK — which reinstates a trusted setup for the wrapper circuit
- Public parameters must still be generated from auditable nothing-up-my-sleeve seeds; 'transparent' is not 'no parameters'

**Choose it when:** Systems verifying off-chain, or on a chain tolerant of larger proofs, and any team for whom parameter lifecycle risk outweighs proof size.

Maintained by: See the transparent families in §01: StarkWare, Polygon, RISC Zero, Succinct, Zcash and others ship transparent provers · Maturity: Production-used at scale · License: Varies by implementation · Source: https://eprint.iacr.org/2025/064

Full page: https://zkpick.com/ceremony/transparent-proof-systems/

#### snarkjs (powersoftau + zkey) — *Phase 1 and phase 2 tooling*

> snarkjs (powersoftau + zkey): Phase 1 and phase 2 tooling. The de facto toolchain for Circom-based Groth16 and PLONK projects, covering both the universal phase and the circuit-specific phase, on BN254 and BLS12-381. Maturity: Production-used, actively maintained. Maintained by: iden3 (Polygon ID lineage), open source. Choose it when: Circom-based Groth16 and PLONK teams, and anyone consuming .ptau artefacts from Perpetual Powers of Tau.

The de facto toolchain for Circom-based Groth16 and PLONK projects, covering both the universal phase and the circuit-specific phase, on BN254 and BLS12-381. `powersoftau verify` validates the full chain of embedded public keys, not merely hash continuity.

**Strengths**

- Widest ecosystem support and the largest body of published ceremony instructions written against it
- Verification checks the cryptographic contribution chain, not just file hashes
- Runs in Node and in browsers, lowering the barrier for independent contributors
- Consumes widely mirrored .ptau artefacts directly, so phase-1 reuse is a download

**Tradeoffs**

- JavaScript/WASM performance and memory limits make very large powers awkward
- The non-interactive entropy flag is a footgun: a literal string in a CI script produces a contribution with effectively no secret
- Correct usage is a process, not a command — nothing prevents shipping a key with zero phase-2 contributions

**Choose it when:** Circom-based Groth16 and PLONK teams, and anyone consuming .ptau artefacts from Perpetual Powers of Tau.

Maintained by: iden3 (Polygon ID lineage), open source · Maturity: Production-used, actively maintained · License: GPL-3.0 · Source: https://github.com/iden3/snarkjs

Full page: https://zkpick.com/ceremony/snarkjs/

#### gnark mpcsetup — *Phase 1 and phase 2 tooling*

> gnark mpcsetup: Phase 1 and phase 2 tooling. Go implementation of the two-phase Groth16 MPC setup inside the gnark proving library, exposing contribution, verification and sealing as ordinary library calls. Maturity: Maintained; smaller ceremony track record. Maintained by: Consensys (gnark team). Choose it when: Teams whose circuits are written in gnark and who want the ceremony in the same toolchain as the prover.

Go implementation of the two-phase Groth16 MPC setup inside the gnark proving library, exposing contribution, verification and sealing as ordinary library calls. Phase 2 initialises from a phase-1 file plus the circuit's constraint system.

**Strengths**

- Native to a Go proving stack, avoiding cross-language artefact conversion
- Ceremony automation and per-contribution verification are straightforward to script
- Part of an actively maintained general proving library rather than a single-purpose script

**Tradeoffs**

- Far fewer public ceremonies have been run with it, so less community-tested operational guidance
- Interoperating with snarkjs .ptau files requires a converter
- BN254-focused; check curve coverage before assuming parity with snarkjs

**Choose it when:** Teams whose circuits are written in gnark and who want the ceremony in the same toolchain as the prover.

Maintained by: Consensys (gnark team) · Maturity: Maintained; smaller ceremony track record · License: Apache-2.0 · Source: https://pkg.go.dev/github.com/consensys/gnark/backend/groth16/bn254/mpcsetup

Full page: https://zkpick.com/ceremony/gnark-mpcsetup/

#### Coordinated phase-2 ceremony platforms — *Coordinated ceremony platform*

> Coordinated phase-2 ceremony platforms: Coordinated ceremony platform. Coordinator-run platforms that automate queueing, timeouts, per-contribution verification and attestation publication across multiple circuits at once, with browser and CLI contribution. Maturity: Production-used, maintenance mode. Maintained by: Ethereum Foundation Privacy & Scaling Explorations (p0tion, DefinitelySetup); maintenance mode. Choose it when: Teams needing an open, browser-accessible phase-2 ceremony with many contributors, who do not want to build queueing and attestation plumbing themselves.

Coordinator-run platforms that automate queueing, timeouts, per-contribution verification and attestation publication across multiple circuits at once, with browser and CLI contribution. **The leading open platform states it is no longer actively developed**, which is the most decision-relevant fact here: adopting it means owning it. Third-party coordination does buy something real — it constrains the project's ability to manipulate the ceremony *software* — but not its control of the circuit, the phase-1 artefact chosen, or the deployed verifying key.

**Strengths**

- Removes most of the coordination work, which is where ceremonies usually fail
- Real production track record across multiple independent projects
- Per-contribution verification and timeouts are enforced by the platform, so a stalled or malformed contribution cannot silently block or weaken the chain
- Attestations published automatically rather than collected by hand

**Tradeoffs**

- The leading open platform is explicitly in maintenance mode — plan for self-hosting and self-maintenance
- Requires billed cloud infrastructure, so the coordinator carries real cost and operational obligations
- Cloud-hosted coordination concentrates liveness and censorship risk in one operator
- Phase 2 only; not a phase-1 solution

**Choose it when:** Teams needing an open, browser-accessible phase-2 ceremony with many contributors, who do not want to build queueing and attestation plumbing themselves.

Maintained by: Ethereum Foundation Privacy & Scaling Explorations (p0tion, DefinitelySetup); maintenance mode · Maturity: Production-used, maintenance mode · License: MIT · Source: https://github.com/privacy-ethereum/p0tion

Full page: https://zkpick.com/ceremony/phase-2-platforms/

#### Sequencer-mediated large public ceremony — *Ceremony design pattern*

> Sequencer-mediated large public ceremony: Ceremony design pattern. The architecture behind the largest ceremony run to date: a published specification plus a sequencer that authenticates participants, serves state over an API, verifies contributions and appends them. Maturity: Completed and published; not maintained. Maintained by: Ethereum Foundation (KZG ceremony specification and sequencer). Choose it when: Organisations designing a large, public, browser-based ceremony who want a battle-tested reference architecture and verification-client model.

The architecture behind the largest ceremony run to date: a published specification plus a sequencer that authenticates participants, serves state over an API, verifies contributions and appends them. More than ten independent client implementations were produced against the specification.

**Strengths**

- Demonstrated at a scale no other setup has reached
- Independent client implementations directly mitigate correlated implementation bugs
- Two independent audits before the run — of the specification and of the sequencer
- The specification is openly licensed, so the design can be reused without friction

**Tradeoffs**

- Heavy: a sequencer, anti-sybil authentication, a frontend and months of coordination
- The sequencer is a central coordinator with censorship and liveness power
- The published spec is tailored to one SRS shape, not a general-purpose framework
- Frozen reference rather than maintained software

**Choose it when:** Organisations designing a large, public, browser-based ceremony who want a battle-tested reference architecture and verification-client model.

Maintained by: Ethereum Foundation (KZG ceremony specification and sequencer) · Maturity: Completed and published; not maintained · License: CC0-1.0 (specification) · Source: https://github.com/ethereum/kzg-ceremony

Full page: https://zkpick.com/ceremony/sequencer-ceremony/

#### Coordinatorless and on-chain ceremonies — *Ceremony design (research)*

> Coordinatorless and on-chain ceremonies: Ceremony design (research). Protocols that remove the central coordinator by running contribution and verification through a smart contract or consensus layer, making eligibility and ordering publicly auditable by construction. Maturity: Research with prototypes. Maintained by: Academic authors (Powers-of-Tau to the People; a16z crypto research on-chain ceremony prototype). Choose it when: Projects where censorship-resistance of the ceremony itself is a stated requirement, or teams assessing where the field is heading.

Protocols that remove the central coordinator by running contribution and verification through a smart contract or consensus layer, making eligibility and ordering publicly auditable by construction.

**Strengths**

- Removes coordinator censorship and single-point liveness failure — a property no surveyed production ceremony satisfies
- Contribution eligibility and ordering become publicly auditable
- Opens the door to explicit incentives for honest participation

**Tradeoffs**

- Gas and data-availability costs scale with SRS size; large SRSs remain impractical fully on-chain
- Still synchronous and round-robin; fully asynchronous ceremonies remain an open problem
- Limited deployment track record — treat as research-grade for now

**Choose it when:** Projects where censorship-resistance of the ceremony itself is a stated requirement, or teams assessing where the field is heading.

Maintained by: Academic authors (Powers-of-Tau to the People; a16z crypto research on-chain ceremony prototype) · Maturity: Research with prototypes · License: Academic; see reference implementations · Source: https://eprint.iacr.org/2022/1592

Full page: https://zkpick.com/ceremony/coordinatorless-ceremonies/

### Process

1. **Confirm the requirement** — Re-read the proof system decision from §01 and write down precisely what the setup is for: which scheme, which curve, which degree bound, universal or circuit-specific. If the answer is "none", stop here and record why, so the question is not reopened later.
2. **Search for a reusable SRS before planning anything** — Identify existing public ceremonies that serve your scheme, on your curve, at sufficient degree — in that order, because a KZG-only transcript cannot back Groth16 however large it is. Reuse is the default; running your own phase 1 needs a written justification that survives scrutiny.
3. **Verify the transcript you intend to inherit** — Download the full transcript and run the verification yourself, end to end, on your own hardware. Record the hashes you verified and publish them. Inheriting a ceremony means inheriting the obligation to have checked it.
4. **Freeze the circuit before any circuit-specific phase** — For circuit-specific setups, the constraint system must be final. Any later change — including one made in response to an audit finding — invalidates the output and forces a repeat. Sequence the audit before the ceremony, not after.
5. **Design the participant set and publish the rules in advance** — Name the eligibility criteria, the ordering, the deadlines, the beacon you will use, and what will be published about each contributor. Publishing the rules before the ceremony is what makes the result auditable rather than merely asserted.
6. **Rehearse the whole pipeline** — Run the ceremony against a small circuit with volunteer participants, including verification and publication. Rehearsal is where you discover that the instructions are ambiguous, the upload times out, or the verifier does not build on a common platform.
7. **Run the ceremony, verifying continuously** — Verify every contribution as it arrives rather than at the end, so a bad contribution is caught while the participant is still reachable. Keep an append-only public log of contributions and hashes as they land.
8. **Apply and publish the beacon** — Apply the pre-committed beacon, publish its value and derivation, and run the full-chain verification once more over the finalised transcript.
9. **Publish artefacts, instructions and the trust statement** — Release the parameters, the complete transcript, the verification tooling with reproducible commands, the participant attestations, and a plain-language statement of exactly what users are trusting. Mirror everything somewhere you do not control.
10. **Bind the parameters to the deployed system** — Pin the hash of the verifying key in the on-chain verifier and in the client, and add a test that fails if the deployed parameters ever differ from the ceremony output. For a circuit-specific setup, add two more assertions to the same test: the phase-2 contribution count is greater than zero, and the verifying key's gamma and delta elements are not equal to each other or to the G2 generator. A key produced straight from phase-2 initialisation passes every other check and is trivially forgeable. This is what stops the ceremony from being quietly bypassed later.

### Failure modes

- **Phase 2 never run: shipping the initial zkey** — The circuit-specific phase is initialised from a phase-1 file and the resulting key is deployed without a single phase-2 contribution. In that state the verifying key's gamma and delta are both the G2 generator rather than independent secrets, and a prover can cancel the corresponding terms of the verification equation and forge a proof for any statement without a witness. Every other control — a reputable phase 1, a verified transcript, an audited circuit — is satisfied, and the system is still unsound. This is the only setup failure that has produced real losses: in late February 2026 two deployed protocols were drained through exactly this gap, roughly $1.4 million from one and a few thousand dollars from the other, within a week of each other.
  - *Mitigation:* Treat phase 2 as mandatory for any circuit-specific setup, even a single contribution by the team. Assert in CI and in the deployment checklist that the contribution count is non-zero and that gamma and delta differ from the generator and from each other. Auditors reviewing a Groth16 verifier should check the deployed key for this condition explicitly.
  - Full page: https://zkpick.com/ceremony/failure-modes/phase-2-never-run-shipping-the-initial-zkey/
- **Forgetting that a universal SRS is updatable by you** — A public universal SRS is adopted as a fixed artefact, when its defining property is that anyone may re-randomise it. A team that contributes nothing is trusting that at least one of the *existing* participants was honest; a team that adds one contribution of its own puts itself inside the 1-of-N set, which is cheap and materially strengthens the claim it can make to its users.
  - *Mitigation:* Consider adding your own contribution on top of the adopted SRS. Weigh it against the cost: an updated SRS is no longer byte-identical to the widely mirrored artefact, so you take on publishing and verification duties that reuse would otherwise have avoided.
  - Full page: https://zkpick.com/ceremony/failure-modes/forgetting-that-a-universal-srs-is-updatable-by-you/
- **Adopting a transcript that cannot serve your scheme** — A large, reputable ceremony is adopted on the strength of its participant count, and only later does the team discover the transcript cannot back their proof system at all — most commonly, a Groth16 project reaching for a pure powers-of-tau/KZG SRS that carries no alpha- or beta-shifted powers.
  - *Mitigation:* Check scheme compatibility before curve and before size. Run your toolchain's phase-2 initialisation against the candidate artefact as the very first step, not after the ceremony has been planned.
  - Full page: https://zkpick.com/ceremony/failure-modes/adopting-a-transcript-that-cannot-serve-your-scheme/
- **Running a ceremony you did not need** — Substantial cost, schedule risk and a permanent trust assumption are taken on because the proof system was chosen without regard to its setup requirement, or because a ceremony was assumed to be a prerequisite for credibility.
  - *Mitigation:* Settle the setup question as part of §01, not afterwards. If a setup-free system meets the constraints, the entire workstream and its residual risk disappear.
  - Full page: https://zkpick.com/ceremony/failure-modes/running-a-ceremony-you-did-not-need/
- **Toxic waste that is never actually destroyed** — Contributions are generated on a laptop that is backed up, on a cloud VM whose memory is snapshotted, or in a process whose secret is swapped to disk. The participant sincerely believes the secret is gone.
  - *Mitigation:* Provide tooling and written procedure: ephemeral or air-gapped machines, no swap, no backups, secure erase or destruction of the medium. Have participants attest to what they actually did, not to what was recommended.
  - Full page: https://zkpick.com/ceremony/failure-modes/toxic-waste-that-is-never-actually-destroyed/
- **Unverified contributions in the chain** — The final parameters verify, but individual contributions were never checked against their predecessors. A contribution that was malformed or replayed silently reduces the honest-participant count.
  - *Mitigation:* Verify each contribution on receipt and re-verify the full chain before publication. Publish the verification output alongside the transcript.
  - Full page: https://zkpick.com/ceremony/failure-modes/unverified-contributions-in-the-chain/
- **A participant set that cannot bear scrutiny** — Contributors are all employees, investors or close partners of the project. The 1-of-N assumption is formally satisfied and practically worthless, because a single organisation could have controlled every contribution.
  - *Mitigation:* Recruit adversarially: parties with no stake, competitors, independent researchers, other jurisdictions. Publish affiliations so readers can judge independence for themselves.
  - Full page: https://zkpick.com/ceremony/failure-modes/a-participant-set-that-cannot-bear-scrutiny/
- **Circuit changes after the ceremony** — An audit finding, a feature request or a bug fix changes the constraint system after a circuit-specific setup has completed, invalidating the parameters. Under schedule pressure the change ships against stale parameters, or the ceremony is repeated in a rush with whoever is available.
  - *Mitigation:* Freeze the circuit and complete the audit before the circuit-specific phase. If a change is unavoidable, repeat the phase properly and treat the timeline slip as the cost of the design choice — or move to a universal setup so this class of event stops being fatal.
  - Full page: https://zkpick.com/ceremony/failure-modes/circuit-changes-after-the-ceremony/
- **A transparent system that quietly reintroduces a setup** — The team selects a setup-free proving system and announces that no trusted setup is needed — and then, to make on-chain verification affordable, wraps the final proof in a pairing-based SNARK. That wrapper circuit has its own trusted setup, so the system does depend on one after all, often on parameters inherited from a ceremony nobody on the team examined.
  - *Mitigation:* Trace the trust assumption all the way to what the chain actually verifies. If a wrapper is used, its parameters are in scope: name their provenance, verify that transcript, and describe the assumption in user-facing documentation rather than claiming the system is setup-free.
  - Full page: https://zkpick.com/ceremony/failure-modes/a-transparent-system-that-quietly-reintroduces-a-setup/
- **Citing a ceremony without naming the branch and index** — Long-running ceremonies can fork: a contribution chain splits and only one branch is continued, so "we used the public powers of tau" does not identify which parameters were adopted. Artefacts derived from a discontinued branch may not be compatible with those from the live one, and the claim cannot be independently checked.
  - *Mitigation:* Record the exact ceremony, branch, contribution index, file and hash you adopted, publish them, and verify that specific chain yourself rather than relying on the ceremony's overall reputation.
  - Full page: https://zkpick.com/ceremony/failure-modes/citing-a-ceremony-without-naming-the-branch-and-index/
- **Using an SRS with the wrong curve or degree** — Parameters are taken from a well-known ceremony that does not match the deployed curve, or whose degree bound is below the circuit size, and the mismatch is discovered late or papered over by shrinking the circuit.
  - *Mitigation:* Check curve and degree against the largest circuit you expect to need, not the current one, and add an automated check that the loaded SRS matches the expected identity and size at build time.
  - Full page: https://zkpick.com/ceremony/failure-modes/using-an-srs-with-the-wrong-curve-or-degree/
- **The transcript becomes unavailable** — Artefacts live in one repository, one bucket or one company's infrastructure. Years later the links are dead, the verification tool no longer builds, and no one can independently confirm the ceremony happened as described.
  - *Mitigation:* Mirror artefacts across independent parties and archival services, pin content hashes in the published documentation, and keep the verifier buildable with pinned dependencies.
  - Full page: https://zkpick.com/ceremony/failure-modes/the-transcript-becomes-unavailable/
- **A correctly run ceremony for an unsound setup protocol** — Every operational control works — diverse participants, verified contributions, published transcript, beacon — and the parameters are still unsound, because the setup *protocol* published an element it should not have. This has happened: a flaw in an early pairing-based construction's parameter generation allowed unlimited undetectable counterfeiting and went unnoticed for years. No amount of ceremony hygiene addresses it.
  - *Mitigation:* Have the setup construction itself reviewed as cryptography, separately from the ceremony's operation — see [§03](https://zkpick.com/audit/). Prefer constructions with multiple independent implementations and published security proofs over bespoke or modified parameter generation.
  - Full page: https://zkpick.com/ceremony/failure-modes/a-correctly-run-ceremony-for-an-unsound-setup-protocol/
- **Ceremony as security theatre** — The ceremony is run and marketed as proof of trustworthiness while the real risks — an underconstrained circuit, an unaudited verifier, a privileged upgrade key — go unaddressed. Attention is spent where it buys the least security.
  - *Mitigation:* Rank the ceremony against the other risks in the system honestly. For most deployments the circuit and the verifier are far likelier failure points than the setup, and should receive proportionally more budget.
  - Full page: https://zkpick.com/ceremony/failure-modes/ceremony-as-security-theatre/
- **Entropy theatre presented as a security control** — An unusual randomness source is used and publicised in place of a vetted CSPRNG, sometimes with no independent check that it produced high-quality, unpredictable, unrecoverable bits.
  - *Mitigation:* Use the platform CSPRNG as the primary source. Additional entropy may be mixed in, and may be filmed for communication purposes, but the security argument must not depend on it.
  - Full page: https://zkpick.com/ceremony/failure-modes/entropy-theatre-presented-as-a-security-control/
- **Deployed parameters that do not match the ceremony output** — The verifying key deployed on-chain or shipped to clients differs from the ceremony result because of a rebuild, a manual copy, or a toolchain version change — and nothing in the system detects it.
  - *Mitigation:* Pin the parameter hash in the verifier and in CI, and fail the build on mismatch. Include the check in the audit scope.
  - Full page: https://zkpick.com/ceremony/failure-modes/deployed-parameters-that-do-not-match-the-ceremony-output/

### Sources

1. [SoK: Trusted setups for powers-of-tau strings (Wang, Cohney, Bonneau; FC 2025)](https://eprint.iacr.org/2025/064) — paper
2. [Scalable multi-party computation for zk-SNARK parameters in the random beacon model](https://eprint.iacr.org/2017/1050) — paper
3. [Snarky Ceremonies — Groth16 ceremony security analysis](https://eprint.iacr.org/2021/219) — paper
4. [Powers-of-Tau to the People: decentralising setup ceremonies](https://eprint.iacr.org/2022/1592) — paper
5. [Lite-PoT: practical powers-of-tau setup ceremony (CCS 2025)](https://arxiv.org/abs/2503.04549) — paper
6. [ZKProof community reference: setup ceremonies](https://zkproof.org/2021/06/30/setup-ceremonies/) — reference
7. [Wrapping up the KZG ceremony — 141,416 contributions over 208 days](https://blog.ethereum.org/2024/01/23/kzg-wrap) — record
8. [KZG ceremony special contributions — alternative entropy sources](https://blog.ethereum.org/2023/08/02/kzg-special-contributions) — record
9. [ethereum/kzg-ceremony — transcript, FAQ, audits, independent verifiers](https://github.com/ethereum/kzg-ceremony) — transcript
10. [ethereum/kzg-ceremony-specs — SRS sizes and contribution format](https://github.com/ethereum/kzg-ceremony-specs) — spec
11. [ceremony.ethereum.org — participation and transcript verification](https://ceremony.ethereum.org/) — record
12. [Perpetual Powers of Tau — contribution chain, attestations, beacon](https://github.com/privacy-ethereum/perpetualpowersoftau) — transcript
13. [Perpetual Powers of Tau — verifying a contribution](https://github.com/privacy-ethereum/perpetualpowersoftau/blob/master/verifying_a_contribution.md) — procedure
14. [Perpetual Powers of Tau technical report](https://github.com/privacy-ethereum/technical-reports/blob/main/reports/Primitive_Engineering/Perpetual_Powers_of_Tau/Perpetual_Powers_of_Tau.md) — report
15. [snarkjs — powersoftau and zkey commands, supported curves](https://github.com/iden3/snarkjs) — tool
16. [gnark mpcsetup — Groth16 BN254 phase 1 and phase 2](https://pkg.go.dev/github.com/consensys/gnark/backend/groth16/bn254/mpcsetup) — tool
17. [p0tion — phase-2 ceremony toolkit (in maintenance mode)](https://github.com/privacy-ethereum/p0tion) — tool
18. [DefinitelySetup — ceremony registry and coordination front end](https://github.com/privacy-ethereum/DefinitelySetup) — tool
19. [phase2-bn254 — Rust phase-2 tooling used by several BN254 ceremonies](https://github.com/kobigurk/phase2-bn254) — tool
20. [RISC Zero trusted setup ceremony — rationale for a STARK-verify wrapper circuit](https://dev.risczero.com/api/trusted-setup-ceremony) — record
21. [SP1 security model — documented reliance on an existing setup for its wrapper](https://docs.succinct.xyz/docs/sp1/security/security-model) — documentation
22. [Aztec Ignition ceremony completion report (BN254, ~100M points)](https://aztec.network/blog/aztec-crs-the-biggest-mpc-setup-in-history-has-successfully-finished) — record
23. [AztecProtocol/Setup — Ignition MPC ceremony code and transcript tooling](https://github.com/AztecProtocol/Setup) — transcript
24. [AztecProtocol/ignition-verification — independent verification of the Ignition transcript](https://github.com/AztecProtocol/ignition-verification) — tool
25. [ZcashFoundation/powersoftau-attestations — 88 entries ending in a random beacon](https://github.com/ZcashFoundation/powersoftau-attestations) — transcript
26. [The design of the ceremony — Zcash Sprout operational security (archived copy; the original post has been removed)](https://web.archive.org/web/20250117175433/https://electriccoin.co/blog/the-design-of-the-ceremony/) — record
27. [Reinforcing the security of the Sapling MPC — Maller's proof that the beacon is not needed in the generic group model (archived copy)](https://web.archive.org/web/20241204211816/https://electriccoin.co/blog/reinforcing-the-security-of-the-sapling-mpc/) — analysis
28. [Filecoin powers of tau — BLS12-381 phase 1 at 2^27, 19 participants](https://github.com/filecoin-project/powersoftau) — transcript
29. [Filecoin: trusted setup complete — phase 1 and phase 2 summary](https://filecoin.io/blog/posts/trusted-setup-complete/) — record
30. [Hermez: selection of Perpetual Powers of Tau contribution 54 plus beacon — origin of the powersOfTau28_hez files](https://hackmd.io/@4sHVqkbyQnyF63sea5vFOg/S1XuzpJXw) — record
31. [Tornado Cash trusted-setup-server — phase 2 with 1,114 contributions on PPOT contribution 30](https://github.com/tornadocash/trusted-setup-server) — transcript
32. [Penumbra summoning ceremony — decentralised phase 2 run through the chain's own wallet](https://penumbra.zone/blog/summoning-ceremony-phase-2) — record
33. [Zcash counterfeiting vulnerability remediated — the BCTV14 setup flaw](https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/) — disclosure
34. [The first ZK exploits happened, and they weren't what we expected](https://blog.zksecurity.xyz/posts/groth16-setup-exploit/) — analysis
35. [filecoin-project/phase2-attestations — production Groth16 phase-2 records](https://github.com/filecoin-project/phase2-attestations) — transcript
36. [Filecoin trusted setup artefact hosting](https://trusted-setup.filecoin.io/) — artefact
37. [semaphore-phase2-setup — phase 2 built on a Perpetual Powers of Tau challenge file](https://github.com/privacy-ethereum/semaphore-phase2-setup) — transcript
38. [ark-srs — Rust utility for consuming SRS from existing ceremonies](https://github.com/alxiong/ark-srs) — tool
39. [ptau-deserializer — converts snarkjs phase-1 output for use with gnark](https://github.com/worldcoin/ptau-deserializer) — tool
40. [drand / League of Entropy — distributed publicly verifiable randomness beacon](https://drand.love/) — service
41. [Debian DSA-1571-1 — predictable OpenSSL random number generator](https://lists.debian.org/debian-security-announce/2008/msg00152.html) — advisory
42. [Zcash NU5 — Orchard shielded pool on Halo 2, requiring no trusted setup](https://z.cash/upgrade/nu5/) — record