Trusted setup
Dev-grade, single-contributor keys. NOT safe for real value. Read this before trusting the pool.
DEVELOPMENT KEYS ONLY — NOT FOR MAINNET / REAL FUNDS
The proving and verifying keys in this build come from a single-contributor trusted setup run on one machine. Whoever ran it could have kept the toxic waste, and a party that keeps the toxic waste can forge proofs — i.e. mint value from nothing. This is fine for a testnet / dev pool, and is exactly what comparable projects say about their current keys. Do not use these keys, or any pool built on them, for anything of value.
Groth16 requires a per-circuit trusted setup. If the secret randomness ("toxic waste") from that setup is retained by anyone, they can forge proofs that verify — breaking the pool's soundness (they could withdraw value that was never deposited). The only defense is a multi-party ceremony where soundness holds as long as at least one participant was honest and destroyed their contribution.
What null's setup actually is
Phase 1 — Powers of Tau (circuit-agnostic): trustworthy
null uses the Hermez / Perpetual Powers of Tau ceremony output (a well-known multi-party ceremony with dozens of contributors), not a solo-generated one. A multi-party PoT is more trustworthy than one generated alone — only one of its many contributors needed to have been honest.
- File:
powersOfTau28_hez_final_15.ptau(2^15) - Source: the Polygon zkEVM mirror of the Hermez ceremony
- Integrity: verified with
snarkjs powersoftau verify→ "Powers Of tau file OK!", 55 contributions
Phase 2 — circuit-specific: single dev contribution
This is the part that is not safe. The circuit-specific key was produced with a single contribution on one machine:
- The contribution entropy is generated with
crypto.randomBytes(32), passed straight to snarkjs, and never written to disk — the derived toxic waste lives only in process memory and is gone at exit. After a run, only the final proving key and the verifying-key JSONs remain; no entropy or contribution artifacts are kept. - But there is only one contributor. Soundness therefore rests entirely on that single run having destroyed its toxic waste. There is no multi-party guarantee. Treat the keys as potentially compromised for any real value.
What production requires — no softening
Before any real value, null needs both of the following, without exception:
- A multi-party trusted-setup ceremony (many independent contributors, public transcript, at-least-one-honest soundness), replacing the single dev contribution.
- A security audit of the circuit, the on-chain verifier and state machine, and the key handling.
Until both are done, null is a demonstration of the design — not a system to hold funds.