Wallet setup
Minting needs more than a send button. Check these five capabilities before the window opens, not during it.
- The five things your signing setup has to do, including a Taproot script path spend that reveals one specific leaf.
- Why the 16 byte salt is the one item in your backup that nothing else can recompute.
- How to rehearse the whole mint on regtest by mining the 144 block wait yourself.
- Which wallet features spend a carrier without asking you, and how to lock the output against them.
- Why you pay two fees, and why you keep a second funded output for bumping.
The five capabilities
Each row is a yes or no question about your tools. Answer all five before you fund anything, because the answers decide whether you build the two mint transactions yourself or hand the shape to a planner. The two transactions and the gap between them are drawn end to end on the public page for commit, wait, reveal.
| Capability | Needed for | How to check |
|---|---|---|
| Send to an arbitrary Taproot output | The commit output, which is a P2TR address you build, not one your wallet hands you | Can you paste a bc1p address and send to it |
| Taproot script path spend with a custom leaf | The reveal, which must show the commit leaf in the witness | Most consumer wallets cannot do this. A signing library or the planner endpoints can. |
| An OP_RETURN output in a transaction you build | The SEED marker | Can you add a data output of 26 bytes of script |
| Coin control, including locking an output | Keeping the carrier from being swept into an unrelated payment | Can you freeze a single UTXO and see it excluded from coin selection |
| Message signing with the carrier key | Attestations, which are optional but useful | Can you sign a BIP-322 message for a Taproot address |
Row two is the hard one. Building a Taproot script path spend that reveals a specific leaf is not a feature most wallets expose. You will either use a signing library and construct the reveal yourself, or use a planner that hands you an unsigned transaction to sign. Nothing in this protocol requires you to give anyone your keys, and no step ever should.
Use the planner if you are not building raw transactions
The Bitcoin Universe backend exposes two build helpers. They construct unsigned transactions and a plain language review summary. They hold no key material, they take no custody, and they broadcast nothing that you have not signed yourself.
POST /patina/plan/commit returns an unsigned commit plan and a review summary
POST /patina/plan/seed returns an unsigned reveal plan and a review summaryRead the summary before you sign. It exists so that a plan you did not build is still a plan you can check. The mint walkthrough shows what to compare it against.
Pick the network first
PATINA runs on three networks. Practise on the first two.
| Network | Use it for | Notes |
|---|---|---|
regtest | Your own machine, instant blocks | Mine 144 blocks yourself to clear the commit age check in seconds |
signet | A shared rehearsal with real block timing | Coins have no value, timing is realistic |
mainnet | The real thing | Gated by activation control. The mainnet record ships with null heights, and tools must refuse to build mainnet transactions until an authorised record naming at least two approvers is loaded. |
Run the whole mint on regtest at least once. The 144 block wait means a mistake on mainnet costs you a day before you find out.
Keep artifacts away from spending money
The single biggest cause of a lost stretch is coin selection picking up your carrier for an unrelated payment. Structure around it:
- Use a separate wallet, or at least a separate account, for artifacts.
- Fund it with what you intend to seal and no more.
- After the reveal confirms, label the carrier output and lock it.
- Never enable automatic consolidation or "clean up dust" tools on that wallet.
- If you use a wallet that sweeps on restore, know that restoring from seed can produce a sweep. Check before you restore.
What resets depth lists every accidental path in one table.
Back up three things, not one
Write all three down before you broadcast the commit, not after it confirms. Only the first is a backup you already have a habit for, and the third is the one nothing on the chain can give back to you.
| Item | Size | If you lose it |
|---|---|---|
| Wallet seed | 12 or 24 words | You lose the endowment and the artifact |
| Claimant x-only public key | 32 bytes | Recomputable from the key path, but keep it anyway |
| Salt | 16 bytes | You cannot build a valid reveal, and the commit output is only recoverable as ordinary coins |
The commitment is a hash of your claimant key and your salt. Without the salt you cannot produce the SEED payload that matches your commit, so the reveal cannot be valid. Your bitcoin is still yours because the leaf also requires your signature, but the claim is gone. Write the salt down when you generate it.
Fee planning
Two transactions, two fees. The reveal is the larger one because it carries a witness with the commit leaf and control block, plus a 26 byte OP_RETURN output.
- Do not target the cheapest possible confirmation for the commit. Whether a commit sits inside the founding window is decided by the height it confirms at, so a commit left sitting in the mempool can land after the window closes and miss the cohort.
- Budget the reveal fee at the time you reveal, not at the time you commit. That is at least 144 blocks later and the fee market will have moved.
- Keep a separate funded output for fee bumping. Bumping with the carrier itself defeats the purpose.
Before you continue
You are ready when you can, on regtest, produce a commit output, wait out the age, reveal it, and see the artifact appear in your indexer. Then do it on mainnet. The mint walkthrough is next.