A new token standard has been floating around the Ordinal space for a couple of days now, and while researching it, some interesting conclusions emerged. 

As readers know, I have been highlighting the Ordinal and BRC20 markets for a while now. Inscriptions were a game changer for Bitcoin, bringing new use cases and renewed interest. However, the ecosystem really took off when Domo released the BRC20 token standard. BRC20s are super simple; they are three text instructions (deploy, mint, and transfer), which users can inscribe onto sats to create and transfer tokens. This small set of instructions has kicked off a $1B+ market sector, dozens of new projects, and a new level of excitement on Bitcoin. 

Version Clash

But, I have just become aware of a new challenge in the BRC20 world. Ordinal indexers – the devices that index BRC20 transactions and make the protocol usable through off-chain indexing of onchain data, have had to freeze their indexers on v.09 of Ord. Ord is the indexing software nodes have to run to understand inscriptions. The early Ordinal market forced people to run their own Ord indexer on top of a full Bitcoin node. But recently, wallets and markets have begun running their own on the backend, so users don’t need to. The consolidation of Ord has caused some centralization in the Ordinal protocol but has made it much easier to use.

Freezing on a version of Ord means that the existing BRC20 platforms, like Unisat or BRC20 wallets like Xverse, are forced to continue to run the old indexer. Thankfully, as a fairly simple protocol, this probably isn’t a huge concern; the protocol still works fine for now. But it adds uncertainty around the future of the stack. My hunch is that developers are thinking through ways to transition BRC20s to v.10 of Ord through burning and reminting in some manner. 

However, problems with Ordinal indexers came to a head with the recent launch of a new version of Ord. The latest version, v.10, adds many features to Ordinals that many BRC20s won’t be able to harness – including the new metaprotocol and metadata fields to Ordinal envelopes. 

A Word On Mail

One must understand Ordinal envelopes to understand the importance of Ord v.10. Ordinal envelopes allow indexers to identify and read inscriptions. Users inscribe data onto Bitcoin in a BTC transaction’s witness data section. But indexers have no idea if the data in the field is an inscription without envelopes—an Ordinal envelope signals to an indexer that any data following it is the inscription. As such, envelopes are an essential part of the Ordinal stack. Without envelopes, indexers would be unable to see and parse inscriptions. Ordinal Hub wrote a great article on them here; I recommend readers check it out.

Envelopes are pretty simple. A simple text inscription envelope looks like this:

1. OP_PUSH “ord” – indicates what follows is an inscription. Indexers see “ord,” and then they know what follows is the inscriptions data. 

 

2. OP_PUSH 1 – denotes the content type.

3. OP_PUSH 0 – holds the actual inscription content, up to 520 bytes.

4. OP_ENDIF – signals the end of the envelope.

Envelopes are an integral part of the Ordinal stack, and Ord v.10 has made them much better by adding metaprotocol and metadata fields directly into them.

Metaprotocols have been a loosey-goosy term in the Ordinal community for a while. In general, metaprotocol refers to a protocol built on top of inscriptions. BRC20s are a metaprotocol, as are Bitmaps, ORC20s, and BRC721s. But metaprotocol was just a community term to denote different standards and has not been enshrined in the Ordinal software until now. Ord v.10 puts a metaprotocol field directly into an envelope, making indexing faster and easier as it allows indexers to flag specific metaprotocols. With metaprotocols, indexers no longer need to sift through each inscription looking for fungible tokens; they can just specify the metaprotocol and index accordingly.

V.10 also adds the ability to put metadata into an envelope as a CBOR file. CBOR files, concise binary object representation, are data formats that are much smaller than text and JSON files – something like a 60%-70% reduction in byte size compared to raw JSON. As BRC20s are JSON text inscriptions, reducing their overall footprint reduces their impact on the chain. 

Most importantly for inscriptions, v.10 allows token standards to put the metadata into the Ordinal envelope, and only the deploy transactions require it. This new metadata field means that BRC20 transfer and mint transactions would no longer need the “p,” “op,” “tick,” or “amt” parameters – as those are already in the metadata deployed transactions. As such, tokens would have a lighter footprint on Bitcoin, indexers could index them faster, and fees would be cheaper. It would be a win-win for everyone if BRC20 indexers didn’t freeze their indexers.

A New Token On The Block

As the Ord version freeze may have frozen BRC20 tokens, there may be some opportunity for new token standards to emerge in Bitcoin in their stead. BRC20s will still work as long as indexers are running v.9 to support them, but it could mean they will never develop beyond their current state. To that end, a new inscription token standard emerged this week. 

Cybord, this new token standard, has much in common with BRC20s, but they use the metadata and metaprotocol fields. Using the new fields makes them lighter, faster, and cheaper than BRC20s. The website and market around them are extremely early, with only 165 tokens, a clunky dex, OTC discord trading, and a rudimentary wallet. At best, Cybord is probably experimental. But seeing what teams are building on Ord v.10 is interesting.

I recommend users exercise extreme caution if/when they use this site – it is, at best, thought of as experimental. 

I am skeptical of technological exceptionalism – which is what I call the idea that the best tech wins a market. Tech adoption is mostly about network effects, and BRC20s, even if frozen, still have the strongest network. But, being frozen in an indexer version means that other tokens may surpass them.

A Note On Runes

While I was drafting this post, Casey Rodarmor, creator of Ord and Ordinals, pushed some new commits to his GitHub. In it, he seems to suggest that we can expect him to release his Rune token standard in April alongside the halving.

Runes are a Bitcoin token standard like BRC20 that uses the full suite of Ord tools and is near an official Ordinal token standard we can hope for. Runes will likely be fully integrated into the Ord stack and have much more support than BRC20s. I expect Runes to be as popular as BRC20s. Runs are like an official token release from Ord. However, don’t go out and buy Rune tokens yet – most likely, any Runes bought before the official release will be cursed by indexers and not counted, so fair warning.

Image credits to ordinalhub.com and @RuneX_Tech on Twitter.