How BRC-20, Ordinals Inscriptions, and Bitcoin NFTs Actually Work — A Practical Guide

Okay, so check this out—Bitcoin used to be “just” money. Now it’s a platform for tiny programmable artifacts that developers and artists can actually put on-chain. At first glance that sounds wild. Seriously, people keep asking: “Is this tagging Bitcoin or enriching it?” My take: it’s both — and it’s messy in useful ways.

Short version: Ordinals let you inscribe arbitrary data onto satoshis, and BRC-20 is a minimalist, text-based token convention built on top of those inscriptions. They’re not smart contracts like on Ethereum. They’re more like a set of rules that people follow, encoded as JSON blobs and transactions. That difference matters for how tokens behave, how reliable they are, and how wallets and marketplaces must be built to support them.

What’s an Ordinal inscription, in plain language?

Think of an Ordinal as a label you glue to a specific satoshi. The inscription is the content of that label — could be an image, a piece of text, or a JSON payload. The Ordinals protocol numbers satoshis and assigns those inscriptions, and because Bitcoin transactions are immutable, that inscription lives with that satoshi forever (unless the satoshi gets spent and moves, carrying the inscription along).

Important nuance: inscriptions live in witness data (SegWit and taproot-friendly), so they don’t break Bitcoin’s base rules. But they increase block weight. That’s why fees, mempool congestion, and miner policy matter a lot for creators and collectors.

What exactly is a BRC-20 token?

BRC-20 is a non-Turing standard — it’s a convention for minting and transferring fungible tokens using inscriptions. It uses a handful of text inscriptions with specific methods: deploy, mint, and transfer. No contract execution, no state machine on-chain. Everything is reconstructed by indexers that read the sequence of inscriptions and apply rules off-chain to compute balances.

So, unlike ERC-20 where the chain enforces balances via contract state, BRC-20 trusts clients and indexers to interpret blockchain history consistently. That’s clever and low-footprint, but it also creates attack vectors: replay confusion, indexer divergence, and the classic “who’s counting?” problem when different services parse history differently.

How minting and transfers actually happen

Procedurally, creators write a specific JSON inscription (deploy) that defines a token symbol, supply limit, and decimal behavior. Then they mint by adding inscriptions that reference the deploy and specify amounts. Transfers are separate inscriptions that point to previous outputs. Every step is a transaction on Bitcoin, so you pay BTC fees for each operation.

Fees are the friction point. If you batch poorly, you pay a lot. If you batch cleverly (use fewer inputs, combine actions), you save. Wallet support is uneven, so tooling matters. For a widely used option, see https://sites.google.com/walletcryptoextension.com/unisat-wallet/ — it’s one of the more battle-tested wallets for ordinals and BRC-20 workflows, and the UX keeps improving.

Comparing BRC-20 tokens to ERC-20 and Omni

On one hand, BRC-20 is simple and gas-cheap per operation compared with early Ethereum if the chain weren’t full. On the other hand, it’s brittle: no on-chain enforcement, no composability, and a high degree of off-chain parsing. ERC-20 gave you composable DeFi primitives. BRC-20 gives you lightweight tokens that move like annotated satoshis.

Also, BRC-20 inherently inherits Bitcoin’s settlement finality and censorship-resistance strengths. But again — and this bugs some builders — you lose the convenience of contract-based tooling. So expect weird corner cases when marketplaces, wallets, and indexers disagree.

Practical tips for creators and collectors

– Test on testnet first. Seriously. Use testnet to prototype deploy/mint flows.
– Batch your inscription operations when possible; fewer transactions equals lower total fees.
– Use fee estimation tools that understand witness weight and current block space demand.
– Keep metadata lean. Large image inscriptions are cool, but they’re expensive and create heavier blocks. Consider off-chain hosting plus a lightweight on-chain pointer when appropriate.
– Use a reliable wallet with ordinals support — you’ll thank yourself. (The link above is a great starting point.)

Indexers, explorers, and custody — who to trust

BRC-20 depends on indexers to interpret inscriptions into token balances. Different indexers can diverge temporarily, and some may prioritize different mempool rules or drop certain weird inscriptions. That means custody services and exchanges have to run their own parsers and maintain resilience against malformed or borderline-inscription behavior.

If you’re building tooling, design for eventual consistency. Build reconciliation jobs. Log everything. And expect someone to find an obscure edge-case that breaks naive assumptions — it happens all the time. Your instinct might be to harden everything up front. That’s wise, but don’t overengineer before you see real user behavior.

Legal, ethical, and network considerations

Embedding arbitrary data on Bitcoin raises content moderation questions. Once data is on-chain, it’s nearly impossible to remove. That permanence is a strength for censorship resistance, but it’s also a liability for service providers who might be uncomfortable hosting or indexing certain content. Some miners or nodes may choose different policies, and that can fragment the ecosystem.

From an environmental or spam perspective, large-scale inscription activity increases block space usage and fees for everyone. That’s a political-economic issue as much as a technical one. Expect policy discussions and maybe even soft standards from major node operators if inscription volume keeps growing rapidly.