Bitcoin Ordinals let you attach data — an image, a line of text, even a small program — to a single satoshi, turning it into a one-of-a-kind artifact that lives on-chain. Bitcoin Runes do something different: they create fungible tokens directly on Bitcoin. Both sit on the same blockchain, and neither can be read straight from Bitcoin’s base layer.
To query inscriptions or runes data, you need two things: software that scans the chain and decodes these protocols, called an indexer, and an interface that serves the decoded results back to your app. There are three practical routes — run the official ord indexer yourself, self-host a third-party indexer, or call a hosted API that someone else maintains.
This guide explains what the data actually is, why Bitcoin doesn’t expose it on its own, and how each route works in practice.
What Are Inscriptions and Tokens on Bitcoin?
Both features extend Bitcoin without changing its consensus rules. They lean on two older upgrades — SegWit and Taproot — which made room for arbitrary data in a cheaper part of a transaction. The difference is what each one produces.
What Is an Inscription?
An inscription is content written to a specific satoshi, the smallest unit of Bitcoin (one hundred-millionth of a coin). Bitcoin Ordinals is the protocol that makes this possible by assigning every satoshi a sequential number based on the order it was mined. That numbering scheme is called ordinal theory, and it gives each satoshi a stable identity you can track and inscribe.
The content itself lives in the witness portion of a Bitcoin transaction. Once written, it stays on-chain permanently and moves with the satoshi when it’s spent. You can browse live examples on ordinals.com, the reference explorer maintained by the protocol’s creator, Casey Rodarmor.
Inscriptions started slowly in January 2023 and then grew fast. More than 117 million had been made by early 2026, and text-based content — most of it token data — accounts for roughly 83% of the total (Spark research).
What Are Runes?
Runes is a protocol for issuing fungible tokens on Bitcoin. Where an inscription is “inscribed,” a rune is “etched” — a single transaction defines the token’s name, supply, and decimal precision, and those rules become immutable once confirmed. Rodarmor, who also created Ordinals, launched Runes at the April 2024 halving, when Bitcoin reached block 840,000 (Decrypt).
Runes store token balances inside Bitcoin’s unspent transaction outputs (UTXOs), the same accounting units Bitcoin already uses to track who owns what. Transfer instructions are written into a special output called a runestone. This design is deliberately lean, which is the main reason Runes was pitched as a cleaner alternative to the earlier BRC-20 standard.
BRC-20 is worth naming because the three concepts get confused. BRC-20 also creates fungible tokens, but it does so by inscribing JSON text through Ordinals — which is why most inscriptions today are text, not images.
| Bitcoin Ordinals | Bitcoin Runes | BRC-20 | |
|---|---|---|---|
| Creates | Unique artifacts (inscriptions) | Fungible tokens | Fungible tokens |
| Action | Inscribed | Etched | Inscribed via JSON |
| Where data lives | Witness data, tied to a numbered satoshi | UTXOs, via a runestone output | Text inscriptions |
| Launched | January 2023 | April 2024 (block 840,000) | March 2023 |
| Readable from Bitcoin alone? | No | No | No |
Why Can’t You Read This Data From Bitcoin Directly?
Because Bitcoin doesn’t know these protocols exist. To Bitcoin, an inscription is just some witness data and a rune transfer is just a normal transaction. Ordinal numbers, inscription IDs, rune balances — none of that is tracked by the chain itself.
All of it is a convention layered on top. The rules for assigning satoshi numbers, decoding inscription content, and interpreting runestones live in the protocol specifications, not in Bitcoin’s own logic. So reading the data means running software that applies those rules to every block, from genesis forward, and keeps a separate database of the results.
That software is an indexer. It connects to a fully synced copy of Bitcoin, replays history while applying the Ordinals and Runes rules, and then answers questions like “what’s inscribed on this satoshi?” or “who holds this rune?” Everything in the rest of this guide is a different way of getting at that indexed database.
Who Needs Inscription and Runes Data?
Anyone building a product that has to show, verify, or track this data rather than just create it. The reader is usually a developer or a team, not an end user clicking a wallet button.
Common cases include:
- Marketplaces that list inscriptions and runes and need accurate ownership, metadata, and transfer history.
- Wallets that display a user’s inscriptions and rune balances alongside their BTC.
- Explorers and analytics tools that chart minting activity, holder distribution, or fee trends.
- Portfolio trackers that value a user’s holdings using live rune supply and market data.
- Verification flows that confirm an inscription is genuine before letting it trade.
The market has matured into this builder phase rather than staying a speculative frenzy. By mid-2026 the Runes sector sat around $104 million in market cap, and some venues narrowed their focus — Magic Eden wound down Ordinals and Runes support in early 2026, for example. Reliable data access is now a practical requirement, not a novelty.
How to Query Bitcoin Ordinals and Runes Data
You have three routes, and they trade control against effort. Run the canonical indexer, self-host someone else’s, or let a provider host it for you.
Route 1: Run the Official ord Indexer
ord is the reference implementation from the Ordinals project, and it doubles as a wallet, block explorer, and local server. When you run ord server, it exposes an HTTP interface you can query over the network.
The workflow looks like this:
- Point
ordat a fully synced Bitcoin instance so it can read raw block data. - Let it build its index — the first full scan is slow and disk-heavy.
- Run
ord serverto expose the HTTP endpoints. - Request a route, sending an
Accept: application/jsonheader to get JSON back instead of HTML.
Its recursive endpoints are the most dependable to build on, because the project guarantees they won’t be removed or have their fields renamed (Ordinals docs). A few examples:
/r/inscription/<INSCRIPTION_ID>— details about a single inscription./r/children/<INSCRIPTION_ID>— the first 100 child inscription IDs./r/sat/<SAT_NUMBER>— inscriptions on a given satoshi./content/<INSCRIPTION_ID>— the raw inscription content.
Running ord yourself gives you canonical data and full control, which matters if correctness is non-negotiable. The cost is operational: you maintain the index, the storage, and the Bitcoin layer beneath it.
Route 2: Self-Host a Third-Party Indexer
If you want a broader REST surface than ord offers out of the box, you can run an open-source indexer such as Hiro’s Bitcoin indexer. It serves Ordinals and Runes data over separate REST APIs — /ordinals/v1 and /runes/v1 — with pagination and JSON responses built in.
Typical calls include GET /inscriptions/{id} for a specific inscription, GET /inscriptions for a paginated list you can filter by MIME type or block height, and GET /stats for aggregate totals. The Runes API covers rune metadata, address balances, and transfer activity.
One current caveat matters here. Hiro has been deprecating its hosted Ordinals, Runes, and BRC-20 APIs and now steers developers to either run the indexer themselves or move to Xverse’s data APIs (Hiro migration notes). If you were planning to lean on Hiro’s public endpoints, check their status before you commit.
Route 3: Use a Hosted Metaprotocol API
The fastest route is to skip the indexing entirely and call an API that a provider already runs. Several exist — Xverse, Maestro, UniSat, and QuickNode among them — and they expose inscriptions, runes, satoshi data, and collections through REST or JSON-RPC methods such as ord_getInscription and ord_getRune.
The appeal is obvious: no sync, no storage, no upkeep, and you ship faster. The trade-offs are the usual hosted ones — you depend on the provider’s uptime, their pricing, and whatever data they choose to expose. As the Magic Eden and Hiro shifts show, hosted metaprotocol services also come and go, so it’s worth knowing how hard a migration would be before you wire one in deep.
| Approach | Control | Maintenance | Best for |
|---|---|---|---|
Run ord yourself | Full | High | Canonical data and custom indexing logic |
| Self-host an indexer | Full | High | A rich REST surface on your own infrastructure |
| Hosted metaprotocol API | Low | None | Marketplaces and apps that need to ship quickly |
Where NOWNodes Fits
Two of the three routes share a dependency that’s easy to overlook: the indexer only works if it can read a fully synced copy of Bitcoin. ord and Hiro’s indexer both need that base layer, and syncing and maintaining it is its own ongoing job.
That’s the gap NOWNodes covers. Instead of running and keeping a full Bitcoin instance in sync, you can use Bitcoin API access from NOWNodes and point your indexer at it, so your team spends its time on the inscription or runes logic rather than on base-layer upkeep. For heavier, latency-sensitive setups, a dedicated Bitcoin configuration runs one isolated instance for you, with the option of custom indexing — useful when you want the whole stack, index included, in one place.
Worth being precise about what this does and doesn’t give you. NOWNodes’ Blockbook interface returns standard Bitcoin address and transaction data — balances, history, UTXOs — and its Bitcoin address webhook can notify you when a watched address changes, which is handy for spotting an incoming Ordinals or Runes transfer. Neither decodes inscription content or rune balances for you; that decoding is still the indexer’s job. The split is clean: NOWNodes supplies the Bitcoin data layer, the indexer turns it into Ordinals and Runes data.
Conclusion
Bitcoin Ordinals and Bitcoin Runes add artifacts and tokens to a chain that was never designed to track either, so every method of reading them comes back to the same step — an indexer that decodes the protocols and serves the results.
Pick your route by how much control you need. Run ord for canonical data you own end to end, self-host an indexer for a fuller REST surface on your own terms, or call a hosted API when speed to launch matters more than independence. Whichever you choose, the fully synced Bitcoin layer underneath is the common requirement — and the part a provider like NOWNodes can take off your plate so you can focus on what you’re building.
FAQ
Is a Bitcoin Rune the same as a BRC-20 token?
No. Both are fungible tokens on Bitcoin, but Runes etches token data into UTXOs through runestone outputs, while BRC-20 inscribes JSON text through the Ordinals protocol. Runes was designed partly to avoid the extra on-chain clutter BRC-20 tends to create.
What is a runestone?
A runestone is the special transaction output that carries Runes instructions — etching a new token, minting, or transferring one. Indexers read these outputs to reconstruct every rune’s supply and current balances.
Do inscriptions live on-chain or off-chain?
On-chain. Unlike many NFTs that point to a file hosted elsewhere, an inscription’s content is stored directly in the Bitcoin transaction’s witness data and stays there permanently.
Is the ord indexer free to use?
Yes — ord is open-source software you can run yourself at no license cost. The real expense is operational: disk space for the index and a synced Bitcoin instance for it to read from.
