Privacy & security
Privacy & security model
Be precise about what is hidden and what is not. PoolPass hides the link between a subscription and an identity. It does not hide the amount, the timing, or the on-chain wallet.
Who sees what
| Value | Investor | Issuer | Contract | Public observer |
|---|---|---|---|---|
| investor_id | ✓ | ✓ | · | · |
| cap | ✓ | ✓ | · | · |
| investor_secret | ✓ | · | · | · |
| leaf | ✓ | ✓ | via root | · |
| merkle_root | ✓ | ✓ | ✓ | ✓ |
| amount | ✓ | ✓ | ✓ | ✓ |
| nullifier | ✓ | · | ✓ | ✓ |
| commitment | ✓ | · | ✓ | ✓ |
| subscribing wallet | ✓ | ✓ | ✓ | ✓ |
What is NOT hidden
The amount is a public input, the commitment over the amount does not hide it. The timing of a subscription is observable. The on-chain identity of the subscribing wallet is visible to everyone. If a wallet is already linked to a real-world identity, the subscription is too.
What the issuer knows
Everything about its own investors. The issuer builds the tree, so it holds every investor_id and cap. The privacy guarantee is against the public ledger and third parties, not against the issuer that accredited you. This is the correct trust model for a regulated pool: the issuer keeps its audit trail.
Cross-epoch linkability
The nullifier is Poseidon2(investor_secret, epoch). Because the secret is folded in with the epoch, an investor’s nullifier in epoch 1 and epoch 2 are unlinkable without the secret, a public observer cannot tell that the same investor subscribed in two different epochs. Within one epoch, the nullifier prevents a double subscription: a replay finalizes FAILED with NullifierUsed.
Security assumptions
- Discrete log on BN254. Groth16 soundness rests on the hardness of the discrete logarithm in the BN254 pairing groups. BN254 targets roughly 100-bit security, adequate for a testnet build, and a known consideration for a mainnet curve choice.
- Poseidon collision resistance. Leaf, nullifier, and commitment integrity depend on Poseidon being collision-resistant over BN254 Fr with the stated round parameters.
- Groth16 trusted setup. This build uses a Phase-1 (powers-of-tau) hackathon setup, not a ceremony-grade Phase-2. A leaked toxic-waste value would let a forger mint proofs. A multi-party Phase-2 ceremony is on the roadmap before any mainnet deployment.
Honest framing
Anyone can verify a subscription; no one is asked to trust the team. The trust you do extend is to the issuer (which accredited you) and to the trusted-setup assumption (which the roadmap addresses with a public ceremony).
Threat model and honest limits
- Self-serve issuer. The accreditation gate is simulated for the demo. In production, the issuer performs real KYC/AML verification off-chain before committing an investor’s leaf to the Merkle tree. The ZK proof verifies membership in whatever set the issuer commits, but the integrity of that set depends entirely on the issuer’s off-chain process.
- Trusted setup. The Groth16 parameters are a test fixture. A mainnet deployment requires a multi-party Phase-2 ceremony (Powers of Tau) to eliminate the trapdoor risk.
- Public amount. The subscription amount is a public input. The commitment records the amount but does not hide it. Anyone reading the ledger knows how much was subscribed.
- Timing correlation. The on-chain wallet address and the timing of subscriptions are observable. The nullifier prevents cross-epoch linkability (it folds in the secret and epoch), but intra-epoch timing is a side-channel leak.
- Issuer centralization. The issuer is a single point of trust for tree commitments. A production system should use a multisig or on-chain governance to limit issuer unilateral power.
- Merkle depth. Depth-3 (8 leaves) is demo scale. Production requires depth 16 to 20. The circuit is parameterized for depth but compiled for 3; scaling requires recompilation and a new trusted setup.