Privacy
Who sees what
A privacy pool on a public blockchain is not invisible, it is selectively decryptable. Here is who holds which decryption capability, party by party.
Most privacy documentation describes what is hidden. That is the easy half. This page names the parties who can read things, because those are the ones that determine whether the product is right for you.
The five parties
1. You
Your wallet derives and holds your viewing key on your device. It decrypts your notes and authorises spending them. Sealed's app code never receives or stores it.
2. The hosted card account
Card swipes are processed by a hosted account with its own server-held viewing key. It can read every note it owns and every swipe it settles. It cannot decrypt your self-custody wallet's notes - they are different keys - but everything you spend through the card passes through an account the operator controls. This is the custodial exception in an otherwise non-custodial product and it gets its own page.
3. The relayer
Private operations are submitted by a relayer, so the transaction's sender_address is never yours. In exchange the relayer sees the submission itself: the timing, and the IP that asked for it unless you took separate steps about that. It cannot read your note contents.
4. The merchant
A card number and an amount in USDC. Not your balance, not your Starknet address, not your other activity. Without shadow identities, a merchant can link your repeat visits to each other - see the swipe.
5. Anyone with a block explorer
That an address touched the pool and when. Every deposit and withdrawal amount, because those legs are ordinary ERC-20 transfers. The pool fee. The relayer as sender. Nothing about which notes were spent or what remains.
The same thing as a table
| What | Hidden | Public on chain | Readable with a viewing key |
|---|---|---|---|
| Which notes were spent alongside yours | Unlinkable, protected by the anonymity set | not applicable | not applicable |
| Sender and receiver of a private transfer | not applicable | not applicable | Either side’s key |
| Private transfer and spend amounts | not applicable | not applicable | A viewing-key holder |
| Your shielded balance and history | not applicable | not applicable | A viewing-key holder |
| Deposit and withdrawal amounts | not applicable | Always, no key needed | not applicable |
| That an address touched the pool, and when | not applicable | Always, no key needed | not applicable |
| The pool fee, paid in public STRK | not applicable | Always, no key needed | not applicable |
| Transaction sender | Your address is not the sender | The relayer’s address is | not applicable |
The anonymity set is not infinite
“Unlinkable” means unlinkable within the set of notes that could plausibly have been the one spent. On a testnet pool with few participants, that set is small. Privacy from an anonymity set is a function of how many other people are using it, and no amount of cryptography changes that.
Showing someone one payment
Because one key both reads and spends, there is nothing safe to hand over. The mechanism instead is a scoped statement for a single authorization:
GET /api/card/statement?authorizationId=…returns the settlement with amounts omitted.- With
&full=1and the viewing key, it returns the full record: the merchant transaction, the settled amount, and any position opened by the same invoke. - Scope is per authorization. It is not a key to your history.