Prove you qualify. Keep your wallet private.

Zero-knowledge eligibility without sharing your portfolio with the app.

Your eligibility travels. Your portfolio does not.

Issuer verifies eligibility. Apps receive a proof.

Private access

An app can learn that you qualify
without seeing your portfolio.

Eligibility checks today ask for a wallet connection, and a wallet connection hands over an address — and with it every balance, position and counterparty attached to it. VeilPass takes a different approach: the check happens once with an issuer, and the app receives a proof instead of your portfolio.

  1. Control

    You prove control of your wallet to an issuer. This step is between you and the issuer — the app is not part of it.

  2. Credential

    The issuer checks the eligibility condition at a defined time or snapshot and issues a short-lived credential describing only that condition.

  3. Proof

    Your device generates a zero-knowledge proof over the credential, bound to the requesting app and to a session challenge.

  4. Access

    The app verifies the proof. It never receives the credential, your address, or your balances — only the answer to the question it asked.

The protocol

What the proof
does and does not say.

Privacy claims are only useful when their edges are drawn. These are the boundaries the application is built around.

The issuer still sees the wallet
Eligibility is verified against a real address, so the issuer knows which wallet was checked. The design hides the wallet from the app, not from every party.
The chain stays public
On-chain activity, timing and reuse of the same wallet can still correlate. A proof narrows what is disclosed in a flow; it does not erase a public ledger.
A credential describes a moment
A credential reflects the condition at issuance or at a snapshot. Assets moved afterwards are not retroactively reflected, which is why expiry and revocation have to be defined, not assumed.
Zero-knowledge is not a synonym
Zero-knowledge does not by itself mean trustless, anonymous, Sybil-resistant or compliant. A trusted issuer combined with a ZK presentation is still a trust assumption worth naming.

Developers

A working proof flow.

The application combines wallet signatures, an on-chain balance check, issuer-signed credentials, browser proving, and server verification. Open VeilPass to test eligibility and register a Zcash reward destination. Token, reward amount and live campaign details are not yet set.

  • Issuer-signed credentials expire within 10 minutes. A wallet signature binds each request to a fresh holder commitment.
  • A Circom circuit checks the issuer signature, the balance threshold and a holder secret. Groth16 proofs are generated in a browser worker.
  • Each proof is bound to an application and a one-time, browser-bound challenge. Replayed or mismatched proofs are rejected.
  • An off-chain verifier opens Zcash reward registration after proof verification. A stable campaign nullifier prevents another registration from the same eligible wallet.
  • Robinhood faucet tokens let you test eligibility without real funds. Public deployment requires an independently reviewed setup and security review.

Docs

Built to disclose less.

The proof demonstrates eligibility under a trusted issuer. It does not make a public chain private or hide network metadata.

StageRobinhood Chain testnet — real cryptographic proofs.

BuiltWallet eligibility, browser ZK proofs, Zcash address validation and persistent preview registrations.

Before launchIndependent ceremony, security audit, production issuer operations and durable session infrastructure.

OpenLive chain, asset and threshold; revocation policy; independent issuer and app operators.

The current test policy is a placeholder for our future token. Prove eligibility, then enter your Zcash address. Preview registrations do not send or guarantee ZEC. The issuer sees the EVM wallet, and the reward service stores your Zcash destination.