Bitcoin Ordinals, Inscriptions, and BRC-20s for Dummies
A step-by-step walkthrough of the latest Bitcoin developments, including whether they are good or not!
Introduction
Disclaimer
My goal is to explain the core concepts, not to be 100% technically accurate. However, if I got something fundamentally wrong, please leave a comment or message me on Twitter.
The Absolute Basics
The satoshi (“sat” for short) is the smallest denomination of the cryptocurrency bitcoin. Each bitcoin consists of 100M sats. New sats are created when Bitcoin blocks are mined. The miner gets the new sats as a reward for mining.
Ordinals
Why do we need Ordinals?
The goal of the Ordinal standard is to assign each sat a “serial number” corresponding to the order in which it was created. I use the word “assign”—instead of “discover” or “determine”—because sats do not have an order in Bitcoin and therefore their serial numbers must be invented.
How do we know sats do not have an order in Bitcoin? Let’s try to derive one and see where things go wrong.
Start with the notion of order Bitcoin does have. If I get 1 sat as a reward for mining a block, and before I got that reward there were 50 sats in existence, then my sat is obviously number 51.
Likewise, if I receive 10 sats as a reward instead of 1, it’s clear that I own sats 51–60. So far, so good.
But what happens when I transfer a sat? If I own sats #51–60 and I send you a sat, did I send you #51, #60, #55, or a different one? No matter how long you stare at the Bitcoin protocol it cannot answer this question. Instead, you need a new protocol that invents an answer, and this the Ordinals standard.
How Ordinals Work
The Ordinal protocol solves the transfer issue in a brilliantly simple way. It decrees that when you make a transfer, you are always transferring your lowest numbered sats. In my example above, if I own sats #51–60, and I send you one sat, according to the Ordinals protocol, I am sending you #51.
Combining existing Bitcoin concepts with this simple rule, we can number every sat. Beyond this, we can choose which sats we want to transfer. Using the example again, if I want to send you #52, I can transfer 1 sat to a different wallet, and then 1 sat to you. The first sat is #51, the second is #52.
Of course this only works if everyone treats sat transfers the same way, and this choice of “first in, first out” is arbitrary. If a competing protocol decreed that higher-numbered sats transfer first, this would generate a different, incompatible, and equally-valid sat ordering.
Ordinals invents a system through one possible interpretation of Bitcoin. It does not give you access to the “fundamental reality” of what’s going on because there is no fundamental reality of how sats are ordered. This is important to understand, but it isn’t a bad thing.
Just as we don’t try to justify driving on the right or left side of the street by reference to some “fundamental truth,” the important thing with Ordinals is that everyone adheres to the same arbitrary choice.
Likewise, Bitcoin itself cannot be justified by reference to something else. As the classic quote goes:
If you don’t believe me or don’t get it, I don’t have time to try to convince you, sorry.
How To Use Ordinals
The Ordinals protocol is extremely simple: “you always transfer your lowest numbered sats first.” But to actually determine the ordinal number of a sat you need to apply this rule to every Bitcoin transaction ever, which is a lot of work.
You could write software to do this, but in practice you’ll probably want to use a service that indexes the Bitcoin blockchain and does the necessary calculations for you. This type of service is called an “indexer.” Etherscan is an example of a commonly-used indexer on Ethereum, which, of course, does not support Bitcoin ordinals.
Trust Issues
Using an indexer means you must trust it to faithfully report blockchain data.
However, despite the fact that Ordinals extend Bitcoin, they do not create additional trust or consensus issues. This is because the Ordinal protocol is read-only. The only way for value to actually change hands is through Bitcoin transactions which are secured by the Bitcoin consensus mechanism.
This means that when it comes to Ordinals there will always be a single “correct answer” that all users of the protocol can agree on. This wouldn’t necessarily be the case if the protocol required users to write to something that isn’t the Bitcoin blockchain.
Compare this to the situation with an L2. L2s add functionality to Bitcoin (or Ethereum or whatever), but they are read-write. To use them you have to send data to something that isn’t Bitcoin and trust the L2 to do the right thing. And you can only trust the L2s to do the right thing if there is an incentive to do the right thing. And what is that incentive? It’s not getting paid in Bitcoin to mine Bitcoin blocks etc.
Inscriptions
What are Inscriptions?
Inscriptions build on the idea of using the Bitcoin blockchain as a data store.
This is an idea a very old idea—in fact it’s as old as the very first Bitcoin block into which Satoshi famously embedded the message:
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.
Why might you want to embed data into Bitcoin? Durability and censorship resistance, proven attribution, guaranteed correct timestamps, etc.
Again, this is all quite old. What’s new are two things:
- A Bitcoin update that made it cost effective to add much more data than was possible before, enabling photos, videos, etc.
- Ordinal theory, which provides the building blocks for assigning ownership to data embedded on Bitcoin.
How Inscriptions Work
You can embed data into any transaction you send on Bitcoin. If you embed a picture into a random transaction, the picture will be available to anyone for the lifetime of Bitcoin, but it will not be “owned” by anyone.
Inscriptions invents a notion of ownership via embedding data “on a sat.” Once this is done, we can say that the owner of the sat is the owner of the data.
However, neither Bitcoin nor the Ordinal protocol have a notion of embedding something “on a sat.” This is why Inscriptions require a new protocol.
Inscriptions invents the concept of “inscribing” data on a sat by interpreting data embedded in transactions in a certain way. Specifically, to find the data inscribed into a sat, you:
- Look at every transaction that specific sat has ever been a part of. This is not possible with Bitcoin, but it is possible with Bitcoin + Ordinals, which is why Inscriptions depend on Ordinals.
- Once you find a transaction that has data embedded into it in a specific format defined by the Inscriptions protocol, you know this is the data “inscribed on the sat.”
Inscribing data on to a sat uses the same concept. To do so, you send a sat to yourself, embedding the data into the transaction. Because this Sat can be identified, you can trace back its transaction history to the transaction where it was inscribed, which identifies the data that’s “on it.”
To repeat, the content isn’t actually inscribed “on” the sat. Only adherents to the Inscriptions protocol have to say it is. By contrast, the content is actually on the Bitcoin blockchain somewhere—anyone who believes in Bitcoin, whether or not they believe in Inscriptions, must admit the content is there.
Now again here you have another independent protocol that cannot be justified by reference to Bitcoin or Ordinal theory. And again there is the possibility for competing but equally-valid protocols. For example, is the thing inscribed on a sat determined by its first inscription, or its most recent inscription?
But if everyone follows the same protocol, and there are efficient non-buggy protocol implementations, and there are public indexers who use these implementations, everyone can agree on who owns what content without additional consensus mechanisms.
BRC-20s
What are BRC-20s?
Building upon the concepts of Ordinals and Inscriptions, BRC-20 is a more complex and rapidly evolving standard.
BRC-20 extends Inscriptions to represent the ownership and transfer of fungible assets. To believe in BRC-20s, you must believe in Inscriptions and Ordinals, but believing in Inscriptions and Ordinals doesn’t mean you have to believe in BRC-20s.
The name BRC-20 is a reference to ERC-20, the standard for fungible tokens on Ethereum. ERC-20s store everyone’s token balance directly on-chain, updating it whenever there is a transfer. The way to port ERC-20 to Bitcoin would be to do the same thing.
However, a core idea behind Inscriptions is that they are immutable. This means you can’t have a single Inscription that represents the number of fungible tokens I own and then update that Inscription when I get more.
To track token balances using Inscriptions, you must compute and track running balances using a different protocol. And this is what BRC-20 does—it enables users to simulate balance updates using a series of immutable Inscriptions.
It does this by inscribing each balance-affecting operation, and computing the end result off-chain. Because the history of balance-affecting changes will never change, they can be represented using Inscriptions.
A Simplified Example
To create a token in a simplified version of BRC-20, I would inscribe something like this:
{
"protocol": "brc-20",
"operation": "deploy",
"symbol": "cat",
"maxSupply": "100",
"perOrdinalMintLimit": "10"
}To the average person, this is random text that could mean anything.
But if you adhere to this simplified version of the BRC-20 standard, it means that I have just created a new token called “cat” with a maximum supply of 100. Other people can now mint, but no more than 10 tokens per inscription.
To mint I would inscribe something like this:
{
"protocol": "brc-20",
"operation": "mint",
"symbol": "cat",
"amount": "10"
}Great! Now I own 10 tokens to everyone who believes in BRC-20!
To send some cat to Alice I create an inscription describing the transfer operation:
{
"protocol": "brc-20",
"operation": "transfer",
"symbol": "cat",
"amount": "1"
}Finally, I transfer the inscribed sat to Alice’s Bitcoin address. Now I have 9 cat tokens and Alice has 1. Where do these balances “live”? How can people access them?
Like with Inscriptions and Ordinals, you need to find or create an indexer which will find all these BRC-20 inscriptions and compute the balances. The balances are stored on Bitcoin in the sense that they can be computed with no non-Bitcoin data sources. But they depend on everyone having the same interpretation of the Bitcoin data.
How Far Can We Take This Thing? What’s Next—“Bart Contracts”?
As we’ve ascended from Bitcoin to Ordinals to Inscriptions to BRC-20s, each step has been more complicated—and depending on your perspective, more interesting and useful—than the last.
Is there a limit to how abstract and complicated we can get?
The BRC-20 standard allows us to simulate ERC-20 smart contracts on Bitcoin. The next logical step is to invent a protocol that uses Bitcoin to simulate not only ERC-20 smart contracts, but all Ethereum smart contracts.
I call this new (facetious) protocol Bart Contracts.
Bart Contracts are the final step in this ladder because the EVM is Turing-complete and therefore Bart Contracts can do anything you want to do.
How might Bart Contracts work?
Just like BRC-20s! But instead of deploying a token, you’d inscribe and deploy a full smart contract:
{
"protocol": "bart-contract",
"operation": "deploy",
"id": "CatContract",
"solidity-code": "contract Cat is Ownable ..."
}Bart Contracts are actually simpler than BRC-20s because all their logic is defined in one place—the Solidity code. By default Ethereum chooses the address of your new contract for you, which is nice because every address will be unique. In Bart Contracts you have to choose your own id, so be careful—only the first contract with a given id will be considered valid.
To interact with a Bart Contract you inscribe another sat:
{
"protocol": "bart-contract",
"operation": "transaction",
"id": "CatContract",
"functionName": "petCat",
"functionArgs": [],
}Then, to determine the state of all Bart Contracts, you turn to a Bart Contract-aware indexer and it evaluates the result of all these transactions. Unlike Ethereum where invalid transactions fail in real time, in Bart Contracts your transactions always succeed on the Bitcoin level but might be invalidated by an indexer.
Another downside of Bart Contracts is that you can’t send Bitcoin with transactions and contracts can’t hold Bitcoin because they don’t have addresses on the Bitcoin network.
Overall this is a joke, but it would be pretty cool! Also, IS IT A JOKE? There is a famous apocryphal rumor that Ethereum started as basically this exact idea.
“You are talking about an L2.”
No I am not!
This is different because in an L2 batches of transactions are “rolled up” into a single L1 transaction. But every Bart Contract transaction is a single Bitcoin transaction.
L2s increase throughput but at the cost of making you write to something that is not an L1 and therefore making you worry about the security and decentralization of the thing you’re writing to.
The point of the fake Bart Contracts and the real other protocols we’ve discussed is to stomach the low throughput and inefficiency of L1 transactions in order to have Bitcoin-level data security for everything.
Conclusion: Is Any of This a Good Idea?
Evaluating Ordinals, Inscriptions, and BRC-20s
Are Ordinals, Inscriptions, and BRC-20s Good? Or are they Bad? Should they be banned and their users forced to migrate to Ethereum? Or is it Ethereum that should be banned?
I have a pro-Ethereum bias. I like smart contracts, I like Solidity, and I like the idea of “throwing away the key” on protocol logic. I don’t want the balance of my token to change based on some off chain indexer “upgrade.”
So I want to focus on arguments FOR this approach.
Don’t be Boring
Ethereum people might say: Ordinals, Inscriptions, and BRC-20s likely have fatal flaws. Their rules might be inconsistent or impossible to apply on a practical level.
This argument is almost too powerful as it applies to all new protocols. The only way to improve protocols is to use them. Early adopters might lose everything in the process, but they should be aware of the risks and there are benefits to being an early adopter of a protocol that ends up being important.
Anyway, if you don’t like this stuff, come up with a more interesting argument, please.
Less Boring Arguments
For me Ordinals, Inscriptions, and BRC-20s are a bet on two things:
1) The cost of larger off-chain infrastructure is lower than the cost of on-chain storage.
Building new protocols on Bitcoin requires beefy off-chain infrastructure. For example, reconstructing every balance of every holder of a BRC-20 off-chain is much more costly than doing a simple RPC call to get the already-computed balance of an ERC-20.
On the other hand, storing and updating balances using contract storage on Ethereum is also incredibly expensive, as is deploying the contracts necessary to perform these computations.
The Ethereum philosophy is that this extra gas cost is worth paying in order to enable simpler off-chain infrastructure. Is this the correct philosophy? I love Ethereum but I hate the gas. Time will tell.
2) Complicated technical off-chain protocols are better than complicated social off-chain protocols.
Looking at the Bitcoin blockchain and “seeing” BRC-20 transfers requires a lot of creativity and interpretation (or the use of a sophisticated tool created by someone with such creativity). It would be better if things were more obvious.
ERC-20 transfers, by contrast, are much simpler to understand from Ethereum alone without a lot of off-chain technical work.
But the true meaning of an ERC-20 transfer is not just the incrementing of a number. These tokens are supposed to stand for something of value. In the case of USDC each USDC should be worth one US Dollar!
This is tricky though because Ethereum has a history of hard forks, the most recent one being the famous “Merge.” As part of this fork, all Ethereum users who didn’t move to the new PoS chain saw their USDC become worthless.
So the pro-Bitcoin tech argument would be: if Ethereum looks simpler it is only because you are not accounting for the complexity of determining when the next “Merge” will be and whether it will benefit you or not.
Is this argument correct? Time will tell.
