How Locket works, in plain words
This page is the honest one. No marketing, just what's real today and what's still a preview.
The idea
On Unicity, an asset is a self-contained file, and the rules for spending it live inside the file itself. Locket uses that to build possession without power: you hand someone the asset today, and a two-layer rule decides when holding becomes owning. Layer one, your key works always. Layer two, the keys you named start working only after your heartbeat has been missing longer than the window you chose. A heartbeat is a tiny network transaction that costs a fraction of a cent.
Live today vs preview
| Piece | Today | Detail |
|---|---|---|
| Identity and keys | live network | A BIP39 seed and secp256k1 keys, created in your browser by the Sphere SDK. Nametags register on the Unicity network. |
| Test coins | live network | UCT is minted on the network's v2 token engine and certified by it. There's no faucet; you mint your own. |
| Heartbeat | live network | Each tap lands a certified state transition on Unicity's aggregation layer, at an address recipients compute from public facts and signed by a delegated anchor key the deed pins. The beat also publishes to the network relays. If the network doesn't answer, the app records a signed local beat instead and says so. The heartbeat identity is derived from a wallet signature, so any device holding the same wallet rebuilds the same one, and beats from before that scheme keep riding along. |
| The deed inside a .locket file | live network | A real secp256k1 signature by the owner's wallet key over the sealed document, including a hash of every file, note, and secret inside. Recipients verify it offline. Nobody can reword or swap anything without breaking it. |
| File encryption | live network | The payload seals once under a random content key (AES-256-GCM), and that key is wrapped to every wallet key named in the deed (ephemeral ECDH). By default that is the whole lock: the file opens for the named wallets and nobody else, ever, and no passphrase exists. Adding a passphrase door (PBKDF2, 310k iterations) is the opt-in, for recipients without a Locket wallet. A wallet connected through Sphere can't decrypt at all (the Connect protocol never exposes the key), so sealing from one always adds the passphrase door, and no key-only file leaves the seal step unless the maker's own wallet just proved it opens. Nothing readable rests on disk on either side: the maker's device and the recipient's device both keep only the sealed bytes, re-opened when needed. Reworded or stripped headers fail authentication outright. |
| The silence clock | live network | The recipient's client reads two independent sources and verifies both itself: anchored beats on the aggregation layer (checked against BFT inclusion proofs and the network trust base) and signed relay events (checked against the owner key in the document). The clock fails closed: when neither source answers, the locket stays sealed and says so. Nobody has to take anyone's client at its word. |
| The silence window's enforcement | preview | The clock is verified and fails closed, but who may CLAIM, and when, is still checked by the client: the public SDKs don't yet expose time-based predicates, so a modified client could ignore the clock it can now see. Network-enforced predicates remain the roadmap. |
| Taking a locket back | preview | Retiring a locket publishes an owner-signed revocation to the relays and lands one on the aggregation layer under the deed's anchor key. Locket clients refuse a retired file for everyone but the maker, and once a device has seen the revocation it never forgets it. Like the silence window, enforcement on content is the client's; the network-enforced version is the same roadmap item. |
| Claim settlement | preview | Nothing moves at sealing; the deed records the amount. When a named recipient (or the owner) claims, the amount is minted to their wallet through a certified network transaction. Moving the original tokens under a network-enforced predicate is the roadmap. |
| Guardian | live network | The downloadable script signs beats with a delegated heartbeat-only key and, in --relay mode, publishes them straight to the network relay AND lands them on the aggregation layer, where recipients verify them the same way they verify yours. Imported beat files (from the script or the Astrid capsule) reach the relays and the aggregation layer too, the moment they verify. A hosted agent is the roadmap. |
The threat model, plainly
- Someone steals the .locket file. They see random bytes. Without the passphrase or a wallet key named in the deed, AES-256-GCM gives them nothing, not even the label.
- Someone has the file and the passphrase. They can read what it is and who it's for. They still can't claim it: claiming settles to the recipient keys named inside the deed, and the deed can't be reworded without breaking the owner's signature.
- Someone steals your laptop. Everything at rest sits in IndexedDB as AES-256-GCM ciphertext behind your password (PBKDF2, 310k iterations). No password, no keys.
- Someone steals the Guardian key. It can sign heartbeats and nothing else. The damage ceiling is that your lockets stay sealed, which is the safe direction.
- This website disappears. Your files, your keys, and the network remain. The code is open source; run it anywhere.
- Someone steals the file AND the passphrase. A default file has no passphrase at all, so there is nothing to steal beside the file, and the file opens only for the named wallets. When you chose to add a passphrase door, whoever holds file plus passphrase can read the notes and files inside; share it like a house key. The silence window on CONTENT is the client's rule, not cryptography: whoever holds a way in can read early with a modified client. The coins are different: no coin key rides in the file, and claiming settles only to the keys named inside the deed.
- The network goes quiet. The door stays shut. When neither the aggregation layer nor any relay completes a round, the clock refuses to call it silence: the locket shows "couldn't reach the network to confirm" and retries. Only a positive answer, verified beats or a clean none-recorded, moves the clock.
- The honest gap. The clock is verified against the chain and fails closed, but CLAIMING still runs in the client: until time-based predicates land in the public SDKs, a motivated recipient with a way into the file and a modified client could claim early. Weigh what you seal against that, and watch this page.
Why a Guardian doesn't fight the promise
The promise is that a Locket opens only when you truly go quiet. Forgetting a tap on a long trip isn't going quiet; it's life. The Guardian holds a delegated key that can do exactly one thing, sign heartbeats, so the only mistake it can prevent is the accidental opening. It can't spend, can't open, can't seal. If someone steals it, your lockets simply stay sealed, which is the safe direction to fail. And if you're truly gone, the machine running it goes quiet too. It's optional, and you can revoke it with one click.
Passwords, and when there isn't one
The password exists for one job: it encrypts the seed of an identity created inside Locket, on your device. Sign in with your own Sphere wallet instead and there's nothing here to encrypt; the wallet holds the keys and asks for approval in its own window, so Locket never shows you a password screen at all. The passphrase on a .locket file is a different thing: it locks the file itself, and it exists only when you add it. A default file carries no passphrase; the named wallet keys are the whole lock.
What it costs, and who gets paid
The app is free and open source. A heartbeat costs the network's own fee, a fraction of a cent. On top of that, Locket has a keeper's fee: when it's switched on, each heartbeat also sends a few cents to the maker's address. It is off on the current network (UCT has no price yet), it lives in the open code where anyone can read it, and if it ever changes, this page changes first. The plan for later is the same shape: running your Guardian for you, so it never forgets a beat, will be the paid convenience. The security is never the paid part.
Where things run
There's no backend. The app is static files. Your browser talks to exactly three places, all on Unicity's current network (testnet2): the gateway to the aggregation layer (heartbeat anchors go in, BFT inclusion proofs come out), the wallet-api mailbox (delivery only, it never holds your inventory), and the Nostr relays for heartbeats and nametags. When Unicity's mainnet arrives, Locket moves with it. Keys, seeds, and decrypted documents never appear in any request. You can verify that with the network tab open; we did.
Questions the landing page answers in friendlier words live here.