Reviewed and updated: October 19, 2026.
A Bitcoin inscription places content in Bitcoin transaction data and associates it with a satoshi under ordinal rules. To understand what a buyer receives, separate four things: the stored bytes, the rules used to locate them, the software that displays them and any rights in the associated work.
Where inscription data is recorded
The Ordinal Theory Handbook describes a two-stage commit/reveal process. A commit transaction creates a Taproot output; spending it through the relevant script path reveals the inscription content. The content is carried in an envelope within an unexecuted conditional. This is more precise than saying an image is simply inserted into a signature.
Bitcoin already has a scripting system for spending conditions. Its design differs from a general-purpose application platform, but saying Bitcoin has no programmable conditions is incorrect. Ordinal interpretation adds a way to track inscriptions; it does not require Bitcoin nodes to recognize a marketplace collection or enforce its artistic claims.
Storage is different from retrieval and display
| Layer | What to inspect | Possible misunderstanding |
|---|---|---|
| Transaction data | Reveal transaction, inscription ID and content bytes | A marketplace thumbnail is assumed to be the original file |
| Indexing | Rules and software used to identify the inscription's location | A wallet display is treated as Bitcoin consensus itself |
| Retrieval | Availability of the relevant historical data and content endpoint | Every node is assumed to serve every old file |
| Rendering | Content type, dependencies and viewer behavior | Stored code is assumed to look identical in every viewer |
| Rights | The creator's license and evidence of authorization | Token control is mistaken for copyright ownership |
Bitcoin Core supports pruning historical block files after validation. A fully validating node therefore need not retain every old inscription's raw data locally. Historical retrieval depends on data being retained and served somewhere, even though the transaction's place in the chain can be validated.
A recursive artwork example
Imagine inscription A contains a small program that references image B and font C through supported inscription-content endpoints. The displayed artwork depends on A, B and C, plus the viewer's ability to execute and render the format. A screenshot of the final picture does not reveal that dependency graph.
The handbook's recursion documentation describes endpoints for requesting other inscription content and related information. This can support reuse of on-chain components. It does not justify assuming every item sold under a Bitcoin NFT label has the same storage model. Inspect the specific item's content and references.
For a fictional inventory, A is 2 kilobytes, B is 12 kilobytes and C is 6 kilobytes. The dependencies total 20 kilobytes before transaction overhead. If B is reused by ten artworks, ten references do not mean ten fresh copies of B were necessarily inscribed. This is a dependency-accounting example, not a fee estimate.
Fees depend on the transaction, not the sale price
A high-priced collectible does not automatically require a proportionately high Bitcoin network fee. Fee evaluation needs the actual transaction's size or weight, the selected fee rate and any commit/reveal steps. A marketplace price can also include separate service charges. Ask for these components individually instead of treating a single checkout total as the network fee.
Ownership needs a specific definition
The U.S. Copyright Office and USPTO's 2024 NFT study explains that transfer of an NFT may or may not convey rights in the associated asset. Control of the relevant output and permission to reproduce, adapt or commercially exploit an image are different questions. A chain record cannot supply a license that the seller never had authority to grant.
Before evaluating an inscription, record its identifier, inspect its content and dependencies, confirm wallet support and read any license. This produces a more useful assessment than broad claims that all Bitcoin NFTs are permanently self-contained, that all NFTs elsewhere use external storage or that on-chain data guarantees market value.
Sources and scope
- Ordinal Theory Handbook: inscriptions and commit/reveal
- Ordinal Theory Handbook: recursion
- Bitcoin developer guide: transactions and spending scripts
- Bitcoin Core: historical introduction of block-file pruning
- U.S. Copyright Office and USPTO: NFTs and intellectual property, 2024
Continue reading: Ordinals, BRC-20 and Runes · IP registration and licenses · Bitcoin block weight and scaling
Editorial update: Corrected the data-placement and no-scripting claims; distinguished archival data, indexing and rendering; added a recursive-content example and separated token control from copyright.