Roadmap
What Voidcash does now, the browser extension planned next, and more assets in the same pool after that.
| Stage | What | In short |
|---|---|---|
| Now | Private SOL | Shield, send privately and unshield SOL from the Voidcash site, with proofs built on your device |
| Next | Voidcash for Chrome | A wallet extension that uses the private balance on any Solana app: each site gets a fresh wallet funded from the pool |
| Later | USDC and more | More assets in the same pool, so what is bought through the extension can come back private too |
Now: private SOL
Everything in these pages: one pool of native SOL, notes that hide amounts and owners, private transfers between
void addresses, and unshields to any Solana address. A share of every pool fee buys and burns $VOID (see
Buyback and burn).
Next: a browser extension
Planned work. The design is a Chrome extension that Solana apps see as an ordinary wallet, with the Voidcash private balance behind it.
Solana apps work with public accounts: a swap or a mint needs a signer with a visible balance. No app can read or spend notes in the pool. So the extension gives each app a session wallet, an ordinary keypair derived from the vault root, and funds it from the private balance:
Connect. The app connects through the Wallet Standard. The extension answers with a session wallet, derived from the root, so it can be recovered from the recovery key like every note.
Fund. The extension proves an unshield to the session wallet and sends it through the relayer. The session wallet receives the amount less the exit fee and the relayer fee.
Use. The app asks the extension to sign. Before signing, the extension simulates the transaction and shows the session wallet's balance changes.
Return. When the session ends, the extension shields what is left back into the pool, with the session wallet as the shield's payer.
An app can only ever reach the session wallet, never the private balance: a malicious site, or a signature the user did not read, can affect at most what the session was funded with.
The pool program needs no change for any of this: transact already pays any recipient, and any wallet can shield.
The extension is a new app on top of the same pool: it adds the session-wallet derivation and a step that sweeps a
session wallet back into the pool.
Questions the design leaves open include one session wallet per site or one for all, whether the return is automatic on disconnect, and what to do with tokens a session bought, which a SOL-only pool cannot take back.
Later: more assets in the same pool
Every note already commits to an asset field, 0 for native SOL (see
Notes). A later circuit with more assets, USDC first, can spend today's notes
as asset 0, in the same tree, without a second verifier or a migration of notes.
What such a circuit adds: asset as a signal in each note, a public input naming the asset that crosses the pool's
edge, and a balance check per asset. It changes the circuit and the program, so it needs a new
trusted setup and a program upgrade.