Keys and the scan model
Jat splits your identity into a scan key and a spend key. The split lets a service help you find payments without ever being able to move them, and it means no operator holds a key to your funds.
Scan key and spend key
- Scan key recognizes which on-chain payments are addressed to you. It is a read capability. With it you can detect funds, but you cannot spend them.
- Spend key reconstructs the private scalar of a one-time address and authorizes moving its funds. It is the spending capability.
Your shareable payment link carries only the public halves of both keys. Anyone can pay you from it; only the holder of the private halves can find and claim what arrives.
Why the split matters
Because scanning needs only the scan key, an indexer can hand you the raw stream of announcements and let your browser do the matching locally, instead of you handing a service a key that can spend. The result is the property Jat leans on everywhere: no operator, indexer, or relayer ever holds something that can take your money.
The pool uses its own per-deposit secrets
Funds you move into the fixed-denomination pool are not guarded by your scan and spend keys. Each deposit has its own random nullifier and secret generated at deposit time. Those two values are what you use to withdraw later, and Jat shows them once so you can save them. Losing them means the deposit cannot be withdrawn by anyone.
What each party can see
| Party | Sees | Can spend |
|---|---|---|
| Indexer | Public announcements and deposit leaves | No |
| Relayer | The transaction it pays the fee for | No |
| You (scan key) | Which payments are yours | No |
| You (spend key) | Which payments are yours | Yes |