Why zero-knowledge fits

Accreditation is a yes/no fact backed by private data. A zero-knowledge proof carries the yes without the data, which is exactly the shape of the problem.

The friction it removes for investors

Today an investor proves they qualify by disclosing identity and net worth to each issuer, who stores it. PoolPass replaces the disclosure with a proof. The investor computes Poseidon3(investor_id, cap, investor_secret) once, hands the issuer only that leaf, and from then on proves membership without re-revealing anything.

The audit trail it preserves for issuers

The issuer keeps everything it needs. It built the tree, so it can map any leaf back to a real investor for its own compliance. The public ledger, meanwhile, holds only nullifiers and commitments. A regulator can be shown a proof that every subscriber was authorized, without a public roster of who they are.

What each party learns

• The issuer learns nothing new at subscription time, it already knows its investors.
• The contract learns that a valid member subscribed a public amount in this epoch, and that the nullifier is fresh.
• A public observer learns a wallet subscribed an amount, plus an opaque nullifier and commitment, and cannot link the subscription to an identity or across epochs.

The proof is the contract between these three views: it lets the contract enforce the issuer’s rule while showing the public almost nothing. That is the property no plaintext allowlist can offer.

Why not just a private allowlist?

A contract could hold a list of approved addresses and check membership directly. That fails for three reasons. First, the list is public on chain, so every approved investor is exposed by address. Second, it binds approval to a wallet, so an investor cannot rotate keys or use a fresh address without re-approval. Third, it leaks the size and composition of the issuer’s book to competitors. A Merkle root plus a proof removes all three: the on-chain state is one hash, approval is bound to a secret rather than an address, and the book stays private.

What “zero-knowledge” means here

A zero-knowledge proof has two properties that matter for this product. It is sound: a false statement cannot produce a passing proof except with negligible probability, so the contract can trust a proof it verifies. It is zero-knowledge: the proof reveals nothing beyond the statement’s truth, so the four public inputs are the only thing an observer learns. PoolPass uses these to turn “this person qualifies” into a value a contract can check without the person behind it.

What it does not fix

Zero-knowledge hides the link between a subscription and an identity. It does not hide the amount, which is a public input, nor the timing, nor the wallet that submits. If a wallet is already tied to a real identity, the subscription is too. The privacy and security page is explicit about every one of these boundaries.