Privacy Model
ZK Stables are built around the idea that privacy is not a single switch. Different users and different transactions need different things hidden, so the protocol exposes privacy as a set of progressive layers. Each layer keeps the same underlying assets but changes what an outside observer can see, letting users choose the level of disclosure that fits the use case.
Public layer
At the base, ZK Stables behave like a standard ERC-20 token. Balances, transfers, senders, recipients, mints, and burns are all visible on-chain, exactly as they would be for any other ERC-20.
This transparency is deliberate. It is what makes the asset interoperable with wallets, exchanges, payment processors, and DeFi contracts that expect normal ERC-20 behavior. The public layer is the compatibility surface — the part of the system that the rest of the ecosystem can interact with without any awareness of privacy features.
Encrypted Balances layer
The Encrypted Balances layer sits on top of the public layer and hides values while keeping accounts visible. Each account has an encrypted balance, and transfers between encrypted accounts conceal the sensitive numbers while leaving the surrounding transaction structure intact.
Specifically, an encrypted transfer hides:
- the sender's balance
- the recipient's balance
- the transfer amount
Examples of what the chain still sees include structural information around the transfer:
- which encrypted account sent
- which encrypted account received
- that a transfer happened
- when it happened
Put differently: at this layer, encrypted transfers hide how much moved, not that something moved.
In practice, this covers many of the sensitive details that public ledgers tend to leak: account balances, payment sizes, payroll amounts, big treasury movements, operator volumes, and customer concentration by value. These are the details businesses and individuals are usually most concerned about.
What the layer does not provide is anonymity, as it does not obscure the transaction graph. If an observer already knows that encrypted account A belongs to Alice and B belongs to Bob, they can see that A sent to B — they simply cannot see the amount or the resulting balances. This makes Encrypted Balances a strong fit when amount privacy is the primary concern and when the participants involved already know one another: payroll, B2B settlement, treasury operations, and similar flows where identities are not secret but financial details should be.
Shielded layer preview
The Shielded layer extends the model to additionally hide transaction links and accounts. Funds change hands within the same privacy pool rather than between visible encrypted accounts, breaking the direct relationship between sender and recipient.
At this layer, an outside observer sees deposits into the common privacy pool and withdrawals out of it, but cannot tell which deposit funded which withdrawal, who transacted with whom inside the pool, or what amounts moved. Sender, recipient, and value are all hidden; only the fact that the pool exists and that activity is happening within it remains public.
See Shielded Layer Preview for details.