How to Get Bitcoin Ordinals and Inscription Data (2026)

Ordinals look like they should be easy to read. The data is on-chain, it is permanent, and every block is public. Then you connect a node, call getrawtransaction, and find nothing that resembles an inscription: just a Taproot spend with a witness blob. That gap between what is stored and what is queryable is the whole problem, and it is why an entire layer of indexers exists. Here is what actually lives on the chain, what has to be computed, and which route makes sense depending on what you are building.

How do you get Bitcoin ordinals data?

There are four practical routes, and they trade operational load against control. A node alone is not one of them, because a node validates the chain without indexing it for these lookups. Whatever you pick, something has to replay every block from genesis and track which output holds which sat range.

The last row is worth separating out. Marketplace listings, floor prices and sale history are not on the Bitcoin blockchain. They are a venue's own records. Only the transfer itself is on-chain, so if you mix the two sources, be clear in your own schema about which fields you can verify against a block and which you are taking on trust.

Where is ordinals data actually stored on Bitcoin?

Inscription content is stored in the transaction witness. An inscription commits its payload inside a Taproot script-path spend, wrapped in an envelope that an indexer parses back out of the script. That is genuinely on-chain and permanent, which is also why inscriptions consume block space and cost real fees. The sat that carries the inscription gets its identity from ordinal theory, a numbering convention that assigns every satoshi a serial number in the order it was mined.

Nothing in the Bitcoin protocol enforces any of this. Ordinal theory is an interpretation applied on top of ordinary UTXO data, which is why the network has no opinion about which sat is which and indexers have to work it out independently. If you are fuzzy on why outputs rather than accounts are the unit of ownership here, what a UTXO is is the right place to start, and Taproot's role is covered in Bitcoin address types explained.

What is the difference between ordinals, BRC-20 and Runes?

These three get grouped together and behave very differently, especially when you have to prove a number is correct. The short version: inscriptions are individual artifacts, BRC-20 balances are computed off-chain from inscribed instructions, and Runes balances are attached to UTXOs on-chain.

Runes launched at block 840,000 in April 2024 and was designed to lean on Bitcoin's own model rather than on off-chain bookkeeping. A runestone is identified by an output whose script starts with OP_RETURN followed by OP_13, then data pushes decoded as variable-length integers. Balances are held as amounts attached to specific outputs, and a rune is identified by the block height and transaction index where it was etched, written as BLOCK:TX. A malformed runestone is called a cenotaph, and the consequences are strict: runes going into that transaction are burned, and anything etched there becomes unmintable. That is a real edge case your code has to handle rather than ignore.

Why do two ordinals indexers report different BRC-20 balances?

Because BRC-20 balances are not stored anywhere on the chain. The chain holds a sequence of inscribed JSON instructions, and a balance only exists once an indexer applies the rules to those instructions in order. Two indexers that handle an edge case differently, an overflow, a malformed mint, a transfer that exceeds available balance, will produce different totals for the same wallet, and both will be internally consistent.

This has a practical consequence if you are displaying balances to users or settling anything against them. Keep the raw events, not just the computed total. If a user disputes a number, you want to point at the specific mint and transfer inscriptions that produced it rather than at your own database. Runes is easier here precisely because the accounting is on-chain and per-output.

What happened to the Hiro Ordinals API?

Hiro deprecated its Ordinals, Runes and BRC-20 APIs on March 9, 2026, as part of narrowing its focus to core Stacks infrastructure, and pointed developers toward Xverse's APIs with a migration guide. That shutdown moved a lot of production traffic, and it is a useful reminder for anyone architecting on top of a single hosted metaprotocol endpoint: the indexing layer above Bitcoin is younger and less stable than the chain underneath it.

The defensive design is to keep your own copy of the identifiers that matter, inscription IDs, txids and block heights, so that if a provider disappears you can re-derive state from any other indexer or from the chain itself. Store the pointers, not just the rendered answer.

Do you need to run your own ordinals indexer?

Only if you need protocol rules nobody else implements. Self-hosting means a synced full node, well over a terabyte of storage once the index is built, and a long initial replay before the first query returns. It also means owning the failure mode nobody warns you about: an indexer that stops keeping up with the tip and keeps answering, confidently, with stale data. If you do go that route, monitor the height gap between your indexer and the chain tip as a first-class alert, the same way you would watch an API endpoint for silent failures, because a lagging indexer looks healthy right up until a user reports a missing transfer.

For most teams the honest answer is no. A wallet showing a user their inscriptions, a gallery rendering a collection, or an analytics dashboard tracking mint activity needs correct data, not custody of the pipeline. That is the same calculation covered in what it costs to run a Bitcoin node, and it lands the same way: the hardware is cheap, the operational attention is not. A hosted Bitcoin node API or an ordinals API removes the sync and the babysitting.

How do you track who owns an inscription?

Ownership follows the UTXO. An inscription sits on a specific sat, that sat sits in an output, and whoever controls the output controls the inscription. So a transfer is not a special ordinals operation, it is an ordinary Bitcoin transaction that spends the output and creates a new one. To track ownership you follow that chain of spends from the reveal transaction forward.

This is also the trap in naive implementations. Because the transfer is a normal spend, an inscription can be moved accidentally by a wallet that treats it as spendable value and hands it to a miner as fee or merges it into change. Any wallet handling inscriptions has to mark those outputs as unspendable for ordinary payments. If you want to see what a transfer looks like at the byte level, decoding a raw Bitcoin transaction shows the input and output structure the indexer is reading, and the transaction decoder does it without a node.

Can you query ordinals data with SQL?

Yes, and for anything aggregate it is the only sane approach. REST endpoints are built for lookups: give me this inscription, give me this address. The questions that actually inform product decisions are aggregate ones. How concentrated is the holder base for a collection. How many mints happened per block during a launch. What share of a rune's supply sits in the ten largest outputs. Which inscriptions moved after a given height.

Answering those over REST means paging thousands of calls and assembling the table client-side. Against an indexed dataset it is one query that returns rows you can export. That is the difference between querying the Bitcoin blockchain with SQL directly and consuming a fixed endpoint, and it is why analytics work and application work usually want different access patterns against the same data. If you would rather pull the underlying blocks yourself, how to download Bitcoin blockchain data covers the routes and their real sizes.

What should you build on?

Match the access pattern to the job. A wallet or marketplace frontend wants REST lookups with low latency and a cache. A research or risk team wants SQL and CSV exports. A team with unusual protocol requirements, or a business whose entire product is the index, has a real case for self-hosting ord and owning the rules.

Whichever you choose, treat inscription IDs, txids and block heights as the durable primitives and everything else as derived. The chain is the only part of this stack that has never had a deprecation date. Full disclosure on what we do: BitcoinDatabase indexes the chain and exposes inscriptions, BRC-20 events and Runes balances over an ordinals API and SQL, with the raw events kept alongside computed balances so you can audit any figure. This is informational on-chain data only, not investment advice, and nothing here is a valuation of any collectible or token.