Docs menu

CACHET docs

How it works

One qualifying buy becomes one sealed piece, and every sealed piece is identical. Five parties touch a buy in order: the buyer, the pool, the server, the buyer again (this time claiming), and the collection, which mints straight back to the buyer's own wallet. A separate, later step, the round, is what opens the whole collection at once.

Status

The path of one buy

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

The wallet at the end is the same wallet as the buyer at the start, the one that sends the claim in step four and pays its own gas.

  1. The buyer buys. An ordinary swap. The pool sends $CACHET 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 claims. Open Get my pieces, connect the wallet that bought, and send the claim. The contract requires the caller to be the named buyer, so nobody else can spend this authorisation, and the buyer's own wallet pays the network fee. One lifetime claim per buyer.
  5. The collection mints, sealed. It checks the signature, marks the buy reference and buyer used, and mints to the buyer's wallet. The sealed image is identical across pieces. The producer may know the collection seed and could calculate traits before reveal; no holder preview service is active.

What happens at the round

The planned seal derives a seed from a Chutes confidential model response and a local nonce, then encrypts it to a pinned drand quicknet round with tlock-js. A seed hash, ciphertext hash, attestation hash and manifest hash are fixed in the constructor when the first claimer publishes the collection. That can be later than offline seal creation. Chutes evidence and inference output binding are unverified, so publication currently fails closed. The producer may know or leak the seed.

After round R and its 120-second margin, anyone who decrypts the published ciphertext can prepare a revealSeed(seed) transaction. The contract accepts the first seed matching its stored commitment. Someone must send that transaction and pay gas. The chain does not verify drand or TEE proofs.

The moment that transaction lands, every piece in the collection opens at the same block, because they all read from the one revealedSeed the contract now stores. Each piece's own traits still differ, since they are computed from that shared seed combined with the piece's own pool, buyer, token id and amount, the same four fields that sealed it in the first place.

What "moments after your buy" means

The piece is not part of the buy's own transaction. The server waits for two confirmations before it will sign anything, and the claim itself is a separate transaction the buyer sends. In normal conditions a buyer can claim within a minute of the qualifying buy, but there is a real gap, and during it the wallet holds the token and not yet the piece.

What can make a claim 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, and every buyer can claim once, for life. If the same transaction is submitted again, or the same wallet tries a second claim, the collection's own usedBuy and claimedBuyer mappings and the server's own check all refuse it.

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