PSBT requirements
What a partially signed transaction must contain for an Atomicals aware wallet to sign it safely, and what a wallet must show you.
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
-
protocol/arc20/psbt-requirements - Normative authority
- Atomicals reference implementation
- Networks
- mainnet
- Documentation version
- 2026.08
- Audience
- developer, integrator
- Owner
- bitcoin-universe-docs
- Sources
-
- Universe ARC-20 index and Marketplace v1 authority
at
670030e50071private repository - Atomicals ElectrumX
at
v1.5.2.0
- Universe ARC-20 index and Marketplace v1 authority
at
- Known limitations
-
- Wallet support for specific signature hash flags and PSBT encodings varies. Verify capability before building, not after a signing failure.
Это содержимое пока не доступно на вашем языке.
A PSBT is the exchange format between a service that builds a transaction and a wallet that signs it. For Atomicals, a PSBT that omits context is a PSBT that cannot be signed safely.
What every input must carry
Section titled “What every input must carry”| Field | Why |
|---|---|
| The previous output script and value | So the wallet can verify what it is spending |
| Whether the input is coloured, and for which Atomical | So the wallet can warn before spending an asset |
| The signature hash flag to use | So the signer commits to the intended scope |
| Derivation information for the signing key | So the wallet can find the key |
| Tap internal key and merkle root for Taproot inputs | So key-path signing works |
What every output must carry
Section titled “What every output must carry”| Field | Why |
|---|---|
| Exact script | So the recipient cannot be redirected |
| Exact value in satoshis | So allocation is deterministic |
| The expected coloured assignment | So the signer can compare against their intent |
Signature hash flags
Section titled “Signature hash flags”A flag that does not commit to all outputs lets someone else change the outputs after you sign. For a swap, the seller’s signature must commit to the exact output that pays them.
A builder must state, per input, which flag it expects. A wallet must show which flag it is about to use. A signer must reject a flag they did not expect.
Ordering
Section titled “Ordering”Input order and output order are part of the meaning. A wallet or library that reorders inputs or outputs for canonicalisation changes the allocation result. Do not reorder an Atomicals PSBT.
Protected outputs
Section titled “Protected outputs”A wallet must refuse to select a coloured output for fees unless the user explicitly approved spending that asset. This is the single most valuable wallet feature for Atomicals. See wallet safety.
Validation before signing
Section titled “Validation before signing”Before presenting a PSBT for signature, a builder should:
- Resolve every input’s coloured state at a stable chain position.
- Compute the expected allocation for the exact output set.
- Assert the burn total is zero, or make the intended burn explicit.
- Assert no unexpected Atomicals operation is present.
- Assert output totals do not exceed input totals per token.
- Record the chain position, and re-validate if it moved.
The transaction inspector performs a read-only version of steps one to five locally, without uploading anything.