Who Can Decrypt What
ZK Stables use encryption in several places. The important question is not only "is this encrypted?", but "who can decrypt it, under what conditions, and why?"
User balances
Encrypted balances are encrypted to the user's encryption public key (EPK).
To read a balance, the SDK:
- reads the ciphertext from the token contract
- decrypts it locally with the matching encryption secret key, usually through a read account that holds the encryption secret key needed for decryption, but not controller signing authority
- uses the solver to recover the integer token amount from the decrypted curve point
In the standard SDK flow, decryption happens locally. No plaintext balance is sent to the chain.
Read capability is separate from spend or controller authority. A read account can decrypt the user's encrypted balance without being able to transfer, approve, or otherwise control the funds.
Why balance decryption needs a solver
In normal operation, the SDK decrypts the balance ciphertext and recovers the token amount for display and local checks.
Under the hood, ZK Stables use exponential-form ElGamal. Decryption recovers a curve point that encodes the amount, not the integer amount directly. The SDK then solves for the integer amount.
For arbitrary curve points, this would be the general discrete-log problem and would be infeasible. ZK Stables only need the bounded case: token amounts are finite and much smaller than the full curve size.
Compliance ciphertexts
Some operations hide amounts from the public chain but still need a controlled disclosure path. For this reason, encrypted transfers, mints, and burns attach an additional compliance ciphertext. Operations whose amounts are already visible on-chain — public-to-encrypted and encrypted-to-public conversions, and public mints and burns — do not need one. In the future Shielded layer, the same mechanism extends further: any information that is no longer visible on-chain will be carried inside the compliance ciphertext.
Guardian Committee
The compliance decryption capability is controlled by a Guardian Committee.
At a high level:
- the compliance public key is available on-chain
- hidden-amount operations encrypt a payload to that key
- guardians hold shares of the corresponding decryption capability
- no single guardian is able to decrypt alone
- disclosure requires the controlled committee process
The cryptographic shape is threshold decryption. Participating guardians produce verifiable decryption shares for a ciphertext. Invalid shares are rejected. Once enough valid shares are available, they can be combined to recover the plaintext amount.
This lets the process reveal an authorized plaintext without giving any one party unilateral access to private data.
The point here is the cryptographic control: encrypted payloads exist on-chain, but decryption is gated by committee cooperation.
Encrypted supply
Supply also has a private accounting problem. The system needs auditability and compliance reporting without making every private supply-changing event public.
A normal ERC-20 totalSupply() is public. In a private system, every encrypted mint or burn amount being public would leak sensitive issuance and redemption data.
ZK Stables maintain an encrypted total-supply counter. Mint operations add to it, and burn operations subtract from it, while preserving privacy for encrypted mint and burn amounts.
Public mint and burn operations update the counter with public deltas. Encrypted mint and burn operations update it with ciphertexts whose correctness is proven by ZK circuits.
An authorized holder of the supply decryption key can decrypt the counter for reserve reporting. This can happen periodically or on request, depending on the reporting process. The result supports supply and reserve checks without exposing each private mint or burn.
Who learns what
| Data | Public chain | Matching ESK holder | Guardian Committee | Supply key holder |
|---|---|---|---|---|
| Public ERC-20 balance | Visible to everyone | Visible to everyone | Visible to everyone | Visible to everyone |
| Encrypted balance amount | Ciphertext only | Decrypts locally | No balance-decryption capability | No balance-decryption capability |
| Encrypted transfer amount | Ciphertext only | Sender knows the submitted amount; recipient can decrypt the recipient-side ciphertext | Only through the compliance payload | No transfer-decryption capability |
| Compliance payload | Ciphertext only | Not needed for normal use | Can recover the hidden amount through threshold decryption | No compliance-decryption capability |
| Encrypted total supply | Ciphertext only | Not a user balance | No direct decryption capability | Can decrypt the encrypted counter for reserve reporting |