Contribute now

Fresh entropy is mixed into the setup parameters in this tab and destroyed here — only the new parameters leave. $0 · no deposit · ~1 minute.

—
contributions · goal 20+

Any wallet, any network we support — Solana or EVM. One rule: the address must have at least one transaction. Brand-new empty wallets are rejected.

connecting…
Why ceremony / 1-of-N ↓ · Verify chain ↓

tidex6 Trusted Setup

Public ceremony for private payments on Solana. $0 · no deposit · ~1 minute. Your wallet is only your name on a public list. We want 20+ real wallets.

What is a trusted setup, and why does it need a ceremony?

The short version of the cryptography.

tidex6 proves things in zero knowledge with Groth16 — the same proof system used across the ZK ecosystem. Groth16 is fast and tiny to verify on-chain, but it needs a set of public parameters (a Common Reference String) that must be generated once, up front.

Generating those parameters produces a piece of secret randomness — the “toxic waste.” Whoever knows the toxic waste can forge fake proofs: mint value from nothing, or withdraw money that was never deposited. If it is destroyed, the parameters are perfectly safe. If it is kept, the whole system can be counterfeited.

So the only question that matters is: was the toxic waste really destroyed?

1 party A single machine generates the parameters and promises to delete the secret. You have to trust that one party. That is what we run today (clearly marked “development only”).
N parties In a ceremony, contributors take turns. Each one adds their own fresh randomness on top of the previous result and destroys it. The final parameters are safe as long as at least one contributor was honest.
Break the setup only if every single contributor colludes.
With 10–20 independent people, that is practically impossible. This is the “1-of-N” trust model.

That is the whole point of a public ceremony: it removes the “trust one party” assumption and replaces it with “trust that not everyone is dishonest.” The more independent contributors, the stronger it gets — which is exactly why we want you.

What already works

This is not a whitepaper. The protocol is live on mainnet today.

Shielded pool on mainnet
Deposit + withdraw, Groth16 / BN254, per-nullifier double-spend protection. verifier ↗
Verified & immutable
OtterSec source-verified; the verifier's upgrade authority is renounced — it can never change.
Two layers of privacy
The link is hidden by the Groth16 pool; the amount is hidden by Token-2022 confidential transfers (wUSDC and wUSDT). Neither who↔whom nor how-much is visible on-chain.
Client-side proving
Proofs are generated in your browser via WebAssembly (~1.7 s). The secret never leaves the tab.

Don't take our word for it — it's all checkable on-chain. Open the pool program ↗, the verifier ↗, or run the full two-layer flow yourself from the app. Nothing here is a promise — it is running right now.

Where we are

The honest current state — not a wishlist.

Two-layer flow + browser-native app, on mainnetdone
  • Wrap → deposit → withdraw to a fresh address → confidential payout → unwrap — verified live
  • Client-side wrap + deposit + withdraw with memo & auditor — the secret and the amount never leave the tab (WASM)
  • Multi-asset: hidden amounts for both USDC and USDT on mainnet
Circuit v2: two structural gaps closeddone
  • Our own security review — before any money sat in the pool — found two gaps in the original withdraw circuit: the recipient was bound by a lossy modular reduction (a hostile relayer could redirect a payout to a colliding address), and the amount lived outside the commitment.
  • The new circuit binds recipient and relayer by their full 256-bit keys and puts the amount inside the commitment with a 64-bit range check. Same prover, same curve — different parameters, hence a fresh ceremony.
Trusted setup ceremony — restarted on circuit v2in progress
  • Public, multi-party generation of the production parameters — this page
  • The six contributions to the v1 circuit are preserved in the public transcript (log, genesis, final state) but do not carry over: parameters are per-circuit by construction. If you contributed before, please contribute again — it takes the same minute.

Verify — don't trust

The server's log is not the source of truth. The published chain is.

The full transcript is public: the genesis parameters and the current chain of contributions. Download both and re-check everything on your own machine — every contribution carries a cryptographic proof of knowledge, and the verifier confirms the whole chain links genesis → … → current with nothing dropped, reordered or tampered:

curl -O https://ceremony.tidex6.com/transcript/genesis.state
curl -O https://ceremony.tidex6.com/transcript/current.state
git clone https://github.com/koshak01/tidex6 && cd tidex6
cargo run --release -p tidex6-circuits --bin ceremony_verify -- ../genesis.state ../current.state

The tool prints an attestation for every contribution — the same hex shown in the list above. Find your wallet in the output and you have independently proven your randomness is part of the final parameters. log.json ↗

How the ceremony ends

Nobody — not even the very last contributor — can bias the result.

1 A future round of drand — the League of Entropy public randomness beacon — is announced in advance. Its value is unknown to everyone while contributions are open.
2 When that round publishes, its randomness is applied as the final, deterministic contribution — through the exact same code path as every human contribution, so anyone can reproduce the step bit-for-bit.
3 The verifying key is extracted from the frozen parameters — byte-reproducible: run the extract tool on the published final state and diff the result against the deployed program.
4 A fresh verifier carrying the ceremony parameters is deployed, source-verified, and its upgrade authority renounced — immutable, exactly like the current one.