LOCKET plans one piece per qualifying buyer. The browser encrypts a random charm for a Lit action bound to immutable code. That action is intended to check the current holder before returning an encrypted key. The same ciphertext stays with the piece on transfer. Live Lit access and ZEC payment are unverified and disabled.
Status
The three-step picture
You buy the token from the pool.
You seal it: the server proves the buy and signs an authorisation, then you sign once more and submit the mint yourself.
You hold the piece. It lands the moment your own mint transaction confirms, not automatically after the buy.
Read next
Each page stands on its own, but they read best in order.
How it works: the path of one buy and one self-claimed mint, step by step, with a diagram of the buyer, the pool, the server, the collection and the buyer's own wallet again at the end.
The piece: the anatomy of a piece and every option of every trait, drawn to scale.
Rarity: the five weight tables, how 1 in N is worked out, and a calculator you can play with.
Contract: for developers, the functions, events, errors and the EIP-712 signing shape.
Keeper: how the signing route proves a buy, why LOCKET has no keeper minting on your behalf, and what happens when the route itself fails.
FAQ: short, plain answers to the questions a buyer asks first.
Brand: the name, the mark, the colours and the type.
What LOCKET is not, yet
Limit
No contract is deployed. No token, pool or collection address is published. Every number on these pages that looks like a real result is computed live from the same arithmetic the eventual contract uses, on example fields, never on a real buy.