A Trusted Setup Ceremony is a multi-party computation (MPC) protocol that generates the Common Reference String (CRS) required by certain zkSNARK systems like Groth16. The protocol proceeds sequentially, with each participant contributing a random secret to generate new structured parameters. The foundational security guarantee is the '1-of-N' trust model: the entire ceremony remains secure as long as a single participant destroys their generated randomness, known as toxic waste, preventing anyone from forging proofs.
Glossary
Trusted Setup Ceremony

What is Trusted Setup Ceremony?
A multi-party computation protocol used to generate the common reference string for a ZKP system, where security relies on at least one participant destroying their generated toxic waste.
The primary risk is the leakage of toxic waste, which would allow an attacker to create convincing but false proofs. To mitigate this, ceremonies often involve dozens of geographically and institutionally diverse participants using air-gapped machines. Modern alternatives like transparent setup protocols (e.g., zkSTARKs) or universal setup schemes (e.g., Plonk) eliminate the per-circuit ceremony requirement, replacing the MPC ritual with publicly verifiable randomness or a single, updatable ceremony for all circuits.
Core Properties of a Trusted Setup Ceremony
A trusted setup ceremony is a multi-party computation (MPC) protocol that generates the structured reference string required for certain zkSNARK systems. Its security relies on the 'toxic waste' being destroyed by at least one honest participant.
1-of-N Security Model
The fundamental security guarantee of a trusted setup ceremony is the 1-of-N trust assumption. The entire protocol remains secure as long as a single participant is honest and destroys their secret randomness. Even if all other participants collude maliciously, they cannot reconstruct the toxic waste needed to forge proofs. This transforms a centralized trust assumption into a decentralized, probabilistic one where the ceremony's integrity scales with the number of independent, verifiable participants.
Toxic Waste
Toxic waste refers to the secret random values generated by each participant during the ceremony. If these values are retained, an attacker can construct false proofs that pass verification. The term originates from Zcash's original ceremony. Key properties:
- Each participant generates a secret scalar
- The secret is combined with the previous state using multi-exponentiation
- The participant must irretrievably destroy this secret after their contribution
- The final structured reference string is a function of all secrets combined
Sequential Contribution
The ceremony proceeds as a sequential chain of contributions, not parallel. Each participant:
- Downloads the current state of the Common Reference String (CRS)
- Verifies all previous contributions using pairing checks
- Generates fresh randomness and updates the CRS
- Publishes the updated state with a proof of correct contribution This sequential structure ensures that the final parameters are a product of all independent randomness sources, creating a cryptographic ratchet that cannot be reversed.
Verifiable Contributions
Each participant must produce a proof of correct contribution that can be verified by all subsequent participants and external observers. This prevents malicious actors from sabotaging the ceremony by submitting invalid updates. The verification typically involves:
- Pairing-based checks confirming the update is consistent
- Zero-knowledge proofs attesting knowledge of the secret without revealing it
- Public transcripts allowing perpetual auditability of every contribution This ensures the ceremony is publicly verifiable from start to finish.
Circuit-Specific vs. Universal
Trusted setups fall into two categories:
Circuit-Specific (e.g., Groth16)
- The ceremony is tied to a single circuit
- Any change to the circuit requires a new ceremony
- Produces the smallest proof sizes and fastest verification
Universal & Updatable (e.g., Plonk)
- A single ceremony supports any circuit up to a bounded size
- New circuits can be added without re-running the ceremony
- The setup can be perpetually updated with new contributions to strengthen security over time
Entropy Sources & Platform Security
Participants must generate high-quality randomness in an environment isolated from potential exfiltration. Best practices include:
- Air-gapped machines disconnected from all networks
- Multiple entropy sources: hardware RNG, mouse movement, radioactive decay
- Ephemeral operating systems booted from read-only media
- Physical destruction of storage media after contribution
- Witness encryption to protect secrets during the contribution process Compromised entropy generation can undermine the entire ceremony's security, making operational security paramount.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Frequently Asked Questions
A trusted setup ceremony is a multi-party computation protocol used to generate the common reference string for a ZKP system, where security relies on at least one participant destroying their generated toxic waste. The following questions address the mechanics, security assumptions, and practical implementations of these ceremonies.
A trusted setup ceremony is a multi-party computation (MPC) protocol that generates the Common Reference String (CRS) required by certain Zero-Knowledge Proof systems, such as Groth16 and Plonk. The ceremony proceeds in sequential rounds where each participant contributes a random secret (often called 'toxic waste') to a structured parameter set. The security guarantee is based on the '1-of-N' trust assumption: the entire ceremony is secure as long as at least one participant destroys their secret contribution. If any single participant's randomness remains unknown, the soundness of the proof system is preserved. The process typically involves a coordinator, a verifiable computation to update the parameters, and a public audit trail to ensure no participant cheated.
Related Terms
Core concepts that interact with or depend on the trusted setup ceremony in zero-knowledge proof systems.
Common Reference String (CRS)
The structured public parameters generated as the direct output of a trusted setup ceremony. The CRS is shared between prover and verifier and encodes the circuit-specific or universal structure needed to create and check proofs. In pairing-based systems like Groth16, the CRS contains elements in both G1 and G2 groups. Security depends entirely on the integrity of the ceremony—if the toxic waste was not destroyed, the CRS enables undetectable forgery of proofs.
Toxic Waste
The secret random values generated by each participant during a trusted setup ceremony that must be destroyed to preserve soundness. If retained, toxic waste enables an attacker to construct fraudulent proofs that pass verification. The term originates from Zcash's original ceremony, where participants generated secret randomness and then securely deleted it. Multi-party ceremonies reduce risk: only one honest participant needs to destroy their toxic waste for the entire setup to be secure.
Universal Setup
A single, one-time trusted setup ceremony that generates a structured reference string capable of supporting any circuit up to a pre-defined maximum size. Unlike circuit-specific setups (Groth16), a universal setup like Plonk's requires only one ceremony for an entire ecosystem. New applications can reuse the existing CRS without repeating the ceremony. The updatable nature allows new participants to continuously strengthen security by contributing fresh randomness to the existing parameters.
Verification Key
A compact cryptographic key derived from the CRS and circuit definition that a verifier uses to efficiently check proof validity. The verification key is typically small (a few hundred bytes) and can be embedded on-chain or in resource-constrained environments. In a trusted setup, the verification key's integrity is directly tied to the ceremony's security—a compromised setup produces a verification key that accepts forged proofs as valid.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us