# Redacted ceremony — technical participant guide
Prepared 15 September 2026.

## Current status
The community ceremony is **not open**. The published page offers a real, local
Groth16 practice using the development control_register circuit. A practice
result is not submitted, is not included in a public ceremony, and must never
become a production proving key.

The six-circuit local coordinator is a development tool, not a live endpoint.
A live coordinator URL, approved initial manifest, independent mirror and final
beacon policy will be announced together. Do not send files to an unannounced URL.

## Simple participant flow
1. Open the official page on a current desktop browser.
2. Optionally move your mouse, draw, or tap in the randomness field.
3. Start and keep the tab in the foreground.
4. Wait for verification. Save the receipt and, for practice, the resulting zkey.
No wallet, seed phrase, signature, funds, or personal account is required.

Gestures are supplemental only. The worker uses Web Crypto randomness and
snarkjs also mixes fresh random bytes. Neither gesture counts nor time spent
drawing measure entropy or security. Raw gestures are not sent to a coordinator.
The fading numbers beside the drawing are separate, decorative values. They
never display or supply the contribution's secret randomness.
JavaScript cannot promise verifiable memory erasure.

## Exactly what is verified
Practice checks SHA-256 of its pinned manifest, vendored snarkjs bundle, initial
zkey, R1CS and all PTAU chunks. It uses snarkjs 0.7.6 to check the initial key
against the R1CS, contribute, and verify the result against the original initial
key and prepared PTAU. No proof witness or wallet data is involved.

The receipt's 64-byte BLAKE2b contribution hash is not the SHA-256 of the file.
receiptSha256 hashes the compact JSON body in the displayed property order,
excluding receiptSha256. It is an integrity checksum, not a signature or proof
of public acceptance. Independently verifying the zkey is stronger than trusting
the receipt's localVerification text.

## Reproduce the practice independently
Download /rehearsal/manifest.json and compare its hash with the release through
an independent channel. Fetch control_register.initial.zkey,
control_register.r1cs, and every PTAU part listed there. Check each size/hash.
Concatenate PTAU parts in listed order as prepared.ptau; verify the whole-file
PTAU hash in the manifest before use. All these inputs are development-only.

Use a dedicated directory and the published, pinned toolchain. The page's
practice engine is snarkjs 0.7.6. For quick verification with that version:

```sh
npx --yes snarkjs@0.7.6 zkey verify control_register.r1cs prepared.ptau control_register.practice.zkey
```

To generate an independent contribution yourself:

```sh
npx --yes snarkjs@0.7.6 zkey contribute control_register.initial.zkey contribution.zkey --name="Participant"
npx --yes snarkjs@0.7.6 zkey verify control_register.r1cs prepared.ptau contribution.zkey
```

The contribute command prompts for additional entropy. Use fresh arbitrary
input, NEVER a wallet seed/private key/password. Do not publish or log the
entropy. For an actual ceremony, use the reviewed lockfile build rather than
resolving an ad-hoc package installation.

## Local full-coordinator rehearsal (operators / developers)
This section requires a separately supplied operator checkout; the public
practice page does not distribute that checkout or accept uploads.
From that source directory, install the exact package-lock.json:

```sh
npm ci
npm run rehearsal:server
```

In another terminal:

```sh
npm run rehearsal:contribute
```

The default is http://127.0.0.1:5187. Only loopback HTTP is accepted; redirects
are forbidden. The client processes all six circuits, verifies signed receipts,
and saves progress under work/client. Re-run the same command to resume already
accepted circuits. Add --new only for an intentional additional run:

```sh
npm run rehearsal:contribute -- http://127.0.0.1:5187 --new
```

Do not use --new to resolve an uncertain upload. The pending file and progress
are preserved; re-run the same command to reconcile against the transcript.
If it remains unconfirmed, inspect the operator state before releasing/retrying.
Never discard the sole pending output while its acceptance is uncertain.

The Node verifier checks the exact current MPC prefix plus precisely one new
ordinary contribution, then Groth16 validity. Heads advance only after successful
verification. The local transcript contains Ed25519-signed acknowledgements
and links each receipt to the previous receipt hash. A signature does not prove
independence, secure erasure, final inclusion, or production approval.

## Live ceremony requirements
Each participant contributes to all six approved circuits:
- reserve_deposit (4 public inputs)
- reserve_spend (7)
- reserve_merge (5)
- control_register (2)
- control_action (5)
- create_subwallet (5)

A live flow must download the leased/current head and validate its manifest and
existing contribution chain, contribute locally, upload within the lease and size
bounds, and wait for independent server acceptance. A successful upload alone
does not mean acceptance. Compare the returned signed receipt against the
published, mirrored transcript and retain it through finalization.

Keep the original zero-contribution zkey for verifyFromInit. Do not pass the
previous contributed head as the "initial" key.

The unmodified snarkjs 0.7.6 browser verifier hits WebCrypto's 65,536-byte
getRandomValues limit for the current reserve_merge circuit. This page therefore
does NOT claim a six-circuit browser verifier. The local coordinator verifies all
six in Node. A reviewed full-browser fix or an explicitly specified verification
path is a live launch gate.

## Final independent verification
After the operators close contributions, apply the previously announced beacon,
verify the full PTAU provenance and all six final zkeys against reproduced R1CS,
export verification keys, and compare browser/contract verifier artifacts with
the signed release manifest. Verify your contribution appears in the final chain.

Do not deploy development keys, skip a circuit, substitute a new genesis, or
silently restart the ceremony after publishing its initial inputs.

## Trust boundaries
The honest-contributor assumption applies separately to each circuit and rests
on a sound Phase 1. A ceremony does not audit circuit correctness, contracts,
frontend supply chains or wallets. The live operator can observe connection
metadata and censor participation; independent mirrors and review are required.
Even in local practice, the website host can observe requests for the page and
downloaded artifacts. Local-only contributions do not make website visits anonymous.

## Sources and reproducibility
- The final contract/circuit source release is not linked from this practice page.
  Publish the reviewed source and reproducible-build instructions before opening
  the real ceremony, so participants can independently inspect the final inputs.
- snarkjs pinned source / license: https://github.com/iden3/snarkjs/tree/v0.7.6
- Official commands: https://github.com/iden3/snarkjs/blob/v0.7.6/README.md
- Browser API example: https://github.com/iden3/snarkjs/blob/master/browser_tests/test/groth16.html
- Worker bundle license: /vendor/SNARKJS-LICENSE.txt