# Bitmap

Bitmap districts are labels on inscribed sats: BTI's opi-bitmap adapter adds a source under Ordinal Sats, never a family of its own.

URL: https://blockspace.wiki/protocols/bitmap/

In bitmap.holdings' own words, "Bitmaps turn each Bitcoin block into a piece of digital land. Each Bitcoin block becomes a coordinate. Each coordinate becomes ownable." [Bitmap](https://blockspace.wiki/glossary/bitmap/) writes a claim to a block, a district, as an inscription. In [BTI](https://blockspace.wiki/glossary/bti/) a district is not a token. It is a [label](https://blockspace.wiki/glossary/label/) on an inscribed sat, and Bitmap's bytes are counted under [Ordinal Sats](https://blockspace.wiki/glossary/ordinal-sats/). Bitmap has no family of its own in the books, so this page has no live share.

## How Bitmap writes to Bitcoin

A district claim is an ord [inscription](https://blockspace.wiki/glossary/inscription/). The BTI protocol review of 2026-08-29 worked one by hand: a 397-byte transaction at block 900,095 holding seven envelopes, each a 13-byte `text/plain` body spelling `900095.bitmap`. All seven bound to the same sat. The review's other example, at block 933,996, is a single inscription whose content is `933996.bitmap`.

## How BTI attributes its bytes

Ruling U3 decides what Bitmap is. "A token is exactly what can be transferred by itself, proven on chain; everything else is a label on one." The inscription is content bound to a sat, and the sat is the token (B14). The token table therefore lists bitmap sats as a sub-subset: inscribed sats whose inscription is a district claim, where the district number is a label (an owner ruling of 2026-08-02). In the adapter rulings' words, "bitmap catalogues inscribed sats, not 'districts'".

The opi-bitmap [metaprotocol adapter](https://blockspace.wiki/glossary/metaprotocol-adapter/) adapts opi-bitmap, one of the three OPI indexers. They sync independently, so each has its own adapter and its own height clamp. Its trust is derived.

Because Bitmap claims the same token the ord adapter claims, the two claims collapse to one claimant: two claims on one token give n = 1, never a division. Their regions are unioned, not summed. In the 900,095 example, the Bitmap claim's regions (31 bytes of output 0 and one 35-byte envelope span) are a strict subset of the inscriptions claim's. The books read content 91, structure 275, overhead 0: Book C 91, Book B and Book A 366 bytes, with 31 bytes of output 1 unattributed. The review's conclusion: a label-writing second source "cannot change n or add a byte".

## Quirks on record

- **Genesis.** Claims begin at block 792,435, matching BTI's `bitmap-genesis` landmark.
- **One district per block.** At the claims frontier of 964,607 the review counted 964,604 district labels, exactly one per block. The review calls this the first-is-first rule, enforced by the label table's key.
- **Sightings and the second source.** opi-ord, a second source on inscribed sats, sights the Bitmap-shaped carriers among others, and its claims are diffed against the ord adapter's window by window.

## What the live data shows

Bitmap appears in the live protocols API as a source inside the `sat` family. On 2026-10-20 at 09:42 UTC it listed the bitmap source with 972,116 sat tokens and 304,024,598 bytes attributed, within the family figures of Ordinal Sats. These overlap with the inscriptions source, since both claim the same sats.

bitmap.holdings is the owner's Bitmap site, hosted elsewhere; see [bitmap.holdings](/projects/bitmap.holdings/).

Sources:

- Blockspace Holdings records
- bitmap.holdings, its own home page, read 2026-10-20 · https://bitmap.holdings
- block.space protocols API · https://block.space/api/protocols

Updated: 2026-10-20