← → Print all
04 — Trusted setup · Only if your proof system demands it

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.

Whether you need one is decided in §01Ceremony design belongs in the audit scope
By MarketComp Updated v1.3 About the authors Changelog
Trusted setup ceremony contribution chain Six participant contributions flow through a public beacon into the final structured reference string. Security requires only one honest participant. BEACON SRS CONTRIBUTES RANDOMNESS DESTROYS THE SECRET 01 02 03 04 05 06 SECURE IF ANY ONE OF THESE WAS HONEST
Fig. 5 · Contribution chain, beacon and the 1-of-N assumption
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 · 8

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 evaluateCheck 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.

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 evaluateConfirm 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.

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 evaluateRecruit 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.

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 evaluateRequire 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.

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 evaluatePrefer 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.

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 evaluatePublish 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.

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 evaluateUse 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.

Operational and communication plan

Ceremonies are logistics exercises. Most failures are dropped participants, ambiguous instructions and unclear deadlines, not cryptography.

How to evaluateDecide 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 setups · 9

Reusable public setups

Filter by hard constraint
Published ceremonies whose output can be adopted instead of running your own
CeremonyCurveSize / degree boundContributionsUsable forRunAdoption caveat
Perpetual Powers of TauBN254up to 2^2880+ recordedGroth16 and PLONK-family2019 – 2024; repository archived Aug 2026No 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)BN2542^28PPOT contributions 1–54 plus a beaconGroth16 and PLONK-family2020The 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 tauBLS12-3812^2719Groth16 and PLONK-family2019 – 2020The 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 ceremonyBLS12-3812^12 – 2^15 G1, 65 G2141,416KZG only — not Groth1613 Jan – 8 Aug 2023By 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 IgnitionBN254~100.8M G1 points~176KZG only — not Groth162019 – Jan 2020The 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 tauBLS12-3812^2188 entriesGroth16 and PLONK-familyNov 2017 – early 2018The 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 2BN254Circuit-specific1,114Reference only — not reusable parametersMay 2020Not 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 ceremonyBLS12-377Circuit-specific15,000+ in phase 1Reference only — not reusable parameters2023Not 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 attestationsBLS12-381Circuit-specific, very large~12–19 per circuit setReference only — not reusable parameters2020, 2021–22Not 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.
Reading this table

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.

Ceremony approaches · 6 pages

Avoid the setup entirely: transparent proof systems Avoidance strategy Systems verifying off-chain, or on a chain tolerant of larger proofs, and any team for whom parameter lifecycle risk outweighs proof size. snarkjs (powersoftau + zkey) Phase 1 and phase 2 tooling Circom-based Groth16 and PLONK teams, and anyone consuming .ptau artefacts from Perpetual Powers of Tau. gnark mpcsetup Phase 1 and phase 2 tooling Teams whose circuits are written in gnark and who want the ceremony in the same toolchain as the prover. Coordinated phase-2 ceremony platforms Coordinated ceremony platform Teams needing an open, browser-accessible phase-2 ceremony with many contributors, who do not want to build queueing and attestation plumbing themselves. Sequencer-mediated large public ceremony Ceremony design pattern Organisations designing a large, public, browser-based ceremony who want a battle-tested reference architecture and verification-client model. Coordinatorless and on-chain ceremonies Ceremony design (research) Projects where censorship-resistance of the ceremony itself is a stated requirement, or teams assessing where the field is heading.

Process · 10 steps

  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 · 16

Phase 2 never run: shipping the initial zkey Forgetting that a universal SRS is updatable by you Adopting a transcript that cannot serve your scheme Running a ceremony you did not need Toxic waste that is never actually destroyed Unverified contributions in the chain A participant set that cannot bear scrutiny Circuit changes after the ceremony A transparent system that quietly reintroduces a setup Citing a ceremony without naming the branch and index Using an SRS with the wrong curve or degree The transcript becomes unavailable A correctly run ceremony for an unsound setup protocol Ceremony as security theatre Entropy theatre presented as a security control Deployed parameters that do not match the ceremony output

Sources for this section · 42

  1. SoK: Trusted setups for powers-of-tau strings (Wang, Cohney, Bonneau; FC 2025)paper
  2. Scalable multi-party computation for zk-SNARK parameters in the random beacon modelpaper
  3. Snarky Ceremonies — Groth16 ceremony security analysispaper
  4. Powers-of-Tau to the People: decentralising setup ceremoniespaper
  5. Lite-PoT: practical powers-of-tau setup ceremony (CCS 2025)paper
  6. ZKProof community reference: setup ceremoniesreference
  7. Wrapping up the KZG ceremony — 141,416 contributions over 208 daysrecord
  8. KZG ceremony special contributions — alternative entropy sourcesrecord
  9. ethereum/kzg-ceremony — transcript, FAQ, audits, independent verifierstranscript
  10. ethereum/kzg-ceremony-specs — SRS sizes and contribution formatspec
  11. ceremony.ethereum.org — participation and transcript verificationrecord
  12. Perpetual Powers of Tau — contribution chain, attestations, beacontranscript
  13. Perpetual Powers of Tau — verifying a contributionprocedure
  14. Perpetual Powers of Tau technical reportreport
  15. snarkjs — powersoftau and zkey commands, supported curvestool
  16. gnark mpcsetup — Groth16 BN254 phase 1 and phase 2tool
  17. p0tion — phase-2 ceremony toolkit (in maintenance mode)tool
  18. DefinitelySetup — ceremony registry and coordination front endtool
  19. phase2-bn254 — Rust phase-2 tooling used by several BN254 ceremoniestool
  20. RISC Zero trusted setup ceremony — rationale for a STARK-verify wrapper circuitrecord
  21. SP1 security model — documented reliance on an existing setup for its wrapperdocumentation
  22. Aztec Ignition ceremony completion report (BN254, ~100M points)record
  23. AztecProtocol/Setup — Ignition MPC ceremony code and transcript toolingtranscript
  24. AztecProtocol/ignition-verification — independent verification of the Ignition transcripttool
  25. ZcashFoundation/powersoftau-attestations — 88 entries ending in a random beacontranscript
  26. The design of the ceremony — Zcash Sprout operational security (archived copy; the original post has been removed)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)analysis
  28. Filecoin powers of tau — BLS12-381 phase 1 at 2^27, 19 participantstranscript
  29. Filecoin: trusted setup complete — phase 1 and phase 2 summaryrecord
  30. Hermez: selection of Perpetual Powers of Tau contribution 54 plus beacon — origin of the powersOfTau28_hez filesrecord
  31. Tornado Cash trusted-setup-server — phase 2 with 1,114 contributions on PPOT contribution 30transcript
  32. Penumbra summoning ceremony — decentralised phase 2 run through the chain's own walletrecord
  33. Zcash counterfeiting vulnerability remediated — the BCTV14 setup flawdisclosure
  34. The first ZK exploits happened, and they weren't what we expectedanalysis
  35. filecoin-project/phase2-attestations — production Groth16 phase-2 recordstranscript
  36. Filecoin trusted setup artefact hostingartefact
  37. semaphore-phase2-setup — phase 2 built on a Perpetual Powers of Tau challenge filetranscript
  38. ark-srs — Rust utility for consuming SRS from existing ceremoniestool
  39. ptau-deserializer — converts snarkjs phase-1 output for use with gnarktool
  40. drand / League of Entropy — distributed publicly verifiable randomness beaconservice
  41. Debian DSA-1571-1 — predictable OpenSSL random number generatoradvisory
  42. Zcash NU5 — Orchard shielded pool on Halo 2, requiring no trusted setuprecord
Cite this page 
MarketComp (2026). Running or reusing a trusted setup. The ZK Field Manual (Version 1.3). MarketComp. https://zkpick.com/ceremony/
@misc{zkfieldmanual-running-or-reusing-a-trusted-setup,
  title        = {Running or reusing a trusted setup — The ZK Field Manual},
  author       = {MarketComp},
  year         = {2026},
  version      = {1.3},
  howpublished = {\url{https://zkpick.com/ceremony/}},
  note         = {Accessed: YYYY-MM-DD}
}