mirror-pool: two-path behavioral anonymity pool (synchronized crowd + ZK-deniable initiation)

[marcelofeitoza]

What this is

mirror-pool makes on-chain activity hard for automated chain-analysis to read. It offers two settlement paths with deliberately different strengths, plus an optional confidential-value layer:

• Crowd path (Commit / SettleEpoch) - N identical actions settle atomically in one transaction on one timestamp, paid by a rotating gasless relay. Each participant signs their own action, so this path does not hide the on-chain signer. What it destroys is the per-actor signal (timing, ordering, size, gas payer, fingerprint, parseable intent), which is what defeats copy-trading and FIFO temporal matching.
• ZK opt-in path (CommitDeposit / SettleZk) - this is the one that hides WHO. A Groth16 membership proof is verified on-chain and the escrow is released with no participant signature at settle.
• Confidential-value layer (InitValuePool / Transact) - a 2-in/2-out Tornado-Nova JoinSplit that hides HOW MUCH. Note amounts and internal transfers are hidden; shield, unshield and pool TVL remain public.

Clean-room, MIT, Rust. Proving runs in-process in pure Rust (ark-circom / ark-groth16, no Node); circom is still required at build time to produce the artifacts.

Verify in 2 minutes

• Program on public devnet: EezWdFrmHtR2PCuucUruvkgyB9HW3w2KskZNeYmXszBq
• Live soaks, every assertion on-chain: behavioral 17/17, confidential 25/25, funding-round 25/25, with signatures and CU in docs/PROOF.md
• Membership settle: 102,115 CU, 4 public inputs (the JoinSplit is a separate instruction with its own verifying key at ~197k CU, 7 inputs)
• 262 host tests, 99 on-chain program tests, design paper at paper/mirror-pool.pdf

The deployed program predates the verifying-key registry, and reproducing the ZK,
confidential and funding soaks on a public cluster is currently blocked on funding.
All three of those drivers publish their key through InitVk before they settle, which
the deployed bytecode does not have. The current build is 119,072 bytes and needs about
0.83 SOL of rent to deploy or stage, and the devnet faucet is refusing this address.
The captured results are unchanged and are labelled historical in docs/PROOF.md; the
crowd path is byte-identical source between the deployed commit and HEAD, so those
assertions carry over. Until a redeploy is funded, treat the ZK, confidential and
funding evidence as local Surfpool evidence.

What is here

• Multi-party trusted-setup ceremony (docs/CEREMONY.md) - phase-2 delta re-randomization, a Schnorr proof of knowledge bound to the contributor id, the chain position and the step's kind and provenance, SHA-256 transcript chaining, an enforced beacon-is-final rule, and reproducible verification that rejects tampered deltas, forged or replayed proofs, reordered and truncated chains, post-beacon steps and relabelled beacons - each with its own test. Demo transcripts committed under docs/ceremony-run/.
• Opt-in association-set proofs (docs/COMPLIANCE.md) - Privacy-Pools-style: prove your deposit is in a curator's curated set without revealing which deposit, enforced on-chain in the execute path. Opt-in per settlement rather than per pool, so a curator can decline to vouch but cannot block anyone from settling.
• Funding-provenance mechanism, wired and soaked - commit wallets are funded by an unshield out of the value pool in denominated, batched rounds. Proven live: each fresh commit wallet's only inbound transfer is the pool vault, and each funding transaction carries exactly one signature, the relay's.
• Write-once, digest-pinned verifying-key registry - each circuit's key lives in a program-owned PDA at seeds = ["vk", circuit_id], installed by a single InitVk instruction with no update path, no authority field and no admin. The stored bytes must hash to a digest the program pins at compile time, checked at install AND recomputed on every verify, so an arbitrary key cannot be installed even though installation is permissionless. That pinning is what makes a PDA-stored key safe rather than a liability.
• Arkworks-native membership circuit (docs/ARKWORKS.md) - an additional Rust-only constraint-synthesis path with an in-circuit Poseidon gadget, cross-checked against the native hash and the sol_poseidon syscall. It does not replace the circom path and does not change any program logic. Honest scope: it verifies through the groth16-solana verifier crate in a host test, not as a landed SettleZk, because a different constraint system means a different key and the program pins the circom key's digest.
• Effective-k measured, not assumed (docs/EFFECTIVE_K.md) - see below.

Anonymity, measured rather than assumed

An earlier revision of this branch modelled all participants as a single provenance class and then concluded effective-k equalled nominal, which was circular. That is replaced, and the honest numbers are lower. At nominal k=32, Shannon effective-k against a joint deposit-to-withdrawal matching adversary:

funding approach	effective-k	retention
public funding edge (baseline)	7.51	23.5%
pass value through the shield only	7.66	23.9%
fixed denomination only	10.19	31.8%
batched rounds only	10.93	34.2%
denomination + rounds, enforced rules alone	24.25	75.8%
denomination + rounds + two rounds of voluntary dwell	28.80	90.0%

24.25 is what the protocol enforces on its own. 28.80 additionally assumes full adoption and participant dwell, which the protocol recommends but cannot enforce. Each mitigation alone is close to useless; they only work composed. Adoption is the binding constraint: at 50% adoption the same configuration measures 42.4% of nominal, and one direct top-up returns the worst case to 1.00.

Known limitations, stated plainly

• The ZK escrow is a pool-wide pot (soundness). No on-chain check ties a settled amount to any single deposit, and because crowd Commit and CommitDeposit produce identically-shaped leaves in one accumulator, a fee-only crowd commit can spend another participant's escrow. This is pinned by a passing test (settle_zk_escrow_is_a_pool_wide_pot_any_leaf_can_spend). A v1 pool must not hold value it cannot afford to lose. The fix (domain-separated leaves plus per-deposit accounting or a fixed denomination) is roadmapped and not in this branch.
• SettleZk enforces no k-floor, no denomination and no recipient freshness. Its anonymity set is the window's ZK deposits of the same amount, and the program will settle into a set of one. The floor is a client check (mirror-cli prove refuses below k_floor unless waived) because the ZK escrow has no refund path and an on-chain floor would strand it. "Settles to a fresh address" is a client convention, not a program property.
• No production ceremony has been run. The machinery exists and is tested, but the committed and deployed verifying keys still come from the insecure dev setup. The local demonstration reports 1 independent contributor from 4 steps, which is the self-run refusal working.
• Effective-k is a model over synthetic populations; the funding trace is modelled, not read off a chain, and the Sinkhorn step is an approximation rather than a bound (a counterexample is pinned in a test).
• Public devnet, not mainnet-beta. Anti-Sybil is economic, not cryptographic. Research-stage; not audited.

Reproduce

cargo test --workspace
cargo build-sbf --manifest-path programs/mirror-pool/Cargo.toml
cargo run -p mirror-harness --release      # attack table + effective-k tables