The contribution is valid
The new transcript follows from the old transcript using a well-formed secret contribution.
Groth16 ceremony research · September 2026
Can you prove a secret is gone?
Seven ceremony implementations reveal the same boundary: the contribution can be verified with cryptography. The destruction of its secret randomness cannot.
01 / CORE FINDING
Three claims that should not be confused.
Ceremony software is strong at proving public state transitions. Its guarantees become progressively more operational once the computation ends.
Every secret copy is gone
A participant can always duplicate randomness before any deletion or attestation step.
The participant said it was erased
A signature binds an identity, contribution and time to the participant’s destruction claim.
02 / COMPARISON
What implementations actually do.
The prevailing pattern is process termination plus participant procedure. Use the filters to isolate approaches.
| Codebase | Secret handling | Erasure approach | Erasure evidence |
|---|---|---|---|
| Powers of Tauebfull / canonical | Trapdoor held in Rust process memory. | Air-gap; destroy hardware; assume RAM remnants. | None |
| Aleo SetupLeast Authority | Rust PrivateKey; explicitly dropped after use. |
Machine destruction and network isolation. | None |
| snarkjsiden3 | Secret in JavaScript objects; OS and user entropy. | Process termination and garbage collection. | None |
| Worldcoin / p0tionPhase 2 CLI | Entropy retained by the Node process. | Optional ordinary deletion of local output. | Public contribution record only |
| Panther ceremonysnarkjs + Docker | Contribution runs in a docker run --rm container. |
Remove container; separately wipe storage. | Artifact hashes only |
| Reilabs / gnarkGo | Calls gnark’s in-process Contribute(). |
Process termination. | None |
| Relaygnark + signed attestations | Contribution with environment and binary identity bound to an attestation. | Operator confirms process and storage destruction before upload. | Signed claim Limitation: Host can retain a secret copy first. |
“None” means no separate evidence of deletion. These projects still provide cryptographic evidence that a contribution itself is valid.
03 / THE BOUNDARY
Where cryptography ends and operations begin.
Relay acts as the participant’s supervisor: it measures and destroys the sensitive compute boundary, then asks the participant only about copies or snapshots software cannot observe.
Create isolated environment
Read-only inputs, no network, temporary memory-backed storage.
Generate and contribute
Toxic waste exists only inside the contributor process.
Handoff public output
Only the candidate transcript crosses back to the controller.
Remove and verify
Relay removes the exact container and verifies that its ID no longer exists.
Confirm, attest, upload
The participant confirms no copies or snapshots remain; Relay creates their signed record and uploads.
Cryptographic operation
Operational control
Signed record
Practical recommendation
Make the claim credible.
Relay cannot turn erasure into a theorem. It can make the participant’s claim narrower, better isolated, and auditable.
- Run Relay on the participant host as supervisor; generate toxic waste only inside its disposable contributor.
- Mount authenticated inputs read-only and expose one public-output handoff directory.
- Use a pinned image, no network, a read-only root, tmpfs, no swap and no core dumps.
- Remove the exact container ID and verify it is absent before continuing.
- Ask the participant to type “NO COPIES RETAINED” for snapshots, dumps and backups Relay cannot observe.
- For stronger macOS assurance, destroy a dedicated Linux VM—not merely one Docker container.
04 / PRIMARY SOURCES
Read the implementations.
Findings are based on project documentation and contribution code, not marketing summaries.