Docs menu

LOCKET docs

How it works

One buy becomes one piece, but LOCKET needs one more step from the buyer than a plain swap does: sealing their own hidden trait. Five parties touch a claim in order, with the buyer appearing twice: the buyer, the pool, the signing server, the collection, and the buyer's own wallet again at the end, since only that wallet can make the seal and send the transaction that finishes the mint.

Status

The path of one buy

1 buys 2 sends 3 reads, signs 4 seals, submits 5 mints Buyer Pool Server You Collection Wallet

The wallet at the end is the same wallet as the buyer at the start, and it has to be: the contract only accepts the credited buyer as the sender of their own mint.

  1. The buyer buys. An ordinary swap. The pool sends $LOCKET to the buyer's wallet, which the token contract records as a Transfer log with the pool as the sender.
  2. The pool's transfer is the proof. Nothing about the buy is trusted from outside the chain: the only evidence that matters is that exact log.
  3. The server reads and signs. It reads the transaction's receipt back from the chain, insists it succeeded with at least two confirmations, finds the token's own Transfer log with the pool as sender and an amount at or above the collection's minimum, and only then signs an EIP-712 MintAuthorization naming the buyer, a buy reference, the amount and a fifteen minute deadline.
  4. The buyer encrypts and submits. The browser creates a random charm and AES key, wraps the key for the immutable Lit action, and submits the encrypted envelope and signed mint authorization. This path stays paused until Lit setup is verified.
  5. The collection mints. It checks the signature against its own signer, marks the buy reference used and the buyer's address claimed before anything else happens, computes the seed for the piece's public face from the pool, the buyer, the swap number and the amount, and stores the sealed commitment and ciphertext against the new token, minted straight to the buyer's own wallet.

What "moments after your buy" means

The piece is not part of the buy's own transaction, and for LOCKET it is not automatic either. The server waits for two confirmations before it will sign anything, and the buyer still has to come back, sign once to seal their trait, and send the mint themselves. In normal conditions that second step takes moments, but there is a real gap, and until the buyer acts, their wallet holds the token and not yet the piece.

What can make a mint not happen

Limit

A buy under the minimum. If the amount is below the collection's minBuy, the server refuses with "buy under the minimum" and nothing is signed.

A transfer that is not from the pool. A wallet-to-wallet transfer, a transfer of a different token, or a transfer into the pool never qualifies. The server only ever signs for a Transfer whose sender is the pool address.

A replay. Every buy reference can be used once. If the same transaction is submitted again, the collection's own usedBuy mapping and the server's own check both refuse it as "that buy already has its piece."

A wallet that already claimed. LOCKET mints once per buyer address, for life. The collection's own claimedBuyer flag refuses a second claim from the same wallet even with a fresh, valid authorisation for a different, later buy.

What the buyer sees in each case is the same thing: no second piece, and no error to act on. A buy that never qualified never had a piece coming; a buy that already has its piece, or a wallet that already claimed once, will not get a second piece no matter how many times the mint is submitted.

Opening the sealed trait later

The current holder signs a short lived request. The Lit action checks current ownership, ciphertext and commitment through its pinned Robinhood Chain RPC, then returns the key encrypted to the holder browser. Live execution is unverified.

Transfer preserves the exact ciphertext and commitment. A former holder may retain a charm or key already opened.