Placeholder ticker · no token exists
See everything. Spend nothing.
// one-way glassread ✓ · spend ✗
The view key lets someone read the ledger. The spend key never leaves you.
// working demo
Give an auditor the glass, keep the key.
1 Owner wallet private
Two independent keypairs, generated right here. The spend key is created non-extractable: this page cannot even export it.
Spend key · ECDSA P-256can sign
not generated
Public half shown. Private half stays inside the browser's crypto engine.
View key · ECDH P-256can decrypt
not generated
2 Owner activity private
Receiving only needs your public view key, so anyone can send. Spending needs a signature from the spend key.
Each entry is encrypted to the current view key with a fresh ephemeral ECDH key, then AES-GCM. Spends also carry an ECDSA signature from the spend key.
3 What the public chain shows everyone
Anyone can read this. Amounts and memos are ciphertext. Anyone can also check each spend's signature against the public spend key.
| # | Kind | Ephemeral key | Ciphertext | Amount / memo | Spend signature |
|---|
4 Auditor read-only
The owner shares the view key. The auditor decrypts the whole history, but the spend key was never in the package.
| # | Kind | Amount | Memo | Time | Spend sig vs spend pubkey |
|---|
Balance the auditor can compute
locked
Generate a wallet, add activity, then share the view key.
// how it works
Two keys. Two very different powers.
Peekkey separates the right to read from the right to move. That is the whole idea, and the demo above implements it with real primitives.
The view key can
- Derive the AES-GCM key for every note encrypted to it, via ECDH then HKDF.
- Read amounts, memos and timestamps for the whole history.
- Check each spend's signature against the public spend key, and compute a balance.
The view key cannot
- Produce a signature that the ledger accepts. Only the spend key's signature verifies.
- Be turned into the spend key. They are independent keypairs.
- Hide history it already read. Disclosure is permanent for everything encrypted to it.
- Generate. A spend keypair (ECDSA P-256, non-extractable) and a view keypair (ECDH P-256).
- Encrypt. For each entry, an ephemeral ECDH key is combined with the view public key; HKDF-SHA-256 turns the shared secret into an AES-256-GCM key. The entry's id, kind and view-key id are bound in as authenticated data.
- Authorise. A spend entry is signed with the spend key over (entry id, ciphertext). Anyone verifies it with the public spend key.
- Disclose. Exporting only the view private key to the auditor lets them decrypt everything addressed to it.
- Attempt to spend. Even the auditor's best forgery, signing with the view key's own scalar, verifies only under the view key, not the spend key the ledger requires.
| Aspect | This demo | Real shielded-pool view keys |
|---|---|---|
| Key relationship | Two independent random P-256 keypairs. | Typically derived from one root secret in a one-way manner. |
| Addressing | Notes are encrypted directly to the view public key. | Stealth or diversified addresses, so recipients can't be linked on-chain. |
| Validity | An ECDSA signature stands in for spend authorisation. | Zero-knowledge proofs of ownership and balance, nullifiers against double spends. |
| Where it runs | One browser tab. No chain, no network. | On-chain protocol with a consensus layer. |
Known limitations — please read
- This is a model, not a protocol. The “ledger” is an array in your tab. There is no chain, no consensus, no double-spend protection, and no stealth addresses.
- Disclosure cannot be undone. Anyone who ever held the view key can decrypt every note encrypted to it, forever. Rotating the key protects only future entries. Try it above.
- The auditor sees your counterparties' data too. Amounts and memos for every entry are exposed, including for people who paid you.
- Metadata is not hidden. Entry count, kind (in or out), size and ordering are visible to everyone. Ciphertext length leaks roughly how long a memo is.
- Reduces linkability, not anonymity. A view-key design controls who can read; it does not make a user anonymous or untraceable.
- Unaudited, demo-only. No third-party audit exists, nothing touches mainnet or real funds, and the cryptography is assembled for illustration from browser primitives.
- Use lawfully. You are responsible for complying with the laws and tax rules that apply to you.