# The trusted setup Groth16 needs a one-time setup ceremony before any proofs can be made. This ceremony produces a **proving key** (used to generate proofs) and a **verifying key** (used to check proofs on-chain). The ceremony also produces "toxic waste": random values that, if not destroyed, would let the holder forge proofs. This page explains what the trusted setup is, what we trust about it, and what the mainnet ceremony will look like. For the step-by-step procedure, see [Trusted-setup ceremony](/operations/ceremony.md). ## What the setup actually produces Each Groth16 circuit needs: * **A proving key**, used by the prover to generate proofs. It's circuit-specific and \~50MB. * **A verifying key**, used by the verifier to check proofs. It's also circuit-specific but much smaller (\~few KB). For TONado Cash, this becomes baked-in constants in the auto-generated `verifier.tolk`. Both keys are derived from a one-time stream of random values, the "toxic waste". The toxic waste is the secret that **must be destroyed** at the end of the ceremony. If anyone keeps a copy, they have the power to forge proofs for the circuit. ## The two phases Groth16's setup is split into two phases: ### Phase 1: Powers of Tau A **universal** ceremony, its output usable for any circuit on a given curve. There are large public Phase 1 ceremonies for BLS12-381 (Polygon Hermez ran one; others exist). We **don't** run Phase 1 ourselves; we use a published, attested ptau file. Trust in Phase 1 reduces to: *did the published ptau come from a real ceremony with multiple honest participants?* The Polygon Hermez ceremony, for example, had 50+ contributors from many organizations. The probability that every one of them was simultaneously malicious is effectively zero. ### Phase 2: Circuit-specific A **per-circuit** ceremony that binds the universal Phase 1 output to TONado Cash's specific R1CS constraint system. We need two Phase 2 ceremonies: one for the withdraw circuit, one for the root-update circuit. Phase 2 is the one **we** run. ## How a Phase 2 ceremony works The ceremony is a sequence of contributions, each by an independent party: ``` initial zkey → Alice contributes → zkey_1 → Bob contributes → zkey_2 → ... → zkey_N │ ▼ public beacon (e.g., a future Bitcoin block hash) │ ▼ final zkey ``` Each contributor: 1. Downloads the previous contributor's zkey. 2. Generates fresh, secret randomness on an air-gapped or otherwise isolated machine. 3. Runs `snarkjs zkey contribute`, mixing their randomness into the zkey. 4. **Destroys their randomness**: overwrites the memory, wipes the disk, ideally physically destroys the medium. 5. Publishes the new zkey + their identity + a signed attestation of what they did. The final step is a **public beacon**, a verifiably random value that no one could have predicted (a future Bitcoin block hash, an Ethereum block hash from a future block, etc.). The coordinator applies the beacon as a final "contribution" before finalizing. ## Why this works The Groth16 setup is sound **as long as at least one contributor was honest**: * If contributor 1 is honest: they used fresh randomness and destroyed it. From that point on, no one (not even contributor 1) can reconstruct the toxic waste, because each subsequent contribution further mixes in randomness no single party knows. * If contributor 1 is malicious but contributor 2 is honest: contributor 2's randomness is fresh and destroyed. The toxic waste is now a function of both contributors' randomness, and neither alone can reconstruct it. * And so on. As long as **any single contributor** generated good randomness and destroyed it, the soundness holds. This is sometimes called a "1-of-N" trust model: you only need to trust that *at least one out of N* contributors was honest. With `N = 5+` contributors, the probability that **all five** were simultaneously malicious (including the contributors with reputations to protect and verifiable identities) approaches zero. ## The public beacon The final beacon serves an important function: it removes coordinator manipulation as an attack vector. Without a beacon, a malicious coordinator could carefully select which contributions to include and in what order. The beacon, being a value the coordinator couldn't have predicted in advance, pins the final zkey to a public commitment. Typical beacons: a Bitcoin block hash at a future, agreed-upon height; an Ethereum block hash; a draw from a randomness beacon like drand. ## What the ceremony produces, concretely After the ceremony: * `withdraw_final.zkey` (\~50MB), the final proving key for the withdraw circuit. * `merkleUpdate_final.zkey` (\~50MB), the final proving key for the root-update circuit. * `verification_key.json` files for each. * `verifier.tolk` and `verifier_merkle_update.tolk`, regenerated by `npx export-ton-verifier` from the final zkeys. * A public transcript of all contributions, their hashes, signed attestations, and the beacon source. The verifier `.tolk` files are committed to the repo. The zkeys are typically too large for git but published via IPFS, a GitHub release with LFS, or similar. ## What TONado Cash's mainnet ceremony will look like The [Mainnet launch plan](/operations/mainnet-launch-plan.md) Phase 3 specifies: * **≥5 contributors**, geographically distributed, with verifiable identities (e.g., team members, auditors, external security researchers, community members). * **A public Phase-1 ptau** for BLS12-381, hash-pinned in this repo. * **One Phase-2 ceremony per circuit**, with each contributor publishing intermediate hashes + a PGP-signed attestation. * **Public beacon** at the end, likely a Bitcoin block hash from a specified future height. * **An attestation file** committed to [`deploy/ceremony/`](https://github.com/tonadocash/monorepo/tree/main/deploy/ceremony) containing the final zkey hashes and contributor signatures. The deploy script refuses to run on mainnet without this file present. For testnet, we use a single throwaway contribution baked into the build. **This is not safe for mainnet**. Anyone with access to the testnet dev entropy can forge testnet proofs. Mainnet requires the real ceremony. ## What if the ceremony is botched If, hypothetically, all contributors collude or all leak their toxic waste, an attacker with the leaked entropy could: * Forge a withdrawal proof for any deposit in the pool. They could drain pools to addresses they control. This is a catastrophic, unrecoverable failure mode. The protocol team's mitigation is to: * Pick contributors with strong identities and reputations to protect. * Make the contribution process operationally simple so honest contributors can follow it correctly. * Publish every contribution transcript so any single contributor's failure (e.g., logging their entropy) can be detected post-hoc. Once the ceremony is final, the toxic waste is presumed destroyed. There's no way to verify destruction directly. Only the contributor knows whether they wiped the memory. This is the same trust model every Groth16 system uses, including Zcash and Tornado-EVM. ## Why we don't use a setup-free system PLONK, Halo2, and STARKs don't require this kind of trusted setup (or use a universal setup that's run once forever across all circuits). They're attractive for that reason. We picked Groth16 anyway because: * Verification cost on-chain is dramatically lower for Groth16. * The TON tooling (`export-ton-verifier`) is Groth16-specific. * The trust model (one honest contributor) is acceptable in practice. The Tornado-EVM ceremony ran successfully, and that system has had no setup-related compromises in \~3 years of mainnet operation. A future TONado Cash v2 could move to a setup-free system if verification costs come down. For v1, Groth16's verification economy wins. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.tonadocash.com/how-it-works/trusted-setup.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.