Appearance
Veilix Protocol
A non-custodial privacy protocol on Solana. You deposit tokens into a shared pool, keep a secret note, and later withdraw some or all of that note to a different address. A zero-knowledge proof authorizes the withdrawal without revealing which note is being spent. A relayer submits the withdrawal, so the recipient address is not the transaction signer.
Private. Non-custodial. Any amount.
This book explains how the Veilix protocol works: deposits, notes, withdrawals, fees, and relayers. It is the public description of the protocol.
What changed from the fixed-denomination design
Earlier pools only accepted a menu of fixed sizes. Veilix does not. Each asset has one shielded tree, and a note can hold any amount up to that tree’s deposit cap.
| Earlier fixed pools | Veilix now | |
|---|---|---|
| Amount | Chosen from a denomination list | Any positive amount, up to the tree cap |
| Pool | One tree per denomination | One tree per asset |
| Spend | The whole note | The whole note, or part of it |
| Remainder | None | A new change note |
| Note format | Legacy notes | vx2-… notes |
| Withdrawal fee | A single relayer percent | Relayer fee plus an on-chain platform fee |
Legacy fixed-denomination notes cannot be spent on the current program.
The idea in one pass
- Deposit. Address A sends SOL or a supported token into the pool and receives a secret note. The chain stores a commitment, not the secret.
- Hold. The note sits in the same tree as every other note of that asset. You can leave it there for as long as you want.
- Prove. Your device builds a zk-SNARK that says “I know the secret behind one unspent note in this tree,” without saying which note.
- Withdraw. A relayer submits that proof. The program checks it, marks the note spent, pays the recipient, and — if you withdrew only part of the note — inserts a change note for the rest.
The deposit signer and the withdrawal recipient are different addresses, and the proof does not connect them.
One program, one tree per asset
Deposits, partial withdrawals, and Private Send all use the same program and the same asset trees. An observer cannot tell, from the program alone, whether a note was created to sit in a wallet or to pay someone.
Supported assets:
| Asset | Decimals | Where |
|---|---|---|
| SOL | 9 | Mainnet and devnet |
| VEILIX | 9 | Mainnet and devnet |
| USDC | 6 | Mainnet and devnet |
| wBTC | 8 | Mainnet |
| wETH | 8 | Mainnet |
Each asset has its own treasury and its own Merkle tree. SOL notes never mix with USDC notes. Inside one asset, every note shares one anonymity set.
Where to start
| I want to… | Start here |
|---|---|
| Understand why public transfers leak | The Privacy Problem |
| See how Veilix breaks the link | Veilix’s Approach |
| Follow a deposit and a withdrawal | Deposit and Withdrawal |
| Understand amounts, change, and fees | Amounts and Fees |
| See what is still public | What Each Party Can See |
| Send privately from an app | Private Send |
| Protect a note | Note Security |