# Ordinal Sats

The sat family: inscribed sats, bitmaps, sat names and CAT-21 sats. How ord binds files to sats, how BTI books them, and the family's live share.

URL: https://blockspace.wiki/protocols/ordinal-sats/

[Ordinal Sats](https://blockspace.wiki/glossary/ordinal-sats/) is the display name of the sat family on block.space. It was renamed from "Individual Sats" on 2026-10-19, and the key stays `sat` in every URL, API field and database row. BTI's token table calls the sat "the base token": every sat is separately ownable and moves with its output, and its identity is ord's numbering, the [ordinal number](https://blockspace.wiki/glossary/ordinal-number/).

## How the data reaches the chain

Most of the family's bytes are [inscriptions](https://blockspace.wiki/glossary/inscription/). ord binds content to a sat through a witness [envelope](https://blockspace.wiki/glossary/envelope/): an `OP_FALSE OP_IF … OP_ENDIF` block inside a taproot script-path spend, marked `6f7264` ("ord"). The data-types reference gives the reasons the channel won. Each data push is capped at 520 bytes, so content is chunked, but a tapscript leaf has no script-size limit, so one leaf can hold megabytes. Witness bytes weigh one weight unit each, a quarter of base bytes. An inscription takes two transactions: a commit and a [reveal](https://blockspace.wiki/glossary/reveal-transaction/).

[CAT-21](https://blockspace.wiki/glossary/cat-21/) uses no envelope. Its mint is any transaction with `nLockTime = 21`, a field every transaction already has.

## What BTI counts as the token

Under ruleset v1's rule U3, a token is "exactly what can be transferred by itself, proven on chain". An inscription is content, not a token: the inscribed sat is the token that claims the bytes (case law B14). The family has these parts in the token table and on block.space:

| sub-item | what narrows the sat | catalogued by |
|---|---|---|
| Ordinal Inscriptions | ord bound content to it | the ord adapter (module inscriptions) |
| [Bitmaps](https://blockspace.wiki/glossary/bitmap/) | the inscription is a district claim; the district number is a label | the opi-bitmap adapter |
| [Sat names](https://blockspace.wiki/glossary/sat-name/) | the inscription names the sat; the name is a label | the opi-sns adapter |
| [CAT-21](https://blockspace.wiki/glossary/cat-21/) sats | an `nLockTime = 21` mint; the cat is a label on the first sat of output 0 | the ord adapter (module cat21) |

Rarity is not a sub-item. The owner ruled on 2026-08-02 that rarity is a property of a sat, not another token. Uninscribed sats would arrive with the positional appendix, which the token table lists as deferred.

The ord adapter's trust is "definitional" in the [trust triad](https://blockspace.wiki/glossary/trust-triad/): ord's ruleset is the protocol for which sat an inscription is bound to. A [second-source adapter](https://blockspace.wiki/glossary/second-source-adapter/), opi-ord, sights the same sats through [OPI](https://blockspace.wiki/glossary/opi/). It writes no bytes and cannot create a token. As everywhere in BTI, the bytes come from the raw chain, never from ord.

## How the bytes are booked

An inscription reveal is usually dedicated to its sat, and the sat's claim covers the whole transaction. The commit that enabled it is an [enabler](https://blockspace.wiki/glossary/enabler/): its bytes join the pool and reach [Book A](https://blockspace.wiki/glossary/book-a/) only. Case 7 of the BTI case studies is a 3.9 MB jpeg at block 960,962. Its body is 3,888,767 bytes (Book C), the reveal is 3,911,459 bytes (Book B), and the 419-byte commit brings Book A to 3,911,878.

A sat often shares a reveal with other tokens. In case 10, the first BRC-20 mint, the sat and the tick `ordi` divide the envelope they share. The sat takes 284.5 bytes of Book B and all 71 bytes of Book C, because the mint JSON is the sat's content. Case 3 adds a rune on the same reveal, so three tokens share it.

Sending an inscribed sat is a [sighting](https://blockspace.wiki/glossary/sighting/). ord records the new location, but the byte difference is zero, so the send is judged [carriage](https://blockspace.wiki/glossary/carriage/) and adds nothing to the books (U5). A marketplace sale has no record in the protocol, so it stays unattributed, an understatement the ruleset accepts on purpose.

The [largest inscriptions](https://blockspace.wiki/glossary/largest-inscriptions-board/) ranks inscriptions by [Book C](https://blockspace.wiki/glossary/book-c/), the file's own bytes. A [delegate inscription](https://blockspace.wiki/glossary/delegate-inscription/) is ranked by the few hundred bytes it bought, not the content it shows.

## Live figures

The family's books (as of block 972,299, 2026-10-20 09:30:48 UTC):

| measure | value |
|---|---|
| Book A | 56.13 GB |
| Book C | 33.44 GB |
| share of the chain's bytes (Book A) | 7.22 % |
| share of all Book A bytes | 41.97 % |
| tokens (sats with claims) | 125,519,930 |
| operations | 129,015,098 |
| first height | 767430 |

The protocols API splits the family by claim source. Read on 2026-10-20 (books at block 972,199), the inscriptions source covered 125,448,674 sats, sat names 4,956,536, bitmaps 972,116 and CAT-21 63,668. The sub-items overlap, because one sat can be sighted by several sources, so they do not add up to the family total.

ord itself counts 128,170,184 inscriptions, 472,043 of them [cursed](https://blockspace.wiki/glossary/cursed-inscription/) (as of block 972,320, 2026-10-20 12:17:53 UTC). On 2026-10-19, 582 of the 100,000 largest inscriptions had no sat binding below the export ceiling, which block.space shows as "not yet attributed".

Holders: read on 2026-10-20, the leaderboard's coverage table placed 99.88 % of the family's Book A on 3,034,207 addresses (see [holders](/concepts/holders/)).

## Measured findings

In the July 2026 measurement run, inscriptions had a bytes:vbytes ratio of 3.374. The measurements page reads this as paying for about 30 % of what they consume, the largest [witness discount](https://blockspace.wiki/glossary/witness-discount/) measured. The same run found that data payload peaked at 45.4 % of block bytes at height 833,000, during the inscription era, and fell to 31.9 % by 850,000 after runes moved to OP_RETURN.

Sources:

- Blockspace Holdings records
- block.space docs: data types · https://block.space/docs/datatypes
- block.space docs: measurements · https://block.space/docs/measurements
- block.space docs: rankings · https://block.space/docs/rankings
- block.space protocols API · https://block.space/api/protocols
- block.space leaderboard coverage API (holders measured per protocol) · https://block.space/api/leaderboard/coverage
- ord /status (the blockspace.to ord server) · https://blockspace.to/status

Live figures: ord as of block 972,320, 2026-10-20 12:17:53 UTC; protocols as of block 972,299, 2026-10-20 09:30:48 UTC

Updated: 2026-10-20