1Sat Ordinals — Inscription Envelopes

Abstract

This BRC defines how inscriptions attach content to a BRC-159 token: an ord envelope embedded in the locking script of a 1-satoshi output.

Together with origin tracking, inscriptions are how 1Sat attaches on-chain files and media to a 1-satoshi token — collectables, documents, app data, and other content-bearing uses.

Motivation

A 1Sat token is a 1-satoshi chain identified by origin. Many applications also want data bound to that token — an image, a document, app JSON, and so on.

Inscriptions put that data in the output script using a small, recognizable envelope. Wallets and indexers can find the envelope, read content type and body, and still follow the token with ordinary 1Sat transfer rules.

This document standardizes the envelope format and the 1Sat rules for when an inscription is valid and how it relates to origin.

Relationship to the token model

See BRC-159 for origin, sat ordering, and transfer.

Inscriptions do not replace that model:

• The token is still the 1-satoshi chain.
• Transfer is still sat ordering into a new 1-satoshi output.
• The envelope is content carried on outputs in that chain (typically at origin, sometimes re-inscribed on later outputs in the chain).

Specification

Envelope format

An inscription is an ord envelope inside an output script. The usual shape includes a content type and a body:

OP_FALSE OP_IF
  <"ord">                      // UTF-8 bytes 6f7264
  OP_1 <content-type>          // field 1: MIME type (UTF-8), e.g. image/png
  OP_0 <content>               // field 0: body bytes
OP_ENDIF

Rules:

• After the ord tag, the envelope is a sequence of field / value pairs. Field 0 (content body) ends the field list; it is followed by OP_ENDIF.
• Each pair is a field tag, then a value (normally one push of bytes).
• Tag aliases: a single-byte push of 0x00 or 0x01 is equivalent to OP_0 or OP_1 (same field number). Minters typically emit the OP_* form; parsers MUST accept both.
• In advanced use-cases, a field MAY appear more than once before the body; that does not invalidate the inscription. When resolving a field's value, the last occurrence wins.

Fields

Parent (field 3)

Field 3, when present, marks a parent / child relationship between inscriptions. This follows the same idea as Ordinals provenance: the owner of a parent inscription can create child inscriptions on-chain in a way others cannot fake, by spending the parent when minting the child.

That pattern is used for collections and other hierarchies (e.g. issuer → collection → items). Children may themselves have children. Burning or otherwise destroying the parent can be used by applications to stop further children that would need to spend it.

On 1Sat, the parent value is the parent's outpoint (the 1-sat output that carries the parent inscription), not a BTC-style txid…iN inscription id string:

• 36 bytes — 32-byte txid + 4-byte little-endian vout (preferred).
• 32 bytes — txid only; treated as that transaction's output 0.

Same-transaction spend (proof):
If field 3 is set, the parent outpoint MUST appear as an input of the transaction that creates this child inscription output. The spend is the proof: anyone can push arbitrary bytes as field 3, but only someone who can unlock the parent output can spend it into the child mint.

Other fields

Additional field/value pairs MAY appear before the body. They do not invalidate the envelope. Conforming 1Sat readers MAY ignore unknown fields. Application meaning (e.g. collections) is defined elsewhere.

Placement in the script

The envelope sits in the output locking script. Typical patterns:

<locking script> <envelope>
<envelope> <locking script>
<envelope> OP_CODESEPARATOR <locking script>

The spend condition MAY be any locking script: P2PKH is common, but covenants, multi-sig, marketplace locks, and other contracts are all valid. This BRC only requires that the envelope is present and well-formed on a 1-satoshi output; it does not constrain how that output is locked.

Push data on BSV

BSV does not impose the historical 520-byte push cap used on some other networks. A field value or content body MUST be a single push. Implementations MUST NOT split one logical value across multiple pushes and concatenate them.

Valid 1Sat inscription

An output is a valid 1Sat inscription when all of the following hold:

1. satoshis === 1 (it is a 1Sat token output under the core model).
2. The locking script contains a well-formed ord envelope as defined above.

Inscriptions are defined for 1Sat Ordinals: the envelope applies to 1-satoshi outputs that participate in origin tracking. Multi-satoshi outputs with similar script patterns are outside this BRC.

Inscriptions on a 1Sat chain

An envelope may appear on the origin output, on a later output in the same chain, or on both (re-inscription when transferring).

• Chain identity (origin and transfers) is unchanged by envelopes — see BRC-159.
• This BRC does not say which envelope is "the" content for an application. Collectable NFTs, updatable assets, feeds, and other profiles may select differently; those rules belong in application or content-resolution specs.

Inscription id

Because envelopes live in outputs (not input witnesses), an inscription is identified by the outpoint of the output that carries it. Outpoint string forms follow BRC-159 (underscore or dot; both denote the same outpoint).

A mint often creates origin and first envelope on the same outpoint; after transfers, the token's current outpoint moves while content may still be addressed by origin or by a specific inscription outpoint, depending on the application.

Mint (informative)

A typical mint creates the origin and inscription together:

inputs:   funding …
outputs:  o0 = 1 sat, lock + ord envelope   ← new origin + inscription
          change …

Transfers afterward follow BRC-159 (1-satoshi input → 1-satoshi output under sat ordering). The envelope does not need to be repeated on every output in the chain unless the application re-inscribes.

Metadata (MAP)

Optional application metadata MAY follow the inscription on the same output after OP_RETURN, using the Magic Attribute Protocol (Bitcom protocol id 1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5):

<ord envelope> <lock> OP_RETURN <MAP id> SET type ord name "…" …

Do not use OP_FALSE OP_RETURN if the output must remain spendable in the usual lock+envelope patterns.

MAP data is a SET command followed by string key/value pushes. For ordinal display metadata, common keys are:

Further keys and other ways to carry MAP (e.g. as an inscription field) are defined by application profiles such as 1Sat collections (specified separately). Unknown keys MUST be ignored by readers that do not implement them.

Wallets that surface a display name (e.g. in BRC-100 customInstructions) SHOULD take it from MAP name when present.

What this document does not cover

• Full MAP / Bitcom opcode encoding — specified separately
• Collection schemas and in-envelope MAP field layout — specified separately (1Sat Collections)
• Issuer authenticity (e.g. Sigma) — specified separately
• Large content via multi-transaction streams / OrdFS
• Wallet baskets, tags, or provenance proofs — BRC-147, BRC-150
• Marketplaces and application-specific locks

Those may require BRC-159, this envelope BRC, or both.

Security considerations

• Content authenticity — An envelope proves data was in a script at an outpoint; it does not by itself prove the token's current outpoint still descends from that origin (see BRC-159 and BRC-150).
• Parent without spend — Field 3 alone is not proof of parentage; only spending the claimed parent in the same transaction establishes the link.
• Large bodies — Very large pushes affect relay and storage (including BRC-150 bags that cover the origin tx). Application limits are out of scope here.
• Content selection — Showing the wrong envelope for a given app (e.g. latest vs origin) is an application concern, not fixed by this BRC.

Implementations

• docs.1satordinals.com
• @1sat/templates Inscription in b-open-io/1sat-sdk
• b-open-io/1sat-stack

References

1. BRC-159: 1Sat Ordinals — Single-Satoshi Tokens and Origin Tracking
2. BRC-147 — 1Sat Ordinals Basket Profile for BRC-46 / BRC-100
3. BRC-150 — 1Sat Provenance Remittance for Basket 1sat
4. 1Sat Ordinals — https://docs.1satordinals.com
5. Ordinals inscriptions — https://docs.ordinals.com/inscriptions.html