Documentation

Today the pool knows one thing it should not need to know: which receipt matches which exit. Timing, denominations and blinded paths hide the link from outside observers, but the coordinator still settles each exit against a receipt it can see. The fix is to replace “show the receipt” with “prove you own a receipt” — a zero-knowledge proof. This section is the roadmap: what ships first, what follows the Lightning protocol itself, and what waits for research to harden.

Deposits stop issuing a plain receipt and start publishing a commitment — a hash of a secret only you hold. The pool keeps every live commitment in a Merkle tree. The tree is public state; your secret never leaves your device.

At exit you produce a Groth16 proof that says two things at once: your secret sits inside the tree, and its nullifier has never been spent. The proof names neither the secret nor the deposit. The pool verifies the proof and pays out through the usual path — uniform denomination, random delay, blinded route. What changes is what the pool learns: someone with a valid deposit withdrew, and nothing more. Double-spends are still impossible, because the nullifier can only appear once.

deposit   →  commitment = hash(secret, amount, epoch)   →  into the Merkle tree
exit      →  SNARK proves:  "my secret is in the tree"
                            "my nullifier is fresh"
payout    →  pool verifies proof → standard lane → jitter → blinded path
coordinator learns:  a valid withdrawal happened.  nothing else.

The zero-knowledge routes make the coordinator blind. This route makes it unable to steal — and it does not wait for BitVM. Three moves, all buildable on today's Lightning:

Anyone can run a coordinator. The coordinator ships as open source with a one-command deploy. Users pick their coordinator, or spread funds across several running in parallel. A single point of failure becomes a reputation market.

Federated rounds keep the anonymity set whole. Many coordinators would normally split the pool into shallow slices. The counter-design is joint settlement: coordinators merge their commitment trees and settle one shared round, so every depositor mixes against the full network, not one operator's slice.

Funds never sit in a hot wallet. Entries lock inside Lightning HTLCs — and later PTLCs — with a timelocked refund path back to the depositor. The on-chain legs of submarine swaps sit in multisig: 2-of-2 with the user, or k-of-n across the federation. The coordinator's worst possible move shrinks from take the funds to refuse to settle — and even then the refund path pays the depositor back on its own.

Today every hop of a Lightning payment carries the same hash lock, so colluding hops can link the route. PTLCs — point time-locked contracts — replace the hash with an elliptic curve point that re-blinds at every hop. No two hops see the same lock, and the payment stops being traceable through the graph itself.

This is orthogonal to the pool: Route 1 hides who paid whom inside the pool; PTLCs hide the path outside it. The primitive is adaptor signatures, and the work lives upstream in LND and Core Lightning. We track both implementations and adopt PTLC channels as they reach stable releases — no fork, no custom network.

BitVM lets Bitcoin verify arbitrary computation through fraud proofs instead of trusted operators. Applied to the pool, the payout condition becomes objective: release the funds if a valid SNARK exists, and let anyone challenge a false claim on-chain. The coordinator stops being trusted for settlement at all.

The first generation worked but was expensive — challenge transactions of several megabytes.BitVM3 moves the SNARK verifier into garbled circuits evaluated off-chain. The on-chain footprint collapses: an assertion of roughly 56 kB and a fraud proof of roughly 200 bytes — about a thousand times cheaper to enforce than BitVM2. That is what makes trustless settlement practical for the large lanes and the cross-chain gateway.

Route 1 is active engineering — the commitment tree, the nullifier set and the Groth16 verifier are being built and tested on regtest against the same harness that validates the live pool. Route 1.5 is the parallel operations track — open-source coordinator, refund paths, multisig legs. Route 2 is a watch-and-adopt track pinned to Lightning client releases. Route 3 is the long-horizon design track for trustless settlement. Each route strips a different power from the coordinator: its sight, its custody, its cover in the network graph, and finally its role in settlement itself.