VERXConfidential accounts
Your ordinary token account, configured once with your ElGamal public key. Everything after that is the same account you already owned.
Protocol
Solana's cryptography. VERX is the client.
The encryption, the proofs and the rules all live in programs that ship with the chain. What this project adds is a browser that can drive them and a page that will not overstate them.
The stack
Where each part of a confidential transfer happens.
Two of these five layers are this project. The other three are Solana's, and they were running long before VERX existed.
layer 1 of 5
- 01
Browser wallet
yoursHolds the only private key in this picture and signs what you approve. VERX never sees it, never asks for a seed phrase, and has no server to send one to.
- 02
Local key derivation
this tabEighteen fixed bytes are signed once, and that signature derives an ElGamal keypair and an AES key. They live in memory, they are in no store, and a reload asks again.
- 03
ZK proof generation
this tabEquality, validity and range proofs are built here from those keys. This is the slow part of a confidential transfer, and it is the part that never leaves the browser.
- 04
Token-2022
part of SolanaThe confidential transfer extension holds the encrypted balance on your own token account and enforces the rules. VERX deploys nothing: this program is already on both clusters.
- 05
Solana settlement
part of SolanaProofs are verified by the ZK ElGamal Proof program inside the validator, and the transfer confirms like any other transaction. No sidechain, no sequencer, no bridge.
The moving parts
Six things worth knowing before you send.
Pending and available
A credit lands in a PENDING balance that nobody can spend until its owner applies it. That is the protocol stopping a sender from flooding an account, not a delay VERX invented.
ApplyPendingBalance
One instruction, no proof, that folds the pending balance into the available one. It is the step people forget, so the app offers it the moment there is something waiting.
Proof contexts
Small accounts that hold a verified proof so a later instruction can cite it. They are created, used and closed inside the same flow, and their rent comes back.
SPL Record
The largest range proof is too big to verify in one transaction, so it is staged in a record account first. VERX sets that record's authority to YOUR wallet, so an interrupted flow leaves nothing stranded.
Settlement
Ordinary Solana transactions, confirmed the ordinary way. There is no sidechain, no sequencer and no bridge in any of this.
One confidential send, counted
Why it is five transactions and not one.
The proofs are too large to carry in a single transaction, so they are staged first and cited second. These are the figures from a real devnet run, not an estimate.
| flow | transactions | approvals | signatures | fee | rent held, then returned |
|---|---|---|---|---|---|
| Confidential send | 5 | 5 | 9 | 0.000045 SOL | 0.012131 SOL |
| Withdraw | 4 | 4 | 7 | 0.000035 SOL | 0.009200 SOL |
| Shield | 1 | 1 | 1 | 0.000005 SOL | none |
0 transactions in those flows could strand lamports if interrupted: every temporary account is given an authority in the same transaction that creates it, and the planner refuses any plan where that is not true. The first two rows are fees the chain charged, read 2026-10-17; the shield row is one signature at the base rate, which is arithmetic rather than a reading.
Where it runs
Both programs are live on mainnet. VERX is not.
The cryptography this depends on has been running on both clusters for a long time. That says nothing about whether this client is ready, and the two are worth keeping apart.
| program | mainnet | devnet |
|---|---|---|
| ZkE1Gama1Proof111111… | runs | runs |
| TokenzQdBNbLqP5VEhdk… | runs | runs |
| A VERX program | none | none |
read 2026-10-16 · 4 libraries, listed in the footer