Docs menu

CIPHR docs

How it works

One buy becomes one sealed piece, with one extra step from the buyer: sealing it. Five parties touch it in order: the buyer, the pool, the server, the collection, and the wallet the piece lands in, which is the buyer's own, because the buyer is the one who submits it.

Status

The path of one buy

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

The wallet at the end is the same wallet as the buyer at the start, and it is the same wallet that signs and submits in step 4. Nobody else can do that step for you.

  1. The buyer buys. An ordinary swap. The pool sends $CIPHR 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. This authorisation proves the buy qualifies. It does not carry any part of the visor.
  4. The buyer requests a seal and submits. The buyer signs a request bound to the action, body, chain, collection, nonce and expiry. A verified Phala dstack CVM would derive the key, seal the visor and sign the envelope; Chutes provides confidential generation. The buyer wallet sends mintForBuy with the seller authorization and sealed envelope, and pays network gas. These services remain unverified and disabled.
  5. The collection mints, already sealed. It checks the buy authorization and enclave-signed seal, consumes the buy reference, and mints to the buyer. Phala dstack holds the encryption key; the wallet signature authorizes access and does not create that key. Attestation, governance and deployment remain unverified. First-claim enrollment is unfinished, so claims remain closed.

What happens between your buy and your sealed piece

The piece is not part of the buy's own transaction, and it is not automatic. The server waits for two confirmations before it will sign anything, and the sealing and minting step only happens when the buyer's own wallet does it. A buyer can complete that step within moments of the buy, or wait, since the buy itself does not expire; only the server's own authorisation carries the fifteen minute deadline, and a fresh one can be requested again if it lapses.

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."

The wrong wallet submitting. The collection only accepts mintForBuy from the buyer named in the authorisation. A different wallet trying to submit it, even with a valid signature, is refused.

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