{
  "type": "section",
  "id": "ceremony",
  "number": "04",
  "title": "Running or reusing a trusted setup",
  "url": "https://zkpick.com/ceremony/",
  "markdown": "https://zkpick.com/md/ceremony.md",
  "summary": "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.",
  "notes": [
    {
      "kind": "note",
      "label": "Read this first",
      "text": "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."
    },
    {
      "kind": "warn",
      "label": "The residual risk never reaches zero",
      "text": "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."
    }
  ],
  "decisionCriteria": [
    {
      "name": "Do you need a setup at all",
      "why": "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": "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."
    },
    {
      "name": "Reuse versus run your own",
      "why": "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": "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."
    },
    {
      "name": "Participant set: size, independence and legibility",
      "why": "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": "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."
    },
    {
      "name": "Contribution integrity and attestation",
      "why": "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": "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."
    },
    {
      "name": "Randomness sourcing",
      "why": "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": "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."
    },
    {
      "name": "Transcript publication and independent verifiability",
      "why": "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": "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."
    },
    {
      "name": "Final beacon",
      "why": "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": "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."
    },
    {
      "name": "Operational and communication plan",
      "why": "Ceremonies are logistics exercises. Most failures are dropped participants, ambiguous instructions and unclear deadlines, not cryptography.",
      "how": "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."
    }
  ],
  "comparisons": [
    {
      "title": "Reusable public setups",
      "caption": "Published ceremonies whose output can be adopted instead of running your own",
      "url": "https://zkpick.com/ceremony/#ceremony-matrix",
      "note": "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.",
      "columns": [
        {
          "key": "name",
          "label": "Ceremony"
        },
        {
          "key": "curve",
          "label": "Curve"
        },
        {
          "key": "size",
          "label": "Size / degree bound"
        },
        {
          "key": "contribs",
          "label": "Contributions"
        },
        {
          "key": "usable",
          "label": "Usable for"
        },
        {
          "key": "period",
          "label": "Run"
        },
        {
          "key": "caveat",
          "label": "Adoption caveat"
        }
      ],
      "rows": [
        {
          "url": "https://zkpick.com/ceremony/#ceremony-matrix-perpetual-powers-of-tau",
          "constraints": [
            "bn254",
            "phase1",
            "large",
            "groth16"
          ],
          "name": "Perpetual Powers of Tau",
          "curve": "BN254",
          "size": "up to 2^28",
          "contribs": "80+ recorded",
          "usable": "Groth16 and PLONK-family",
          "period": "2019 – 2024; repository archived Aug 2026",
          "caveat": "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."
        },
        {
          "url": "https://zkpick.com/ceremony/#ceremony-matrix-hermez-powers-of-tau-powersoftau28-hez",
          "constraints": [
            "bn254",
            "phase1",
            "large",
            "groth16"
          ],
          "name": "Hermez powers of tau (powersOfTau28_hez)",
          "curve": "BN254",
          "size": "2^28",
          "contribs": "PPOT contributions 1–54 plus a beacon",
          "usable": "Groth16 and PLONK-family",
          "period": "2020",
          "caveat": "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."
        },
        {
          "url": "https://zkpick.com/ceremony/#ceremony-matrix-filecoin-powers-of-tau",
          "constraints": [
            "bls12381",
            "phase1",
            "large",
            "groth16"
          ],
          "name": "Filecoin powers of tau",
          "curve": "BLS12-381",
          "size": "2^27",
          "contribs": "19",
          "usable": "Groth16 and PLONK-family",
          "period": "2019 – 2020",
          "caveat": "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."
        },
        {
          "url": "https://zkpick.com/ceremony/#ceremony-matrix-ethereum-kzg-ceremony",
          "constraints": [
            "bls12381",
            "phase1"
          ],
          "name": "Ethereum KZG ceremony",
          "curve": "BLS12-381",
          "size": "2^12 – 2^15 G1, 65 G2",
          "contribs": "141,416",
          "usable": "KZG only — not Groth16",
          "period": "13 Jan – 8 Aug 2023",
          "caveat": "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."
        },
        {
          "url": "https://zkpick.com/ceremony/#ceremony-matrix-aztec-ignition",
          "constraints": [
            "bn254",
            "phase1",
            "large"
          ],
          "name": "Aztec Ignition",
          "curve": "BN254",
          "size": "~100.8M G1 points",
          "contribs": "~176",
          "usable": "KZG only — not Groth16",
          "period": "2019 – Jan 2020",
          "caveat": "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."
        },
        {
          "url": "https://zkpick.com/ceremony/#ceremony-matrix-zcash-sapling-powers-of-tau",
          "constraints": [
            "bls12381",
            "phase1",
            "groth16"
          ],
          "name": "Zcash Sapling powers of tau",
          "curve": "BLS12-381",
          "size": "2^21",
          "contribs": "88 entries",
          "usable": "Groth16 and PLONK-family",
          "period": "Nov 2017 – early 2018",
          "caveat": "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."
        },
        {
          "url": "https://zkpick.com/ceremony/#ceremony-matrix-tornado-cash-phase-2",
          "constraints": [
            "bn254"
          ],
          "name": "Tornado Cash phase 2",
          "curve": "BN254",
          "size": "Circuit-specific",
          "contribs": "1,114",
          "usable": "Reference only — not reusable parameters",
          "period": "May 2020",
          "caveat": "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."
        },
        {
          "url": "https://zkpick.com/ceremony/#ceremony-matrix-penumbra-summoning-ceremony",
          "constraints": [],
          "name": "Penumbra summoning ceremony",
          "curve": "BLS12-377",
          "size": "Circuit-specific",
          "contribs": "15,000+ in phase 1",
          "usable": "Reference only — not reusable parameters",
          "period": "2023",
          "caveat": "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."
        },
        {
          "url": "https://zkpick.com/ceremony/#ceremony-matrix-filecoin-phase-2-attestations",
          "constraints": [
            "bls12381"
          ],
          "name": "Filecoin phase-2 attestations",
          "curve": "BLS12-381",
          "size": "Circuit-specific, very large",
          "contribs": "~12–19 per circuit set",
          "usable": "Reference only — not reusable parameters",
          "period": "2020, 2021–22",
          "caveat": "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."
        }
      ]
    }
  ],
  "options": [
    {
      "type": "option",
      "name": "Avoid the setup entirely: transparent proof systems",
      "slug": "transparent-proof-systems",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/transparent-proof-systems/",
      "markdown": "https://zkpick.com/md/ceremony/transparent-proof-systems.md",
      "category": "Avoidance strategy",
      "summary": "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.",
      "description": "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.",
      "notes": [],
      "sections": [],
      "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'"
      ],
      "bestFit": "Systems verifying off-chain, or on a chain tolerant of larger proofs, and any team for whom parameter lifecycle risk outweighs proof size.",
      "maintainers": "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",
      "facts": [],
      "relatedFailureModes": [
        {
          "name": "Forgetting that a universal SRS is updatable by you",
          "url": "https://zkpick.com/ceremony/failure-modes/forgetting-that-a-universal-srs-is-updatable-by-you/"
        },
        {
          "name": "Circuit changes after the ceremony",
          "url": "https://zkpick.com/ceremony/failure-modes/circuit-changes-after-the-ceremony/"
        }
      ],
      "sources": [
        {
          "title": "SoK: Trusted setups for powers-of-tau strings (Wang, Cohney, Bonneau; FC 2025)",
          "url": "https://eprint.iacr.org/2025/064",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "snarkjs (powersoftau + zkey)",
      "slug": "snarkjs",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/snarkjs/",
      "markdown": "https://zkpick.com/md/ceremony/snarkjs.md",
      "category": "Phase 1 and phase 2 tooling",
      "summary": "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.",
      "description": "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.",
      "notes": [],
      "sections": [],
      "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"
      ],
      "bestFit": "Circom-based Groth16 and PLONK teams, and anyone consuming .ptau artefacts from Perpetual Powers of Tau.",
      "maintainers": "iden3 (Polygon ID lineage), open source",
      "maturity": "Production-used, actively maintained",
      "license": "GPL-3.0",
      "source": "https://github.com/iden3/snarkjs",
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "snarkjs — powersoftau and zkey commands, supported curves",
          "url": "https://github.com/iden3/snarkjs",
          "kind": "tool"
        },
        {
          "title": "ptau-deserializer — converts snarkjs phase-1 output for use with gnark",
          "url": "https://github.com/worldcoin/ptau-deserializer",
          "kind": "tool"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "gnark mpcsetup",
      "slug": "gnark-mpcsetup",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/gnark-mpcsetup/",
      "markdown": "https://zkpick.com/md/ceremony/gnark-mpcsetup.md",
      "category": "Phase 1 and phase 2 tooling",
      "summary": "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.",
      "description": "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.",
      "notes": [],
      "sections": [],
      "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"
      ],
      "bestFit": "Teams whose circuits are written in gnark and who want the ceremony in the same toolchain as the prover.",
      "maintainers": "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",
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "gnark mpcsetup — Groth16 BN254 phase 1 and phase 2",
          "url": "https://pkg.go.dev/github.com/consensys/gnark/backend/groth16/bn254/mpcsetup",
          "kind": "tool"
        },
        {
          "title": "ptau-deserializer — converts snarkjs phase-1 output for use with gnark",
          "url": "https://github.com/worldcoin/ptau-deserializer",
          "kind": "tool"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Coordinated phase-2 ceremony platforms",
      "slug": "phase-2-platforms",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/phase-2-platforms/",
      "markdown": "https://zkpick.com/md/ceremony/phase-2-platforms.md",
      "category": "Coordinated ceremony platform",
      "summary": "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.",
      "description": "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.",
      "notes": [],
      "sections": [],
      "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"
      ],
      "bestFit": "Teams needing an open, browser-accessible phase-2 ceremony with many contributors, who do not want to build queueing and attestation plumbing themselves.",
      "maintainers": "Ethereum Foundation Privacy & Scaling Explorations (p0tion, DefinitelySetup); maintenance mode",
      "maturity": "Production-used, maintenance mode",
      "license": "MIT",
      "source": "https://github.com/privacy-ethereum/p0tion",
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "p0tion — phase-2 ceremony toolkit (in maintenance mode)",
          "url": "https://github.com/privacy-ethereum/p0tion",
          "kind": "tool"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Sequencer-mediated large public ceremony",
      "slug": "sequencer-ceremony",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/sequencer-ceremony/",
      "markdown": "https://zkpick.com/md/ceremony/sequencer-ceremony.md",
      "category": "Ceremony design pattern",
      "summary": "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.",
      "description": "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.",
      "notes": [],
      "sections": [],
      "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"
      ],
      "bestFit": "Organisations designing a large, public, browser-based ceremony who want a battle-tested reference architecture and verification-client model.",
      "maintainers": "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",
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "ethereum/kzg-ceremony — transcript, FAQ, audits, independent verifiers",
          "url": "https://github.com/ethereum/kzg-ceremony",
          "kind": "transcript"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "option",
      "name": "Coordinatorless and on-chain ceremonies",
      "slug": "coordinatorless-ceremonies",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/coordinatorless-ceremonies/",
      "markdown": "https://zkpick.com/md/ceremony/coordinatorless-ceremonies.md",
      "category": "Ceremony design (research)",
      "summary": "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.",
      "description": "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.",
      "notes": [],
      "sections": [],
      "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"
      ],
      "bestFit": "Projects where censorship-resistance of the ceremony itself is a stated requirement, or teams assessing where the field is heading.",
      "maintainers": "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",
      "facts": [],
      "relatedFailureModes": [],
      "sources": [
        {
          "title": "Powers-of-Tau to the People: decentralising setup ceremonies",
          "url": "https://eprint.iacr.org/2022/1592",
          "kind": "paper"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    }
  ],
  "process": [
    {
      "title": "Confirm the requirement",
      "detail": "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."
    },
    {
      "title": "Search for a reusable SRS before planning anything",
      "detail": "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."
    },
    {
      "title": "Verify the transcript you intend to inherit",
      "detail": "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."
    },
    {
      "title": "Freeze the circuit before any circuit-specific phase",
      "detail": "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."
    },
    {
      "title": "Design the participant set and publish the rules in advance",
      "detail": "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."
    },
    {
      "title": "Rehearse the whole pipeline",
      "detail": "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."
    },
    {
      "title": "Run the ceremony, verifying continuously",
      "detail": "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."
    },
    {
      "title": "Apply and publish the beacon",
      "detail": "Apply the pre-committed beacon, publish its value and derivation, and run the full-chain verification once more over the finalised transcript."
    },
    {
      "title": "Publish artefacts, instructions and the trust statement",
      "detail": "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."
    },
    {
      "title": "Bind the parameters to the deployed system",
      "detail": "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."
    }
  ],
  "failureModes": [
    {
      "type": "failure-mode",
      "name": "Phase 2 never run: shipping the initial zkey",
      "slug": "phase-2-never-run-shipping-the-initial-zkey",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/phase-2-never-run-shipping-the-initial-zkey/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/phase-2-never-run-shipping-the-initial-zkey.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "Forgetting that a universal SRS is updatable by you",
      "slug": "forgetting-that-a-universal-srs-is-updatable-by-you",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/forgetting-that-a-universal-srs-is-updatable-by-you/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/forgetting-that-a-universal-srs-is-updatable-by-you.md",
      "detail": "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.",
      "relatedOptions": [
        {
          "name": "Avoid the setup entirely: transparent proof systems",
          "url": "https://zkpick.com/ceremony/transparent-proof-systems/"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "Adopting a transcript that cannot serve your scheme",
      "slug": "adopting-a-transcript-that-cannot-serve-your-scheme",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/adopting-a-transcript-that-cannot-serve-your-scheme/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/adopting-a-transcript-that-cannot-serve-your-scheme.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "Running a ceremony you did not need",
      "slug": "running-a-ceremony-you-did-not-need",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/running-a-ceremony-you-did-not-need/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/running-a-ceremony-you-did-not-need.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "Toxic waste that is never actually destroyed",
      "slug": "toxic-waste-that-is-never-actually-destroyed",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/toxic-waste-that-is-never-actually-destroyed/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/toxic-waste-that-is-never-actually-destroyed.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "Unverified contributions in the chain",
      "slug": "unverified-contributions-in-the-chain",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/unverified-contributions-in-the-chain/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/unverified-contributions-in-the-chain.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "A participant set that cannot bear scrutiny",
      "slug": "a-participant-set-that-cannot-bear-scrutiny",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/a-participant-set-that-cannot-bear-scrutiny/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/a-participant-set-that-cannot-bear-scrutiny.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "Circuit changes after the ceremony",
      "slug": "circuit-changes-after-the-ceremony",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/circuit-changes-after-the-ceremony/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/circuit-changes-after-the-ceremony.md",
      "detail": "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.",
      "relatedOptions": [
        {
          "name": "Avoid the setup entirely: transparent proof systems",
          "url": "https://zkpick.com/ceremony/transparent-proof-systems/"
        }
      ],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "A transparent system that quietly reintroduces a setup",
      "slug": "a-transparent-system-that-quietly-reintroduces-a-setup",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/a-transparent-system-that-quietly-reintroduces-a-setup/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/a-transparent-system-that-quietly-reintroduces-a-setup.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "Citing a ceremony without naming the branch and index",
      "slug": "citing-a-ceremony-without-naming-the-branch-and-index",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/citing-a-ceremony-without-naming-the-branch-and-index/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/citing-a-ceremony-without-naming-the-branch-and-index.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "Using an SRS with the wrong curve or degree",
      "slug": "using-an-srs-with-the-wrong-curve-or-degree",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/using-an-srs-with-the-wrong-curve-or-degree/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/using-an-srs-with-the-wrong-curve-or-degree.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "The transcript becomes unavailable",
      "slug": "the-transcript-becomes-unavailable",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/the-transcript-becomes-unavailable/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/the-transcript-becomes-unavailable.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "A correctly run ceremony for an unsound setup protocol",
      "slug": "a-correctly-run-ceremony-for-an-unsound-setup-protocol",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/a-correctly-run-ceremony-for-an-unsound-setup-protocol/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/a-correctly-run-ceremony-for-an-unsound-setup-protocol.md",
      "detail": "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. Prefer constructions with multiple independent implementations and published security proofs over bespoke or modified parameter generation.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "Ceremony as security theatre",
      "slug": "ceremony-as-security-theatre",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/ceremony-as-security-theatre/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/ceremony-as-security-theatre.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "Entropy theatre presented as a security control",
      "slug": "entropy-theatre-presented-as-a-security-control",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/entropy-theatre-presented-as-a-security-control/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/entropy-theatre-presented-as-a-security-control.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    },
    {
      "type": "failure-mode",
      "name": "Deployed parameters that do not match the ceremony output",
      "slug": "deployed-parameters-that-do-not-match-the-ceremony-output",
      "section": {
        "id": "ceremony",
        "number": "04",
        "title": "Running or reusing a trusted setup",
        "url": "https://zkpick.com/ceremony/"
      },
      "url": "https://zkpick.com/ceremony/failure-modes/deployed-parameters-that-do-not-match-the-ceremony-output/",
      "markdown": "https://zkpick.com/md/ceremony/failure-modes/deployed-parameters-that-do-not-match-the-ceremony-output.md",
      "detail": "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.",
      "relatedOptions": [],
      "updated": "2026-09-12",
      "version": "1.3"
    }
  ],
  "crossReferences": [
    {
      "section": "proof-systems",
      "note": "Whether you need one is decided in §01",
      "url": "https://zkpick.com/proof-systems/"
    },
    {
      "section": "audit",
      "note": "Ceremony design belongs in the audit scope",
      "url": "https://zkpick.com/audit/"
    }
  ],
  "sources": [
    {
      "title": "SoK: Trusted setups for powers-of-tau strings (Wang, Cohney, Bonneau; FC 2025)",
      "url": "https://eprint.iacr.org/2025/064",
      "kind": "paper"
    },
    {
      "title": "Scalable multi-party computation for zk-SNARK parameters in the random beacon model",
      "url": "https://eprint.iacr.org/2017/1050",
      "kind": "paper"
    },
    {
      "title": "Snarky Ceremonies — Groth16 ceremony security analysis",
      "url": "https://eprint.iacr.org/2021/219",
      "kind": "paper"
    },
    {
      "title": "Powers-of-Tau to the People: decentralising setup ceremonies",
      "url": "https://eprint.iacr.org/2022/1592",
      "kind": "paper"
    },
    {
      "title": "Lite-PoT: practical powers-of-tau setup ceremony (CCS 2025)",
      "url": "https://arxiv.org/abs/2503.04549",
      "kind": "paper"
    },
    {
      "title": "ZKProof community reference: setup ceremonies",
      "url": "https://zkproof.org/2021/06/30/setup-ceremonies/",
      "kind": "reference"
    },
    {
      "title": "Wrapping up the KZG ceremony — 141,416 contributions over 208 days",
      "url": "https://blog.ethereum.org/2024/01/23/kzg-wrap",
      "kind": "record"
    },
    {
      "title": "KZG ceremony special contributions — alternative entropy sources",
      "url": "https://blog.ethereum.org/2023/08/02/kzg-special-contributions",
      "kind": "record"
    },
    {
      "title": "ethereum/kzg-ceremony — transcript, FAQ, audits, independent verifiers",
      "url": "https://github.com/ethereum/kzg-ceremony",
      "kind": "transcript"
    },
    {
      "title": "ethereum/kzg-ceremony-specs — SRS sizes and contribution format",
      "url": "https://github.com/ethereum/kzg-ceremony-specs",
      "kind": "spec"
    },
    {
      "title": "ceremony.ethereum.org — participation and transcript verification",
      "url": "https://ceremony.ethereum.org/",
      "kind": "record"
    },
    {
      "title": "Perpetual Powers of Tau — contribution chain, attestations, beacon",
      "url": "https://github.com/privacy-ethereum/perpetualpowersoftau",
      "kind": "transcript"
    },
    {
      "title": "Perpetual Powers of Tau — verifying a contribution",
      "url": "https://github.com/privacy-ethereum/perpetualpowersoftau/blob/master/verifying_a_contribution.md",
      "kind": "procedure"
    },
    {
      "title": "Perpetual Powers of Tau technical report",
      "url": "https://github.com/privacy-ethereum/technical-reports/blob/main/reports/Primitive_Engineering/Perpetual_Powers_of_Tau/Perpetual_Powers_of_Tau.md",
      "kind": "report"
    },
    {
      "title": "snarkjs — powersoftau and zkey commands, supported curves",
      "url": "https://github.com/iden3/snarkjs",
      "kind": "tool"
    },
    {
      "title": "gnark mpcsetup — Groth16 BN254 phase 1 and phase 2",
      "url": "https://pkg.go.dev/github.com/consensys/gnark/backend/groth16/bn254/mpcsetup",
      "kind": "tool"
    },
    {
      "title": "p0tion — phase-2 ceremony toolkit (in maintenance mode)",
      "url": "https://github.com/privacy-ethereum/p0tion",
      "kind": "tool"
    },
    {
      "title": "DefinitelySetup — ceremony registry and coordination front end",
      "url": "https://github.com/privacy-ethereum/DefinitelySetup",
      "kind": "tool"
    },
    {
      "title": "phase2-bn254 — Rust phase-2 tooling used by several BN254 ceremonies",
      "url": "https://github.com/kobigurk/phase2-bn254",
      "kind": "tool"
    },
    {
      "title": "RISC Zero trusted setup ceremony — rationale for a STARK-verify wrapper circuit",
      "url": "https://dev.risczero.com/api/trusted-setup-ceremony",
      "kind": "record"
    },
    {
      "title": "SP1 security model — documented reliance on an existing setup for its wrapper",
      "url": "https://docs.succinct.xyz/docs/sp1/security/security-model",
      "kind": "documentation"
    },
    {
      "title": "Aztec Ignition ceremony completion report (BN254, ~100M points)",
      "url": "https://aztec.network/blog/aztec-crs-the-biggest-mpc-setup-in-history-has-successfully-finished",
      "kind": "record"
    },
    {
      "title": "AztecProtocol/Setup — Ignition MPC ceremony code and transcript tooling",
      "url": "https://github.com/AztecProtocol/Setup",
      "kind": "transcript"
    },
    {
      "title": "AztecProtocol/ignition-verification — independent verification of the Ignition transcript",
      "url": "https://github.com/AztecProtocol/ignition-verification",
      "kind": "tool"
    },
    {
      "title": "ZcashFoundation/powersoftau-attestations — 88 entries ending in a random beacon",
      "url": "https://github.com/ZcashFoundation/powersoftau-attestations",
      "kind": "transcript"
    },
    {
      "title": "The design of the ceremony — Zcash Sprout operational security (archived copy; the original post has been removed)",
      "url": "https://web.archive.org/web/20250117175433/https://electriccoin.co/blog/the-design-of-the-ceremony/",
      "kind": "record"
    },
    {
      "title": "Reinforcing the security of the Sapling MPC — Maller's proof that the beacon is not needed in the generic group model (archived copy)",
      "url": "https://web.archive.org/web/20241204211816/https://electriccoin.co/blog/reinforcing-the-security-of-the-sapling-mpc/",
      "kind": "analysis"
    },
    {
      "title": "Filecoin powers of tau — BLS12-381 phase 1 at 2^27, 19 participants",
      "url": "https://github.com/filecoin-project/powersoftau",
      "kind": "transcript"
    },
    {
      "title": "Filecoin: trusted setup complete — phase 1 and phase 2 summary",
      "url": "https://filecoin.io/blog/posts/trusted-setup-complete/",
      "kind": "record"
    },
    {
      "title": "Hermez: selection of Perpetual Powers of Tau contribution 54 plus beacon — origin of the powersOfTau28_hez files",
      "url": "https://hackmd.io/@4sHVqkbyQnyF63sea5vFOg/S1XuzpJXw",
      "kind": "record"
    },
    {
      "title": "Tornado Cash trusted-setup-server — phase 2 with 1,114 contributions on PPOT contribution 30",
      "url": "https://github.com/tornadocash/trusted-setup-server",
      "kind": "transcript"
    },
    {
      "title": "Penumbra summoning ceremony — decentralised phase 2 run through the chain's own wallet",
      "url": "https://penumbra.zone/blog/summoning-ceremony-phase-2",
      "kind": "record"
    },
    {
      "title": "Zcash counterfeiting vulnerability remediated — the BCTV14 setup flaw",
      "url": "https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated/",
      "kind": "disclosure"
    },
    {
      "title": "The first ZK exploits happened, and they weren't what we expected",
      "url": "https://blog.zksecurity.xyz/posts/groth16-setup-exploit/",
      "kind": "analysis"
    },
    {
      "title": "filecoin-project/phase2-attestations — production Groth16 phase-2 records",
      "url": "https://github.com/filecoin-project/phase2-attestations",
      "kind": "transcript"
    },
    {
      "title": "Filecoin trusted setup artefact hosting",
      "url": "https://trusted-setup.filecoin.io/",
      "kind": "artefact"
    },
    {
      "title": "semaphore-phase2-setup — phase 2 built on a Perpetual Powers of Tau challenge file",
      "url": "https://github.com/privacy-ethereum/semaphore-phase2-setup",
      "kind": "transcript"
    },
    {
      "title": "ark-srs — Rust utility for consuming SRS from existing ceremonies",
      "url": "https://github.com/alxiong/ark-srs",
      "kind": "tool"
    },
    {
      "title": "ptau-deserializer — converts snarkjs phase-1 output for use with gnark",
      "url": "https://github.com/worldcoin/ptau-deserializer",
      "kind": "tool"
    },
    {
      "title": "drand / League of Entropy — distributed publicly verifiable randomness beacon",
      "url": "https://drand.love/",
      "kind": "service"
    },
    {
      "title": "Debian DSA-1571-1 — predictable OpenSSL random number generator",
      "url": "https://lists.debian.org/debian-security-announce/2008/msg00152.html",
      "kind": "advisory"
    },
    {
      "title": "Zcash NU5 — Orchard shielded pool on Halo 2, requiring no trusted setup",
      "url": "https://z.cash/upgrade/nu5/",
      "kind": "record"
    }
  ],
  "updated": "2026-09-12",
  "version": "1.3",
  "canonical": "https://zkpick.com/ceremony/",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "authors": [
    "MarketComp"
  ]
}