Transaction safety
Two facts govern everything on this page.
- A broadcast transaction cannot be recalled.
- A transaction that destroys your asset can be perfectly valid.
Everything below follows from those.
Before signing
Section titled “Before signing”- Compare the asset and quantity with the listing or action you selected.
- Verify every destination and fee shown by the wallet.
- Reject unexpected inputs, outputs, permissions, or network changes.
- Refresh market state after an error before trying again.
- Never approve a request because a support account is pressuring you to act.
The wallet is the final boundary
Section titled “The wallet is the final boundary”Core’s review screen shows the asset, the amount, the service fee, the network fee estimate, and the total before your wallet asks you to sign. That screen is useful and it is not the last word.
Your wallet shows the transaction’s own inputs and outputs. Read them there. The wallet is the authorization boundary; Core’s screen is a summary of what Core intends. Where the two disagree, the wallet is what will actually happen.
What Core checks that a wallet cannot
Section titled “What Core checks that a wallet cannot”A wallet checks that a transaction is valid. Core checks things validity cannot see:
- Rune burns. A malformed rune marker destroys every rune balance the transaction spent, in a transaction Bitcoin considers perfectly valid. No fee check and no node acceptance test can detect it. Core reads the marker and refuses.
- Asset-bearing outputs used as fees or padding. Refused.
- Unexamined outputs. Treated as unknown rather than empty, and refused on the same footing as an output known to carry an asset.
- Complete inventory. Several protocols require ownership to be proven against the full inventory of all 29 protocols before a mutation, because an output can carry more than one thing.
Asset-bearing outputs is the page that explains why.
Fail closed
Section titled “Fail closed”Core’s checks fail closed. A required ownership, output, fee, or signature mismatch blocks the action. It is not downgraded to an advisory warning you can click past.
That is deliberate, and it means a blocked action is sometimes inconvenient and correct. If Core refuses an action citing an unexamined or co-located output, do not route around it in another tool.
Post-signature checks
Section titled “Post-signature checks”Signing is not the end. For an in-app execution the signed result is validated before submission: a changed template, owner, outpoint, price, or signature is rejected. For an Ordex purchase, Bitcoin Core is asked whether it would accept the transaction, and only the exact bytes the node checked are broadcast.
Broadcast
Section titled “Broadcast”A broadcast is submitted once. If the network response is uncertain, Core checks whether the transaction is already visible before returning success. It does not blindly resend to a second provider.
After the broadcast
Section titled “After the broadcast”- One confirmation is the default settlement depth for 16 protocols, and it is not a strong finality claim. For an amount you would mind losing, wait for more blocks yourself.
- A settlement can stay pending after a block, because most protocols also require the protocol-level state transition to be observed at a stable index checkpoint.
- A dropped or replaced transaction is a first-class outcome for the 16 protocols with automatic reconciliation, and a question you have to answer yourself for the other 13.
What the platform does not prove
Section titled “What the platform does not prove”An on-chain transaction does not by itself prove the identity of a counterparty, the value of an asset, or the accuracy of off-chain descriptions. Verify those independently before committing funds.