Sats and ordinals

Every sat is separately ownable and numbered by ord. How BTI treats the sat as a token, why rarity is not one, and the Ordinal Sats family on block.space.

BTI's token table calls the sat "the base token": every sat is separately ownable and moves with the output that holds it. This page covers how sats are identified, how BTI treats them as tokens, and what block.space shows of them under the family name Ordinal Sats.

Numbering: ord #

Sat identity is ord's numbering. ord gives each sat an ordinal number, and BTI uses that number as the sat token's identity, its canonical_ref (ruleset B11). The token table marks ord's numbering as definitional (rule B14): ord's ruleset is the protocol here, so adopting its verdict is not a matter of trust. Blockspace Holdings' own ord server, which also serves blockspace.to, is BTI's source for the binding of inscriptions to sats, for sat numbers and for inscription numbers.

An example from the BTI case studies: the 3.9 MB jpeg inscription of case 7 sits on sat 1,212,723,567,637,705.

The sat as a token #

Ruleset v1's transferability rule says a token is exactly what can be transferred by itself, proven on chain. A sat passes. Several things associated with sats do not, and are labels on a sat instead:

an inscription is content bound to a sat; the sat is the token (B14). See inscriptions;
bitmap districts and sat names are labels on inscribed sats;
a CAT-21 cat is a label; the token is the sat, the first sat of output 0 of an nLockTime=21 mint;
rarity is a property of a sat, not another token. The token table records the owner's ruling (2026-08-02) on this, and the ruleset adds (Q-B18d) that an uncommon sat's backing begins at separation: "the separation is the purchase".

A sat claims bytes where a deliberate region exists for it (B11), as when an inscription is revealed onto it. When an inscribed sat is merely sent on, that is a sighting: ord records the location change, the byte-diff is zero and the judgment is carriage (ruleset U5, which retired the older rule B15).

The positional appendix #

Not every sat is catalogued. The token table lists the whole category of ordinal sats under a "positional appendix", deferred, with births to arrive with it. The design document gives the scale: the positional claim class, every output's bottom sat, would be about 3.6 billion rows, and nothing builds it yet. What BTI does catalogue are the sats something deliberate happened to: inscribed sats, through the ord adapter, and CAT-21 sats.

Ordinal Sats on block.space #

On block.space the sat family's display name is Ordinal Sats; its key stays sat in every URL, API field and database row. It was renamed from "Individual Sats" on 2026-10-19. Its sub-items are Ordinal Inscriptions, bitmap, sat names and CAT-21.

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

tokens: 125,519,930
Book A: 56.13 GB, which is 41.97 % of all Book A and 7.22 % of the chain bytes in range
Book C: 33.44 GB
operations: 129,015,098
first claim at block 767,430

Where sats are #

To say who holds a sat, the holders appendix tracks each catalogued sat's location. It loads the sat positions from an ord index export and then replays each new block, landing sats by ord's assignment rule from the input values, with fee sats going to the coinbase. It requires 100 random landings per pass to match ord's own answer, and treats a disagreement as the appendix's bug. The first seed, on 2026-10-19, placed 125,438,419 sats. See holders.

Lost sats #

ord also counts lost sats: sats that coinbase transactions never claimed, so they exist in no output. ord reported 2,895,844,904 lost sats (as of block 972,308, 2026-10-20 11:17:25 UTC). blockspacelabs.com lists them as a research study: where and when they were lost.

Sources #

Live figures: ord as of block 972,308, 2026-10-20 11:17:25 UTC; protocols as of block 972,299, 2026-10-20 09:30:48 UTC. Refreshed hourly.