pocket, the design
the design

How it works, and why it is built this way.

Hiding a number is easy. Hiding it while making it impossible to lie about is the hard part. Here is how that works, and then why we hide the amount rather than the parties.

The mechanism seven steps, from the commitment to the contract The argument why we hide the amount, not the parties The comparison against shielded pools and custody, row by row

What sits on the chain is not a number.

Your private balance is stored as a Pedersen commitment: a point on a curve, computed as C = v·G + r·H, where v is your amount and r is a random blinding factor. Anyone can read C off the ledger. Nobody can work backwards from it. For any point on the chain, every possible amount has a blinding factor that would have produced exactly that point, so it rules nothing out.

v, r

Only you hold the pair that opens it.

The (v, r) that opens a commitment never touches the chain. Your device derives it from your recovery phrase and keeps it locally. That pair is the difference between a balance being yours to spend and yours to look at.

The contract does arithmetic it cannot read.

Add two commitments and you get a commitment to the sum. So the contract credits deposits, debits transfers and folds one balance into another without ever learning a single amount. That one property is what makes the whole thing possible, and it is also why yield and swapping cannot live here: those need multiplication and comparison, and commitments only add.

A proof makes cheating impossible, not just difficult.

Every private transfer carries a cryptographic proof, generated from one of six circuits, that establishes all of this without revealing any of it:

the balance you are spending from is yours
the amount matches what you committed to, and your new balance is exactly the old one minus it
nothing went negative and no value was created, because amounts are held to a fixed range that closes the wrap-around trick
the recipient can actually open what they were sent

The proof is built on your machine.

Generated locally in under half a second. The proving system and its cryptographic reference data ship inside the extension, so nothing is fetched and nothing is uploaded. There is no server of ours that could do this instead.

The chain either accepts it or rejects the transaction.

It arrives at a verifier contract holding six verification keys, one per circuit, written in when the contract was created and impossible to replace afterwards. No partial state, no admin override, nobody in the path.

Your amount is encrypted to exactly the people who need it.

The same transaction carries it encrypted to the recipient, so they can spend it, and to the auditor key each side has bound, so a business can produce a reviewable record. The circuit enforces both: a transfer cannot be built with either one missing or malformed.

consumed
Built on

Pedersen commitments and Poseidon2 encryption, circuits written in Noir, UltraHonk proofs, running on Stellar's Soroban. Confidential token contracts and circuits by OpenZeppelin, audited by OpenZeppelin Security. Proving system by Aztec. On-chain verifier by Nethermind.

ours
Built by us

Everything that makes it a wallet. Key derivation, witness assembly, the encrypted vault, the archive that keeps private balances recoverable, and three Soroban contracts whose job is mostly to refuse things. The wrapper binds one asset and has no admin. The verifier installs six keys and implements no path that can change them. The auditor registry hands out ids in order rather than letting the caller pick one. We deployed our own instance rather than the reference one, whose verification keys predate the audit.

Confidential, not anonymous. And here is exactly why.

Hiding who you pay sounds like more privacy. On a public chain it costs more than it looks. Here is the trade we make instead.

There are two ways to get privacy on a public chain.

Hide who you pay, or hide how much. Hiding who means pooling your money with strangers and withdrawing to a fresh address, so no one can connect the two. That's a mixer. Hiding how much means keeping the names on the record and encrypting the amounts. That's Pocket.

a payment you want private hide who hide how much
hiding who
A POOL
Hiding who is only as private as the crowd.

In a pool you're hidden because you look like everyone else in it. A thin crowd, an unusual amount, or predictable timing narrows it back down to you. Hiding how much gives every user the same guarantee from day one, with no crowd to depend on.

And it needs people you have to trust.

A pool needs a gatekeeper to decide who's let in and to freeze bad actors, which means someone can freeze you. It usually needs a relayer to submit transactions for you, which means someone sees and could block your payments. Pocket has neither. You sign your own transactions, and nobody stands between you and the chain.

a crowd to hide in a gatekeeper a relayer
hiding how much
POCKET
the trade we make
So we hide the number, not the name.

Think of a bank statement, not a numbered account. For payroll, a treasury, or a supplier, the sensitive thing is how much, and the counterparty has to be on the record, because you can't run a business on untraceable money. And your amounts are readable by no one but you, unless you hand over the key yourself. You are your own auditor.

and what stays public
The edges are public, and here they are.

Opening a private balance is public. So is the amount you move in or out, and the account that pays the fee. Every one of them is listed in full, and checkable on chain.

Both go public at the edges anyway.

Money entering or leaving is a visible amount either way. So the pool takes on a crowd, a gatekeeper, and a relayer, and still doesn't hide the boundary.

a pool
Pocket
How strong is it
a poolas strong as the crowd
Pocketthe same for everyone, from day one
Who submits for you
a poola relayer
Pocketyou do
Staying compliant
a poola gatekeeper who can freeze you
Pocketyour own auditor key, no gate
The edges
a poolpublic
Pocketpublic, and we say so
How strong is it
a pool
as strong as the crowd
Pocket
the same for everyone, from day one
Who submits for you
a pool
a relayer
Pocket
you do
Staying compliant
a pool
a gatekeeper who can freeze you
Pocket
your own auditor key, no gate
The edges
a pool
public
Pocket
public, and we say so
for engineers

Three ways to keep money private on a public chain.

Confidential tokens, shielded pools, and custody are three different answers to the same question. This is the trade-off, not a scoreboard.

scroll sideways to compare →
Pocket, the confidential token
Shielded pool
Custodial / off-chain
Model
per-account encrypted balance, a Pedersen commitment C = v·G + r·H
a shared pool of notes + a nullifier set
balances held by an operator; the public ledger shows only deposits and withdrawals
What it hides
amounts and balances
amounts, plus the sender↔recipient link inside the pool
everything, from the public; the activity is off the ledger
Counterparties
on the public record, by design
hidden inside the pool
hidden from the public, visible to the operator
Privacy model
deterministic, the same for every user from day one
an anonymity set, varying with pool size and timing
the operator's private database
Who holds your funds
you (self-custody)
you (self-custody)
the operator
Who can read your amounts
only you (and an auditor key you hold yourself)
only you
the operator, always
Mechanism
UltraHonk proofs (Noir), Pedersen commitments + Poseidon2 encryption
zero-knowledge proofs (Groth16 or UltraHonk)
none, trust replaces proof
Who submits your transaction
you sign and submit it yourself
a relayer, for private transfers
the operator
Compliance
your own auditor key; no entry gate
operator-run allow / deny at the boundary
operator's KYC / AML, with full visibility
Entry & freeze control
none exists, the contracts have no admin
operator can gate who enters
operator can freeze or close your account
Verifiable on chain
yes, every balance is re-checked against the chain
yes, proofs and nullifiers are on chain
no, you rely on the operator's books
Recovery
recovery phrase + a durable archive, re-verified against the chain
note / indexer backup
the operator resets your account
Standard
the confidential-token standard from the Confidential Token Association (SDF, OpenZeppelin, Nethermind)
shielded-pool design (research and reference implementations)
proprietary to each operator
Best fit
accountable privacy: hide amounts, keep parties on record (payroll, treasury, suppliers)
unlinkable transfers where the counterparty must be hidden
users who would rather an operator hold funds and handle compliance for them
Model
Pocket
per-account encrypted balance, a Pedersen commitment C = v·G + r·H
Shielded pool
a shared pool of notes + a nullifier set
Custodial / off-chain
balances held by an operator; the public ledger shows only deposits and withdrawals
What it hides
Pocket
amounts and balances
Shielded pool
amounts, plus the sender↔recipient link inside the pool
Custodial / off-chain
everything, from the public; the activity is off the ledger
Counterparties
Pocket
on the public record, by design
Shielded pool
hidden inside the pool
Custodial / off-chain
hidden from the public, visible to the operator
Privacy model
Pocket
deterministic, the same for every user from day one
Shielded pool
an anonymity set, varying with pool size and timing
Custodial / off-chain
the operator's private database
Who holds your funds
Pocket
you (self-custody)
Shielded pool
you (self-custody)
Custodial / off-chain
the operator
Who can read your amounts
Pocket
only you (and an auditor key you hold yourself)
Shielded pool
only you
Custodial / off-chain
the operator, always
Mechanism
Pocket
UltraHonk proofs (Noir), Pedersen commitments + Poseidon2 encryption
Shielded pool
zero-knowledge proofs (Groth16 or UltraHonk)
Custodial / off-chain
none, trust replaces proof
Who submits your transaction
Pocket
you sign and submit it yourself
Shielded pool
a relayer, for private transfers
Custodial / off-chain
the operator
Compliance
Pocket
your own auditor key; no entry gate
Shielded pool
operator-run allow / deny at the boundary
Custodial / off-chain
operator's KYC / AML, with full visibility
Entry & freeze control
Pocket
none exists, the contracts have no admin
Shielded pool
operator can gate who enters
Custodial / off-chain
operator can freeze or close your account
Verifiable on chain
Pocket
yes, every balance is re-checked against the chain
Shielded pool
yes, proofs and nullifiers are on chain
Custodial / off-chain
no, you rely on the operator's books
Recovery
Pocket
recovery phrase + a durable archive, re-verified against the chain
Shielded pool
note / indexer backup
Custodial / off-chain
the operator resets your account
Standard
Pocket
the confidential-token standard from the Confidential Token Association (SDF, OpenZeppelin, Nethermind)
Shielded pool
shielded-pool design (research and reference implementations)
Custodial / off-chain
proprietary to each operator
Best fit
Pocket
accountable privacy: hide amounts, keep parties on record (payroll, treasury, suppliers)
Shielded pool
unlinkable transfers where the counterparty must be hidden
Custodial / off-chain
users who would rather an operator hold funds and handle compliance for them

How to read it: the tinted column is ours, and the bold cells are where we think the model genuinely wins. Pick the row you actually care about.