Envelope and operations

The reveal witness carries a non-executed script structure of this shape:

OP_FALSE
OP_IF
  "atom"
  <operation>
  <CBOR payload>
OP_ENDIF

OP_FALSE OP_IF means Bitcoin skips the block entirely. The bytes are inert to consensus and meaningful only to an Atomicals validator.

Operation codes

Code	Branch	Purpose
nft	Non-fungible	Mint a non-fungible object, including Realms, Subrealms, and Containers
ft	Fungible	Direct issuance of a complete supply
dft	Fungible	Deploy a decentralised mint
dmt	Fungible	Claim one mint against a deployment
y	Fungible	Split behavior at the pinned revision
z	Fungible	Custom coloring, activation gated
x	Non-fungible	Splat, separating Atomicals held at one output
mod	Any	Update mutable state
evt	Any	Record an event
sl	Any	Seal, refusing further changes
dat	Any	Store permanent data

The payload is CBOR, not JSON

A user interface may show you JSON. The wire format is CBOR. The differences that matter:

• CBOR has real binary strings, so embedded files are raw bytes rather than base64.
• CBOR map key ordering affects the encoded bytes and therefore the transaction id you grind.
• A JSON round trip can silently change number types and lose byte exactness.

Build the CBOR with the library your target validator uses. Do not hand-assemble an envelope from a formatted JSON blob.

Embedded files

A payload can carry named files. Each file declares a content type and its bytes. A validator records a digest so a consumer can check integrity later. See permanent storage and metadata and media.

Validation is contextual

The same envelope can be valid in one block and invalid in another. Height, network, active rule set, deployment state, quota, and Bitwork all participate. A parser that only checks structure will pass envelopes a validator rejects.

The only reliable check is running the exact validator revision you target against the exact transaction blueprint you intend to broadcast.

What the parser actually scans for

Reading the indexer rather than the prose changes what you should build against.

A witness script is considered only if it is at least 39 bytes long and its first byte is 0x20, the push of a 32 byte key. The parser then scans forward for the first OP_IF and checks the five marker bytes that follow it. It does not require an OP_FALSE before the OP_IF.

That tolerance is worth knowing in both directions. An envelope built in either of the two common script shapes is accepted, so a wallet that omits the leading OP_FALSE still produces something this indexer reads. It is implementation behavior rather than a relaxation of the format, so do not depend on every implementation being equally tolerant: build the shape your target validator documents, and check it against the transaction inspector before broadcasting.

A script that fails either precondition is skipped rather than rejected. A transaction with no readable envelope yields no operation at all, which is a different outcome from an operation that was found and refused.