Docs menu

SHRIVE docs

How it works

Payment release blocked

This source targets the NU6.3 Ironwood pool and a signature claim that keeps the saved code private. The ZEC API is hard closed. Do not send payment. Rust compilation, live Ironwood receipt, reserve and claim integration, host validation and independent review remain UNVERIFIED. See the Zcash advisory.

Pons buys use the ordinary signed buyer claim. For ZEC, the browser creates a random code before payment. The buyer saves it, sends an Ironwood note with its public identifier as text memo, then claims on chain 4663 after the watcher reserves the hash.

Status

The path of one buy

1 buys, or pays ZEC 2 sends 3 checks payment 4 you claim 5 lands in your wallet Buyer Pool Server You Collection Wallet

The wallet at the end does not have to be the wallet at the start. A claim code can be claimed to any wallet, any time.

  1. You buy, or you pay in ZEC. Buying is an ordinary swap: the pool sends $SHRIVE to your wallet, which the token contract records as a Transfer log with the pool as the sender. Paying in ZEC means sending one Ironwood note to the configured unified address with the exact memo shown after you save your code. A Zcash wallet that cannot send Ironwood notes with text memos cannot use this door.
  2. The pool's transfer, or the deposit's confirmation, is the proof. Nothing about either path is trusted from outside the chain: the only evidence that matters is that exact log or that exact deposit.
  3. The server authorizes the right path. For a Pons buy, the server signs an EIP-712 authorization. For Ironwood ZEC, the watcher downloads full transactions through public lightwalletd and decrypts the note with a viewing key. After memo, amount, receiver and confirmation checks, a separate EVM signer reserves the code hash on 4663.
  4. You claim, whenever you like. There is no keeper submitting on your behalf. You bring the code to Get my pieces, connect or type the wallet you want the piece in (any wallet, not only the one that bought or paid), and submit the claim yourself. You pay the small Robinhood network fee.
  5. The claim mints. The Pons path checks its signature. The ZEC path checks a signature from the saved code without revealing it, marks the public identifier used, and mints to the chosen nonzero EVM recipient.

What "shown once" means

For ZEC, your browser creates the code before payment. Save it before the invoice reveals the Orchard receiver and memo. The server receives only the keccak256 hash of its signing address and cannot recover the code.

What can make a mint not happen

Limit

A buy or a deposit under the minimum. If the amount is below the collection's minimum, the server refuses and nothing is signed.

A transfer or a deposit that does not check out. A wallet-to-wallet transfer, a transfer of a different token, or a Zcash deposit that never confirms never qualifies. The Pons signer checks its normal buy proof. The Ironwood watcher checks full transaction data and reserves only after confirmed payment.

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

What you see in each case is the same thing: no second piece, and no error to act on. A buy or a payment that never qualified never had a code coming; a code that already has its piece will not get a second one no matter how many times the claim is submitted.