Ceremony
Technical ceremony participation
Updated 30 September 20262 min read
This page is for contributors who want to verify everything themselves. The ceremony uses a Groth16 circuit-specific setup, so you verify the inputs, extend the contribution chain with fresh local randomness, and then verify that your contribution landed in the final artifacts.
The artifacts
| Artifact | Purpose |
|---|---|
| Manifest | Pins circuits, file hashes, toolchain versions and finalization parameters |
| R1CS | The constraint system of each circuit |
| Powers of Tau (PTAU) | Phase 1 parameters underlying all circuits |
| Initial zkey | Each circuit's starting parameters |
| Current zkey | The live contribution chain to extend |
| Contribution record | Your acceptance receipt in the transcript |
| Final proving/verification keys | What clients prove with and contracts verify against |
Verify file hashes against the manifest, and fetch the manifest through an independent channel so the values themselves are anchored.
Contributing
Browser and command line follow the same cryptographic steps.
- Verify the circuit inputs, Phase 1 parameters and existing chain.
- Extend the current head with fresh, locally generated randomness, and don't reuse a wallet seed, key or password as entropy.
- Verify your resulting zkey against the circuit and setup inputs.
- Submit, and acceptance validates that your result extends the expected chain.
- Keep your contribution record and confirm inclusion in the finalized transcript.
Contribution commands are standard snarkjs tooling. Each circuit has its own chain, so the more circuits you contribute to, the more of the system carries your randomness.
Verifying the final result
For each circuit, anyone can independently do the following.
- Verify Phase 1 provenance and reproduce the circuit constraints from source.
- Verify the complete contribution chain, including their own link in it.
- Check the finalization beacon against its specified public source.
- Derive the verification key from the final zkey and compare it byte for byte with what the contracts verify against.
That last step closes the loop, so every link from community randomness to the exact keys securing the Reserve can be checked publicly. The construction is Groth16, described in the original paper.
See Architecture for how the finished keys fit into the protocol.