Verify a transaction
Confirm what a transaction actually did, before signing and after broadcast, including any burn it caused.
Protocol behavior Verified 2026-08-31
Describes the Atomicals protocol itself at the pinned reference revision. It does not promise that any product exposes it.
- Page ID
-
guides/verify-a-transaction - Normative authority
- Executed source code at a pinned revision
- Networks
- mainnet
- Documentation version
- 2026.08
- Audience
- everyone, holder, developer
- Owner
- bitcoin-universe-docs
- Sources
-
- Atomicals ElectrumX
at
v1.5.2.0 - Universe Atomicals NFT, Realm, and Subrealm index
at
1d9109c68d95private repository
- Atomicals ElectrumX
at
Ce contenu n’est pas encore disponible dans votre langue.
Before you start
Section titled “Before you start”- Supported networks: mainnet.
- Status: protocol behavior for the allocation result, Universe implementation for the read views.
- Do the pre-signing half every time. It is the only part that can still prevent a loss.
Before signing
Section titled “Before signing”- List every input, with its outpoint, satoshi value, and coloured state.
- List every output, with its script and satoshi value, in order.
- Compute the expected allocation for that exact input and output set. Use the allocation visualizer.
- Confirm the burn figure is zero, or that any burn is deliberate.
- Confirm no output pays an address you did not intend.
- Confirm the fee comes from a cardinal input.
- Confirm the signature hash flag matches what the builder said it would use.
- Compare all of it against the wallet prompt, line by line.
If any line differs from your expectation, do not sign.
After broadcast
Section titled “After broadcast”- Wait for Bitcoin confirmation.
- Wait for the index to reach that height and report a stable generation.
- Read each moved asset by Atomical ID and confirm its current location matches the output you intended.
- Read the transaction through a source that reports burns, and confirm the burn figure.
- Compare the coloured input total against the sum of coloured output totals. Any difference is a burn.
- Record the generation identifier alongside the result.
What a block explorer tells you
Section titled “What a block explorer tells you”That the bytes are in a block. Nothing about validity, allocation, or burns. An ordinary explorer does not evaluate Atomicals rules.
Reorg considerations
Section titled “Reorg considerations”A result computed inside the reorg window is not settled. For anything with value at stake, wait for depth appropriate to the amount, then re-read rather than trusting the first answer. See confirmations and reorgs.
If the result is wrong
Section titled “If the result is wrong”- Not yet broadcast: recover from a rejection.
- Broadcast but unconfirmed: replacement may be possible if the transaction signalled it. Do not build a replacement without modelling its allocation first.
- Confirmed with a burn: the units are gone. Record what happened and change the procedure that produced it.
Source
Section titled “Source”Allocation and burns.