跳到內容

本頁面的來源

本頁面的每項論述都對應固定的修訂版本。開啟路徑即可檢視驗證所依據的確切來源。

atomicals-electrumx-1.5.2.0

Atomicals ElectrumX

修訂 v1.5.2.0 (2025-03-27)

開啟固定路徑: normalFtAllocation

Version-sensitive ARC-20 and Atomicals validation behavior used as the pinned reference baseline.

universe-index-atomicals-nfts-and-realms

Universe Atomicals NFT, Realm, and Subrealm index

修訂 1d9109c68d95

開啟固定路徑: server

Materialized read model for plain NFTs, Realms, and Subrealms projected from Atomicals ElectrumX.

Verify a transaction

Raw

Confirm what a transaction actually did, before signing and after broadcast, including any burn it caused.

Protocol behavior Verified 2026-08-31 Metadata & Sources

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

本頁內容尚未翻譯。

  • 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.
  1. List every input, with its outpoint, satoshi value, and coloured state.
  2. List every output, with its script and satoshi value, in order.
  3. Compute the expected allocation for that exact input and output set. Use the allocation visualizer.
  4. Confirm the burn figure is zero, or that any burn is deliberate.
  5. Confirm no output pays an address you did not intend.
  6. Confirm the fee comes from a cardinal input.
  7. Confirm the signature hash flag matches what the builder said it would use.
  8. Compare all of it against the wallet prompt, line by line.

If any line differs from your expectation, do not sign.

  1. Wait for Bitcoin confirmation.
  2. Wait for the index to reach that height and report a stable generation.
  3. Read each moved asset by Atomical ID and confirm its current location matches the output you intended.
  4. Read the transaction through a source that reports burns, and confirm the burn figure.
  5. Compare the coloured input total against the sum of coloured output totals. Any difference is a burn.
  6. Record the generation identifier alongside the result.

That the bytes are in a block. Nothing about validity, allocation, or burns. An ordinary explorer does not evaluate Atomicals rules.

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.

  • 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.

Allocation and burns.