Bitmap Basics
Bitmap is a way of thinking about Bitcoin blocks as digital land. A block number inscribed as number.bitmap becomes the anchor for a piece of on-chain land, and child inscriptions can extend that namespace into parcels, assets, and collections.
The basic thesis
Bitmap land is derived from Bitcoin block data. When someone inscribes a block number as <number>.bitmap, that inscription links a specific block to a named piece of digital land.
The block acts like the root namespace. Once that root exists, related assets can be built under it. In practice, people often think of the Bitmap as the land and the child inscriptions beneath it as the parcels, structures, items, or application-specific components that live on that land.
A simple mental model is: block.bitmap = land. Then child inscriptions extend that land into parcel systems, indexed assets, and metaprotocol experiences.
This is why Bitmap is useful for users: it gives them a simple way to think about location and ownership. Instead of treating every inscription as an isolated file, Bitmap lets a block act as a named place, and then organizes related inscriptions under that place.
How to read it
A block number inscribed as number.bitmap defines the root Bitmap land.
Parcels or assets can then be organized as children of that Bitmap root, forming a hierarchy.
Bitmap and BRC-420 explorers index those relationships so users can navigate land, items, and mints.
From 0rdinals, users can jump into the Oodinals inscriber to select a Bitmap, create parcels beneath it, and inscribe those parcels with a simpler guided flow.
Parcels and children
The parent Bitmap inscription defines the top-level land reference. Child inscriptions can then be used to represent parcels, collections, deploys, items, or application layers attached to that Bitmap.
The exact naming and indexing rules depend on the collection or protocol using the Bitmap namespace, but the common idea is consistent: the parent Bitmap anchors the location, and children extend it into something navigable and ownable.
A useful way to think about parcels is that they sit beneath the root Bitmap in a parent-child structure. The Bitmap root says where the land is, and the parcel inscriptions describe how that land is subdivided, traded, or extended into more detailed on-chain spaces.
What users can do from 0rdinals
0rdinals is the place where the Bitmap guide becomes practical. Users do not need to manually stitch together every piece of namespace logic on their own. From here, the Oodinals inscriber can guide them through choosing the Bitmap they want to work with, selecting the parcel or structure they want to create, and then completing the inscription flow.
For users who already hold Bitmaps or parcels, 0rdinals can act as the discovery and indexing layer around those assets. That means users can review the Bitmap they are targeting, work with parcel-level inscriptions, and move toward trading or managing those items with much less friction through the linked Oodinals flow.
Simple Bitmap tools
Choose the Bitmap root you want to work with instead of manually resolving namespaces by hand.
Use the linked Oodinals inscriber flow to create parcel inscriptions tied to a Bitmap in a simpler, guided interface.
Move from raw inscription data toward user-facing actions around Bitmaps and parcels without forcing users to think only in txids and raw metadata.
Use Bitmap420 and the API routes on 0rdinals to inspect indexed relationships, then jump to Oodinals to take action.