How Cloakpad works
Cloakpad explores private payments for the Solana ecosystem, inspired by Zcash’s shielded-payment design. Our goal is to make it easy to understand what you share and who can see it.
What you can use today
The proof lab has three parts: an interactive model of who learns what, locally generated disclosure receipts, and a prover that builds real zero-knowledge range proofs. It all runs in your browser, uses sample information, and makes no blockchain requests. It does not connect a wallet, send funds or encrypt a payment.
A Solana program, a Zcash integration, a bridge, and security audits are not part of this release. The preview ID is a non-cryptographic display value. Shareable receipts use real salted SHA-256 hashes and the range proofs are real Bulletproofs, but none of them is evidence of a transaction or of a real balance.
Open the proof lab →Why Solana?
Solana is the ecosystem we want to build for. Its confidential-token tools can hide amounts and balances, but public accounts can still reveal who participates. Amount privacy and identity privacy are different requirements.
Read Solana’s privacy documentation ↗Why Zcash?
Zcash’s Orchard design separates spending authority from viewing capabilities and uses zero-knowledge proofs for shielded payments. These principles inform our research; this website does not implement Orchard.
Read the Orchard documentation ↗What the disclosure model shows
You know your sample transaction. The recipient knows the payment amount and memo. The network sees the proof statements you select. Public observers see only the details you choose to disclose in this simplified model.
Hiding a recipient means hiding their address from the public, not hiding their own payment from them. Sharing a transaction detail also reveals that the transaction exists. The model always keeps the sender out of the public receipt.
The balance switch models a statement that a balance exceeds 10 SOL. It does not read or check a real balance. Selecting payment proof models a statement about validity; it does not verify a payment. For a real proof of a threshold, use step 4 of the lab, described below.
How shareable receipts work
Each field gets a fresh 256-bit random salt and a SHA-256 commitment using your browser’s Web Crypto API. The exported JSON includes commitments for all fields and values and salts only for the amount, currency, recipient, or memo you choose to share. The sender value is never exported. Hidden values and salts are not saved by this app.
The receipt checker recomputes disclosed commitments and the receipt fingerprint locally. It rejects mismatched values and malformed files. No receipt file is uploaded. Compare the fingerprint through a trusted channel: a self-consistent file alone does not prove who created it, and someone can generate a different valid file.
A receipt is a field-commitment tool, not a zero-knowledge proof, encryption service, wallet signature, or on-chain attestation. The payment and balance toggles are teaching controls and are not included as verified claims in the export. Once a value is shared, it cannot be taken back.
How the range proofs work
Step 4 of the lab proves a statement such as “this amount is at least 100 SOL” without revealing the amount. It commits to the amount in lamports as a Pedersen commitment, V = v·B + γ·B̃, on the ristretto255 group, with a fresh random γ. Because γ is random, V fits every possible amount equally well, so V alone reveals nothing.
To prove “at least t”, it proves that v − t is a 64-bit number, using the commitment V − t·B, which the verifier can compute without knowing v. “Between t and u” also proves u − v, and both ranges travel in one aggregated proof. The proof is a Bulletproof (Bünz et al., 2018): 672 bytes for one range, 736 for two, with no trusted setup. It is made non-interactive with a SHA-512 Fiat–Shamir transcript that includes the claim, so a proof cannot be moved to a different claim.
The verifier checks two equations: that the prover’s polynomial opens correctly at a random point, and an inner-product argument that folds 64 (or 128) committed bits down to two numbers in 6 (or 7) rounds. Both are combined into multi-scalar multiplications and take a fraction of a second. The lab lets you flip a bit, edit the claim or run a cheating prover, and every one is rejected.
The generators are derived from public labels by RFC 9380 hash-to-curve, so nobody knows a relationship between them. “Check the generators” re-derives all 258 in your tab and compares. The curve and hash code is the independently audited @noble library; the protocol code is ours and has not been audited.
What a proof does not show: that the number is a real balance, or who made it. It proves a fact about the number inside V, and here you typed that number. In a shielded pool, V would already be on-chain, and that link is what would make it your balance. A proof can be shared as a file or as a link to /verify. The link carries the proof in its #fragment, which browsers do not send to the server.
What comes before real payments
A defined threat model, a selected protocol, wallet integration, proofs tied to on-chain commitments, and independent security review. Any cross-chain route would also need explicit custody, bridge, and trust assumptions. We have not selected or shipped that route.
Independent by design
Cloakpad is not affiliated with Solana, Zcash, or the Electric Coin Company. “Zcash-inspired” describes the project’s direction, not a partnership or a live integration.