Inscriptions

An inscription is a file bound to a sat. Blockspace Value Theory's protocol roster dates ordinals inscriptions to January 2023 and describes them as arbitrary files bound to individual sats, carried in a Taproot witness envelope. This page covers how the bytes are carried, how BTI books them, and the variants BTI's documents cover: recursion, delegation and cursed inscriptions.

Content, not a token #

Under BTI's law an inscription is content, and the sat it is bound to is the token (ruleset B14). The chain runs label → content → token, and only the token claims. So an inscription's bytes appear in the books of its sat: its file is the sat's Book C, and the transaction that revealed it is the sat's Book B and Book A. See sats and ordinals.

ord reported 128,169,401 inscriptions (as of block 972,304, 2026-10-20 10:17:29 UTC).

The envelope #

The data-types reference describes how the file is carried. An inscription sits in an envelope inside a taproot script-path spend: the leaf script holds OP_FALSE OP_IF … OP_ENDIF with the content in between, and the ord envelope's marker is 6f7264. Three consensus facts shape it:

• each data push is capped at 520 bytes, which is why envelopes chunk their content into pushes of at most 520 bytes;
• tapscript leaf scripts have no script-size limit, so one leaf can hold megabytes of pushes, bounded only by transaction and block weight;
• witness bytes weigh 1 WU each, a quarter of base bytes. See the witness discount.

The reference adds that standard relay's 80-byte stack-item caps do not touch inscriptions, because the data lives in the leaf script, not in stack items. It also notes that a reveal transaction has base bytes of its own, and that "the commit tx is a second, unmarked cost".

Commit and reveal #

A tapscript can only be revealed by spending an output whose taproot tweak commits to it. So an inscription takes two transactions: a commit and a reveal. BTI records the commit as an enabler of the reveal; the commit claims nothing itself, but its bytes join the reveal's pool and surface in Book A only.

Case 7 of the BTI case studies (2026-08-10) is a 3,888,767-byte jpeg, inscription #127,057,930, revealed at block 960,962:

Of the reveal's structure, 22,457 bytes are envelope framing, about 7,500 push prefixes at 520-byte chunks. ord's content length for the inscription equals the envelope's body exactly, so BTI's extractor and the definitional source agree on the file.

Inscriptions that carry tokens #

Some protocols write their operations as inscriptions. A BRC-20 mint is an inscription whose body is a small JSON text. Case 10, the first BRC-20 mint, has two claimants on one reveal: the sat (op inscribe) and the tick ordi (op mint). The tick shares only the envelope it was written in; the 71-byte JSON body is the sat's content, so the tick's Book C is 0. BRC-100 works the same way: its token table entry says the tick's Book C is 0 because the JSON body is the sat's content.

Recursion #

BVT's roster lists recursive inscriptions, from 2023, as carried in the witness "by reference", and notes that they reduce per-item consumption. BVT's §3.6 adds that recursive inscriptions and better encoding lower per-item consumption while raising "the prestige of efficiency". Blockspace Labs' research project on permanent bytes includes a part called "Reuse, not repeat": how many bytes recursion (/content/, /r/) and delegation save.

Delegation #

A delegate inscription displays another inscription's content. The block.space rankings documentation says such an inscription "bought a few hundred bytes and is that size": the largest-inscriptions board ranks bytes bought, not bytes shown. The holders appendix's inscription labels table carries a delegate column for this.

Cursed inscriptions #

ord counts cursed inscriptions apart from blessed ones. Its latest reading: 472,043 cursed and 127,697,358 blessed (as of block 972,304, 2026-10-20 10:17:29 UTC). A cursed inscription has a negative number; a BTI finding of 2026-10-19 cites #−10,508, at block 791,263.

That finding is open. Of the 100,000 largest inscriptions by body size, 582 had no sat binding in BTI's table, the first of them cursed, far below the ord export's ceiling. The finding gives two possible causes: an export that omits cursed inscriptions, or a mismatch in how the envelope's index is derived. Neither is confirmed as of 2026-10-19. Until it is answered, block.space shows those rows as "not yet attributed", with bytes, block and fee, never 0 and never dropped.

blockspacelabs.com lists cursed inscriptions as a research study: which rules cursed each inscription, by height, and how the books bind them to sats. Blockspace Holdings' documents do not list the rules themselves.

The largest #

The block.space board of largest inscriptions ranks by Book C, the file's own bytes with all framing removed: "the largest file ever committed to a Bitcoin block". The Ordinal Sats family holds 33.44 GB in Book C (as of block 972,299, 2026-10-20 09:30:48 UTC).

Related #

• Sats and ordinals
• The witness discount
• The three books
• Spent sats (blockspace.to)
• inscription
• envelope
• cursed inscription

Sources #

1. block.space docs: data types · block.space/docs/datatypes
2. block.space docs: rankings · block.space/docs/rankings
3. Blockspace Value Theory · block.space/docs/bvt
4. The blockspacelabs.com page (index.html) · blockspacelabs.com
5. ord /status (the blockspace.to ord server) · blockspace.to/status
6. block.space protocols API · block.space/api/protocols
7. Blockspace Holdings records