What is Inscriptions?

Introduction

Inscriptions are a way to attach arbitrary content to an individual satoshi on Bitcoin, creating a Bitcoin-native digital artifact that can be held and transferred like any other UTXO. What makes them significant is not merely that data appears on-chain (Bitcoin has always been able to carry data in limited ways) but that inscriptions combine two ideas into a coherent system: ordinal numbering gives a specific sat identity, and the inscription mechanism binds content to that identified sat in a way indexers and wallets can track over time.

That combination solves a specific problem. Bitcoin normally treats sats as fungible units inside transaction outputs. If you receive 10,000 sats, the protocol itself does not ask which sat is which. But if you want a particular sat to matter (because it carries an image, a text file, a document, a game asset, or simply because it is the first sat of a block) you need a rule for saying this exact sat is the one. Inscriptions exist because ordinals provide that rule.

The result is often compared to NFTs, and that comparison is useful up to a point. Like NFTs, inscriptions let people create collectible or application-specific digital objects. But the mechanism is different in an important way: the content is revealed on Bitcoin itself, typically in witness data, and the artifact is associated with a satoshi rather than with a smart-contract entry. That makes inscriptions feel more native to Bitcoin’s UTXO model, but it also creates distinct tradeoffs in cost, wallet handling, privacy, and indexing.

How does ordinal numbering give a satoshi a persistent identity?

An inscription cannot exist in the abstract. It has to be attached to something. In the ordinals system, that “something” is a single satoshi, identified by an ordinal number; a serial number assigned to sats in the order they are mined and then tracked through transactions.

This is the conceptual step that makes the whole topic click. Bitcoin consensus does not store a global label on every satoshi. Instead, ordinal theory defines a deterministic interpretation of ordinary Bitcoin transaction flow: sats are numbered from 0 upward in mining order, and when transactions spend inputs into outputs, those numbered sats are assigned to outputs in first-in, first-out order based on the order and sizes of inputs and outputs. Because the rule is deterministic, software can agree on where a given numbered sat currently resides without any Bitcoin protocol change.

That is why the ordinals documentation emphasizes that the scheme requires no separate token, no new blockchain, and no changes to Bitcoin itself. The system is opt-in. Bitcoin nodes can ignore ordinal numbers entirely and still validate blocks exactly as before. Wallets and indexers that care about inscriptions, however, use the ordinal assignment and transfer rules to answer a different question: *which sat inside this output is the inscribed one? *

The practical locator for that question is a satpoint: an outpoint (transaction ID plus output index) together with the sat’s offset within that output. If an output contains 10,000 sats and the inscribed sat is the first one, its offset is 0. If it is the seventh, the offset is 6. This matters because inscriptions do not float freely at the transaction level. They ride with the specific sat to which they were attached.

What exactly is a Bitcoin inscription?

With that identity layer in place, an inscription becomes easier to define precisely. An inscription is created by sending the target satoshi through a transaction that reveals inscription content on-chain. Once revealed, that content becomes linked to that satoshi, producing what the Ordinals handbook describes as a Bitcoin-native immutable digital artifact.

There are two parts here that are worth keeping separate.

The first is the content itself: arbitrary bytes that might represent an image, text, HTML, audio, code, structured metadata, or something else. The system is general because, at base, it is just carrying bytes.

The second is the binding between content and sat. The content is not merely “in the same transaction” in a vague sense. Indexers interpret the reveal transaction so that the inscription is assigned to the first sat of the input containing the corresponding tapscript. From then on, when that sat moves according to ordinal transfer rules, the inscription is treated as moving with it.

This is why people sometimes say inscriptions “live on satoshis.” That is shorthand, not a consensus feature built into Bitcoin’s base layer. Bitcoin itself validates signatures, scripts, amounts, and spending conditions. The statement “this content belongs to this sat” is a protocol convention implemented by ordinal-aware software. But because the convention is deterministic and the underlying data is on-chain, it is not arbitrary in the way an off-chain database entry would be.

Why do inscriptions rely on Taproot and SegWit witness data?

Mechanically, modern inscriptions are tied to Taproot and SegWit witness data. This design choice was not accidental. Casey Rodarmor’s account of the project’s origin explains the motivation clearly: an earlier off-chain NFT approach had practical problems because it required out-of-band transfer and made public hosting difficult. The move to on-chain inscriptions came from wanting artifacts that used Bitcoin’s own transaction system and script machinery instead of depending on external storage and side agreements.

Taproot script paths became the vehicle because older script forms were more constrained by size limits, while Taproot made it practical to commit to and reveal larger script data. In wallet terms, the process is commonly described as commit and reveal.

In the commit transaction, the inscription creator commits to a tapscript that contains the inscription content. At this stage, the content is not yet visible on-chain in its final revealed form. The transaction sets up the spending condition that will later expose the data.

In the reveal transaction, that tapscript path is spent, the witness reveals the content, and the inscription becomes visible on-chain. The Ordinals wallet guide states that the inscription is inscribed on the first sat of the input that contains the corresponding tapscript. The canonical inscription ID then takes the form TXIDiN, where TXID is the reveal transaction ID and N is the index of the inscription within that reveal transaction.

This commit/reveal structure is important for understanding both cost and policy. Because the content sits in witness data, it benefits from Bitcoin’s witness discount in fee calculation. The Ordinals wallet guide gives a rough rule of thumb: divide content size by four and multiply by the fee rate to estimate the inscription fee contribution. But “discounted” does not mean “free.” Large inscriptions still consume block space and can become expensive during high-fee periods.

Step‑by‑step: how is a file inscribed onto a satoshi (commit/reveal)?

Suppose Alice wants to inscribe a small image. She runs Bitcoin Core with the required indexing support and uses ord, which relies on Bitcoin Core for wallet management and transaction signing. Her wallet holds ordinary UTXOs; nothing inside Bitcoin Core labels one sat as special yet.

When Alice creates the inscription, ord chooses a sat to carry it and prepares a commit transaction. That transaction locks funds into a Taproot output whose script path commits to the inscription payload. At this moment, the image is not yet visible to a block explorer as the final artifact, but the chain now contains a commitment that makes a later reveal possible.

Next comes the reveal transaction. This transaction spends the Taproot output through the committed script path and includes the inscription payload in the witness. Once mined, the payload is public on-chain. Ordinal-aware software interprets the reveal according to the inscription rules and assigns the inscription to the first sat of the relevant input. That sat now has two things that matter to software built around ordinals: an ordinal identity and an inscription bound to it.

Later, Alice sends the inscription to Bob. She is not “calling an NFT transfer function.” She is constructing a Bitcoin transaction that must preserve control of the specific sat carrying the inscription. If the wallet selects inputs carelessly or combines UTXOs in the wrong way, the inscribed sat may end up somewhere Alice did not intend. This is why sat control matters so much. The mechanism is simple in principle (the inscription follows the sat) but demanding in practice, because normal Bitcoin wallets were built for fungible value, not for preserving the identity of one distinguished sat within a UTXO.

How can wallet behavior cause accidental loss or misplacement of an inscription?

A smart reader might ask: if ordinal transfer is deterministic, why is inscription handling considered risky? The reason is that deterministic does not mean forgiving.

Ordinal assignment depends on ordering: the order sats are mined, the order transaction inputs appear, and the order outputs appear. Transfer semantics follow first-in, first-out allocation from inputs to outputs. If wallet software changes the ordering of inputs or outputs, merges UTXOs casually, or spends an inscribed output without explicit sat control, the inscription may still be transferred deterministically; but not to the destination the user intended.

This is why the ord project warns that Bitcoin Core is not aware of inscriptions and does not perform sat control, and that using ordinary bitcoin-cli wallet commands with ord-managed wallets may lead to loss of inscriptions. “Loss” here often means economic or practical loss, not cryptographic disappearance: the sat still exists somewhere, but the user may have accidentally sent it away, mixed it into change, or made it difficult to recover.

The operational response has been wallet segregation. Users are often advised to keep ordinal wallets separate from cardinal wallets; that is, separate UTXOs meant for inscriptions from ordinary spendable bitcoin. The Sparrow Wallet guide goes further and recommends treating an inscription wallet as receive-only unless the user fully understands UTXO-level spending. Freezing inscription-bearing UTXOs inside the wallet is a practical defense against accidental spends.

This is a good example of a broader truth: inscriptions fit Bitcoin’s UTXO model, but they do not fit the simplifying assumptions of many mainstream Bitcoin wallet interfaces. The system works best when the wallet exposes exact UTXOs, offsets, and transaction construction details rather than hiding them behind a single aggregate balance.

Why do inscriptions need special indexers and heavy bookkeeping?

Another place where people often misunderstand inscriptions is the role of indexers. Because Bitcoin consensus does not natively track each sat’s location, inscription systems depend heavily on software that reconstructs sat movement from the chain.

The ord software is the reference implementation here. It acts as an index, a block explorer, and a wallet interface. To build its view of satoshi locations, it requires a synced bitcoind node with -txindex and communicates with Bitcoin Core over RPC. That architecture tells you something important: inscription state is not a tiny extra annotation. It is derived by walking and interpreting a great deal of chain history.

The draft BIP makes the cost explicit. An index mapping UTXOs to the ordinals they contain is large, and a reverse index from ordinal to current UTXO is even less tractable. That is not a cosmetic implementation detail. It means inscriptions inherit a serious indexing burden. If you want to ask rich questions like “where is sat number X now?” or “which inscription is attached to this satpoint?”, you need storage, compute, and full historical transaction visibility.

This is one reason inscriptions feel very different from token balances in an account-based system. In an account model, the chain often exposes a direct mapping from account to balance or token ownership. In inscriptions, ownership is reconstructed from Bitcoin’s native spend graph plus ordinal assignment rules. The underlying chain was not designed around these queries, so the answers are available, but not cheap.

Which parts of an inscription are immutable and which depend on external software?

The strongest claim inscriptions can make is straightforward: if the reveal transaction is mined, the inscription content is on-chain and therefore immutable in the same sense as the rest of Bitcoin transaction history. This is the source of their appeal. A JPEG referenced by a web URL can disappear. An inscription’s revealed bytes do not depend on some later server continuing to cooperate.

But several limits sit beside that strength.

First, immutability is about the bytes on-chain, not about eternal readability by every tool. Explorer support, MIME handling, rendering rules, recursion features, and display conventions live in software above Bitcoin consensus. The bytes remain; the presentation can evolve.

Second, the artifact is only as recoverable as the sat carrying it is controllable. If the inscribed sat is lost along with the keys controlling its UTXO, the content still exists in historical chain data, but possession and transfer of the inscribed artifact are lost.

Third, some parts of the inscription ecosystem are explicitly normative by reference implementation rather than by finalized Bitcoin standard. For example, the Ordinals documentation for properties says the ord implementation is the normative specification for that feature. That is workable, but it means interoperability depends on matching implementation behavior, not just reading a stable consensus rule in Bitcoin Core.

How do inscriptions support structured metadata, properties, and gallery collections?

The simplest inscription is just content. But the ecosystem has pushed further into structured data layered on top of basic inscriptions.

The properties specification is a good example. It defines protocol-meaningful structured data encoded as CBOR in fields tagged with 17. Because Bitcoin script data pushes are limited to 520 bytes, larger CBOR blobs must be split across multiple 17 fields and concatenated before decoding. Compression is supported using Brotli when tag 19 is set to "br", with explicit decompressed size and compression-ratio limits to avoid decompression-bomb behavior.

This is mechanically revealing. It shows that inscriptions are not just “images on Bitcoin.” They can carry machine-readable structure with enough discipline for wallets, galleries, and other software to interpret consistently. Galleries, for example, can reference other inscription IDs, letting one inscription act as a permissionless collection object.

Still, there is a boundary worth remembering. These higher-level conventions are useful because clients agree to honor them. They are not new Bitcoin consensus objects. If the ecosystem agrees on CBOR schemas, gallery packing formats, or trait conventions, those become real in practice. But they remain application-layer protocol choices riding on Bitcoin transactions.

What security risks and policy debates do inscriptions raise?

Inscriptions introduced not only new artifacts but also new pressure on Bitcoin’s assumptions and tooling.

At the node-policy level, a recurring debate is whether witness-embedded datacarrying should be treated as legitimate use of block space, an unintended loophole, or something in between. The NVD entry for CVE-2023-50428 describes a datacarrier size-limit bypass using constructions such as OP_FALSE OP_IF, but marks the details as disputed and notes that some consider the behavior “not a bug.” That dispute matters because it shows the core issue is partly technical and partly normative: Bitcoin consensus allows certain scripts; mempool and relay policy determine what nodes prefer to forward; miners decide what fees they will accept.

The heated discussion around Bitcoin Core pull request #28408 makes the tradeoff clearer. Supporters framed broader datacarrier filtering as making an old policy limit apply consistently to newer witness styles. Critics argued it would not stop inscriptions in any durable way, would push traffic into private channels, and would make public mempools worse predictors of what miners will actually include. In other words, the argument is not simply “data good” versus “data bad.” It is about what relay policy can realistically accomplish without harming node usefulness or turning block construction into a private market.

There is also a more mundane but very real security issue at the explorer layer: inscriptions can contain arbitrary HTML and JavaScript. The ord server security guidance warns that anyone can publish such content and that explorer operators must treat the served domain as untrusted unless properly isolated. A vanilla ord server instance does not itself expose privileged web actions, so the danger rises mainly when operators serve it from the same domain as sensitive services. The recommended mitigation is plain: keep explorer content separated from anything users are meant to trust with credentials or privileged actions.

How do inscriptions affect privacy, fungibility, and Bitcoin resource costs?

Inscriptions also sharpen three longstanding Bitcoin tradeoffs: privacy, fungibility, and resource usage.

Privacy comes under pressure because ordinal-aware users care about the history of particular sats. The BIP notes that public ordinal numbers can reveal more transaction history than ordinary users might want to foreground. Fungibility becomes weaker in a social and market sense because some sats are now treated as more desirable than others; not just rare sats, but sats carrying specific inscriptions. Bitcoin consensus still sees them as sats, but market participants do not necessarily value them equally.

Resource costs show up in several layers. Large reveal transactions consume block space. Persistent interest in inscriptions increases demand for indexing and archival access. Transfers of single sats can run into Bitcoin’s dust and standardness constraints, sometimes requiring multi-step transactions with padding rather than a neat one-output move. Mailing-list discussion has connected inscription activity to broader concerns about node sync time, UTXO growth, and whether techniques like Utreexo may become more urgent.

None of this means inscriptions are uniquely unnatural to Bitcoin. It means they make visible a fact that was always true: Bitcoin block space is a scarce resource, and policy rules around data carriage are partly economic conventions, not purely mathematical necessities.

What are the common use cases for Bitcoin inscriptions?

People use inscriptions for the obvious collectible cases (art, profile pictures, historical artifacts) but that is only the surface. Because inscriptions can carry arbitrary bytes and, increasingly, structured properties, they are also used for text publishing, software experiments, on-chain interactive content, collection metadata, and token-like schemes built by convention on top of inscriptions.

That broader pattern is not unique to Bitcoin. Other chains have also seen “inscription” styles emerge when users discover a cheap or direct way to commit application data on-chain without relying on a rich native smart-contract abstraction. What changes from chain to chain is the cost model and the security model. On Bitcoin, the distinctive feature is that the artifact is bound to a specific sat inside the UTXO model and typically stored in witness data, not represented as mutable contract state.

That is why the comparison to NFTs should be handled carefully. The analogy explains the cultural role; collectibles, provenance, tradable digital objects. It fails if it suggests the same execution environment, the same transfer logic, or the same metadata model. An inscription is not an ERC-721 token with a Bitcoin skin. It is a different construction built from Bitcoin’s own primitives.

Conclusion

Inscriptions are on-chain content bound to individual satoshis through the ordinals numbering and transfer scheme. The core mechanism is simple once seen clearly: give one sat identity, reveal content on-chain, and let the artifact follow that sat through Bitcoin’s normal UTXO flow.

Everything else follows from that design. It makes inscriptions possible without changing Bitcoin, but it also makes them dependent on careful wallet behavior, heavy indexing, and application-layer conventions. If you remember one thing tomorrow, remember this: **an inscription is not “a file in a transaction” so much as “a file attached to one tracked sat.” ** That is the idea that makes the rest of the system make sense.

How do you get practical exposure to Bitcoin after learning about inscriptions?

If you want practical exposure after reading about inscriptions, the clearest path is to acquire Bitcoin and use it on-chain or hold it for secondary markets. Cube Exchange lets you buy Bitcoin on the spot market and move funds on-chain when you’re ready to interact with Taproot/ordinal-aware tooling.

1. Fund your Cube account with fiat (bank transfer/ACH) or send BTC to your Cube BTC deposit address and wait for the required on‑chain confirmations.
2. Open the BTC/USD or BTC/USDC market on Cube Exchange. Choose the market that matches your funding currency.
3. Choose an order type: use a limit order for price control or a market order for immediate execution; enter the BTC amount or USD you want to spend.
4. Review estimated fees and on‑chain withdrawal confirmation requirements if you plan to move BTC off‑exchange, then submit the order.
5. If you plan to mint or manage inscriptions directly, withdraw BTC to a Taproot‑compatible wallet you control and fund that wallet from Cube before creating commit/reveal transactions.