> For the complete documentation index, see [llms.txt](https://bsv.brc.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bsv.brc.dev/tokens/0160.md). # 1Sat Ordinals — Inscription Envelopes Open Protocol Labs () **Authors:** David Case (), Luke Rohenaz () **Contributors:** Kurt Wuckert Jr. (), Michael Boyd (), Dan Wagner () ## Abstract This BRC defines how **inscriptions** attach content to a [BRC-159](/tokens/0159.md) 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](/tokens/0159.md) 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 // field 1: MIME type (UTF-8), e.g. image/png OP_0 // 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 | Field | Tag | Value | Requirement | | ------------ | --- | ------------------------------------- | -------------------------------- | | Content type | `1` | MIME string, UTF-8 (e.g. `image/png`) | MUST when creating inscriptions | | Content body | `0` | Body bytes (MAY be empty) | MUST (terminates the field list) | #### Parent (field 3) Field **3**, when present, marks a **parent / child** relationship between inscriptions. This follows the same idea as [Ordinals provenance](https://docs.ordinals.com/inscriptions/provenance.html): 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: ``` OP_CODESEPARATOR ``` 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](/tokens/0159.md). * 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](/tokens/0159.md) (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](/tokens/0159.md) (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`): ``` OP_RETURN 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: | Key | Requirement | Meaning | | ------ | --------------------------------- | ------------------------------------- | | `app` | MAY | App that produced the ordinal | | `type` | SHOULD | `ord` when using this schema | | `name` | SHOULD when a display name exists | Human-readable name (case-preserving) | 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](/tokens/0147.md), [BRC-150](/tokens/0150.md) * Marketplaces and application-specific locks Those may require [BRC-159](/tokens/0159.md), 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](/tokens/0159.md) and [BRC-150](/tokens/0150.md)). * **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](/tokens/0150.md) 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](https://docs.1satordinals.com) * `@1sat/templates` `Inscription` in [b-open-io/1sat-sdk](https://github.com/b-open-io/1sat-sdk) * [b-open-io/1sat-stack](https://github.com/b-open-io/1sat-stack) ## References 1. [BRC-159: 1Sat Ordinals — Single-Satoshi Tokens and Origin Tracking](/tokens/0159.md) 2. [BRC-147](/tokens/0147.md) — 1Sat Ordinals Basket Profile for BRC-46 / BRC-100 3. [BRC-150](/tokens/0150.md) — 1Sat Provenance Remittance for Basket `1sat` 4. 1Sat Ordinals — 5. Ordinals inscriptions — --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://bsv.brc.dev/tokens/0160.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.