# Trusted-setup ceremony

## Why we need a fresh ceremony

Tornado Cash's existing zkey is unusable for TONado Cash:

1. **Different curve.** Their zkey contains G1/G2 points on BN254; TONado Cash verifies on BLS12-381. The points don't exist on the other curve.
2. **Different circuit.** We use Poseidon instead of MiMC and different field constants. Even on the same curve, this would invalidate the zkey.
3. **Different domain.** Our `ZERO_VALUE` derives from `"tonado"`, not `"tornado"`.

## The two phases

|                            | What it does                | Reusable?                                                           |
| -------------------------- | --------------------------- | ------------------------------------------------------------------- |
| Phase 1 (Powers of Tau)    | Universal SRS for the curve | **Yes**: we use a public BLS12-381 ptau (e.g. from Polygon Hermez). |
| Phase 2 (circuit-specific) | Binds the SRS to our R1CS   | **No**: we run a fresh multi-party MPC.                             |

## Phase 1: Powers of Tau

We do **not** run phase 1 ourselves. We download a verified BLS12-381 ptau:

```bash
pnpm circuits:ptau-setup
```

**Important:** the URL in `apps/contracts/scripts/setup-ptau.ts` is a placeholder. Replace it with an attested BLS12-381 ptau before mainnet. See [TON ZK docs](https://docs.ton.org/contract-dev/zero-knowledge) for canonical URLs, or contribute to / use the Polygon Hermez ptau ceremony output for BLS12-381.

## Phase 2: Circuit-specific MPC

### Testnet (developer ceremony)

For testnet we use a single throwaway contribution baked into `scripts/compile-circuits.ts`. This is convenient for development but **must not be used on mainnet**. Anyone with access to the dev entropy can forge proofs and drain pools.

### Mainnet (multi-party ceremony)

For mainnet:

1. **Choose a coordinator** (project lead).
2. **Publish the initial zkey** to a public repo. Pin its hash in this doc.
3. **Recruit ≥ 5 contributors** (ideally with diverse motivations: protocol team, auditor, external security researcher, community member, neutral third party).
4. **Each contributor runs:**

   ```bash
   snarkjs zkey contribute \
     withdraw_N.zkey \
     withdraw_N+1.zkey \
     --name="<contributor identity>" \
     -e="<their own high-entropy randomness, NEVER logged>"
   ```

   On finishing, they:

   * Securely delete the entropy and the intermediate zkey from their machine.
   * Publish `withdraw_N+1.zkey` and the snarkjs transcript hash to the ceremony repo.
   * Sign the hash with a public PGP key tied to their identity.
5. **Coordinator verifies** each contribution:

   ```bash
   snarkjs zkey verify withdraw.r1cs pot_final.ptau withdraw_N+1.zkey
   ```
6. **Finalise:**

   ```bash
   snarkjs zkey beacon withdraw_K.zkey withdraw_final.zkey \
     <publicly-attested-beacon-hash> 10 -n="Final beacon"
   snarkjs zkey verify withdraw.r1cs pot_final.ptau withdraw_final.zkey
   snarkjs zkey export verificationkey withdraw_final.zkey verification_key.json
   ```

   The beacon binds the final zkey to a public, unpredictable value (e.g. an Ethereum block hash from a specific future block) so that even the coordinator can't have manipulated the result.

### Publishing

After the ceremony:

1. Commit `withdraw_final.zkey` and `verification_key.json` to `packages/core/artifacts/` (git-LFS if too large).
2. Update this doc with the list of contributors and their published transcript hashes.
3. Regenerate the Tolk verifier:

   ```bash
   pnpm verifier:export
   ```
4. Deploy fresh pool contracts using the new verifier.
5. Tag the commit `mainnet-ceremony-vN` for reproducibility.

## Security properties

The ceremony is secure as long as **at least one** contributor:

* Generated truly random entropy.
* Did not log, persist, or share that entropy.
* Securely destroyed the entropy after their contribution.

This is the same trust model as Tornado Cash's original ceremony, which has \~3 years of mainnet track record.


---

# 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/operations/ceremony.md?ask=<question>
```

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.