When something goes wrong

Start here: in every failure below, your bitcoin is still yours. What can be lost is a claim, a stretch, or fees.

What you will know after this page

Where to find the reason code for a transaction that confirmed and produced nothing.
Which mint failures you can retry with a fresh salt, and which one costs founding status for good.
Why replacing a stuck reveal by fee is safe, and why bumping it from the intended carrier is not.
The first four things to do after an accidental carrier spend, in order.
The four situations nobody can fix, including a relic.

First, find out what actually happened

Get the transaction id from your wallet.
Confirm whether it is in a block, and at what height. Your own node is the better answer here, and the public page on verifying it yourself has the commands.
Ask the indexer whether it produced anything:

curl -s https://indexer.example.org/patina/invalid-events | head -c 2000

Each entry carries a reason code. Look yours up on Reason codes, which lists what every code means and whether anything can be done about it.

If the indexer shows nothing at all

Check GET /patina/status and compare indexed_height against tip_height. An indexer that is behind has not seen your transaction yet. That is not a protocol failure and waiting fixes it.

The reveal is stuck in the mempool

Fee too low, and the reveal has not confirmed.

Safe fix: replace the reveal by fee. Nothing has been created yet, so nothing is lost. The artifact id will follow whichever version confirms, because it is derived from the confirmed txid.
Watch the clock: if you are claiming founding status, the reveal must confirm before the grace period ends. Bump early rather than hoping.
Do not spend the intended carrier output of the unconfirmed reveal to bump it. That is CPFP from the wrong output and it would end the stretch the moment both confirm.

You revealed too early

The reveal confirmed with fewer than 144 blocks between the commit output and the reveal. The reason code is SEED_COMMIT_TOO_YOUNG.

Nothing was created. The commit output is spent and gone.
The coins from it are in whatever outputs your reveal created. They are still yours.
Recovery is to start again: new salt, new commit, new 144 block wait. Never reuse the old salt.
If the window has closed by the time you retry, the new artifact will not be founding. That part is not recoverable.

You pointed carrier_vout at the wrong output

The first three rows created nothing, so the fix is always the same: a new commit and another 144 block wait. The last row is the awkward one, because the reveal was valid and the artifact is sitting on an output you did not intend.

Wrong carrier index, four cases.
Case	Reason code	What to do
Index past the last output	`SEED_CARRIER_OUT_OF_RANGE`	Nothing created. Start again with a new commit.
Index points at the OP_RETURN	`SEED_CARRIER_IS_OPRETURN`	Nothing created. Start again.
Index points at a real output that is below the minimum	`SEED_CARRIER_BELOW_MIN`	Nothing created. Start again with a larger carrier.
Index points at a real, funded output that was not the one you meant	None, it is valid	The artifact exists on that output. It is fine. Protect that outpoint, or move it once and accept the reset.

You lost the salt

The commitment is a hash of your claimant key and the salt. Without the salt you cannot build a SEED payload that matches, so the claim cannot be completed.

The commit output is still spendable, because the leaf also requires your signature. Sweep it back as ordinary coins.
The claim itself is gone. Start again with a fresh salt if the window is still open.
A 16 byte salt cannot be brute forced. Do not try.

You lost the claimant key

Then you cannot spend the commit output at all, and both the claim and the coins in that output are gone. This is ordinary Bitcoin key loss, and nothing in this protocol changes it.

Two markers in one transaction

If a transaction has more than one OP_RETURN output whose payload starts with PTNA, the marker is void: VOID_DUPLICATE_MARKER. For a SEED that means nothing was created. For a spend of an existing carrier it means the KEEP instruction is ignored and the default rule decides where the artifact went. Check where it landed before you assume it is lost.

The artifact vanished after a reorg

Blocks can be replaced. An indexer rolls its state back to the fork point and replays.

Under 6 confirmations, treat everything as provisional.
If your reveal was dropped by the reorg, it may be mined again in a later block, in which case the artifact returns with a new birth_height. If the transaction stays dropped, rebroadcast it.
If your reveal was reorged past the end of the grace period, founding status is lost even though the artifact may still be created.

Details on Reorg behavior.

You spent the carrier by accident

This one is not recoverable and nobody can undo it.

Find where the artifact went. Fetch it and read the new carrier, or read the newest ring's successor_txid.
If it landed on an output you control, protect that outpoint now. Lock it.
If it landed on an output you do not control, whoever controls that output controls the artifact.
If it became a RELIC, the artifact is over. The rings remain readable forever.

The rest of the loss is real. The ring you closed records exactly how deep the stretch got, which is a precise and permanent record of what happened.

Your indexer disagrees with another one

That is a bug in one of them, and it matters more than one artifact. Do not patch quietly.

Get GET /patina/status from both, including spec_sha256 and parser_version.
Find the first block height where they differ.
Follow Report a disagreement.

What can never be fixed

A confirmed spend of your carrier.
A missed founding window.
A lost private key.
A relic. Terminal means terminal.

There is no admin key, no support override, and no rollback. Anyone offering one is lying to you. The same four, with the rest of what this protocol does not promise, are set out on the public risks page.