ACTIVITY
The statement of the account, and how it lives on a server that cannot become a list of who holds Zcash.
ACTIVITY is the statement of the account. One list, sorted by date, holding what this wallet did rather than what somebody asked it to do.
The chain is the history. This is the part a light wallet cannot re-derive: outgoing payments, and everything that happened off the chain at a merchant.
What is on it
| Entry | What it records |
|---|---|
| A shield | Transparent funds moved into the pool, and where they came from. |
| A payment | ZEC that left the pool, and the address it went to. |
| A purchase | What was bought and where it works, which is the only record of it anywhere. |
| An issued card | An eSIM that exists, with an anchor and no amount. A card the account holds is a thing the account did. |
Why a server holds it
The wallet travels and its history did not. The seed derives from the login, so the same person signing in on a second device gets the same wallet and the same balance. What they do not get is any record of what they did, because a row in one browser's storage reaches one browser on one machine.
This project also holds that a table joining a public identity to shielded funds is a list of who holds Zcash. Building one would be worse than the problem it solves, so the store cannot become that list.
| Decision | What it prevents |
|---|---|
| The key comes from the seed | An Ed25519 public key the wallet derives, not the Privy identity, the Solana account or the Zcash address. Nothing here joins to a person. |
| Every field is ciphertext | Figures, addresses, transaction ids and product names are all sealed with a key the server never sees. What stays in the clear is an opaque identifier, a six-value kind, and a timestamp. |
| There is no account to create | No session, no password, no sign-up. The key is the account, so possession is the only credential and there is nothing stored worth stealing. |