The Bitcoin halving is approaching, interpreting the underlying design mechanisms and limitations of the Runes protocol

Author: Shijun

Preface

After a long hiatus, I, Shijun, am back.

In the past six months, I have completely transitioned from the ETH ecosystem to the BTC ecosystem, moving from the application layer to the underlying blockchain layer, examining the underlying layers of L2 public chains like BTC, Merlin, Babylon, and Xion, and studying the source code of inscription protocols such as Ordinals, BRC20, Atomical, Runealpha, and Runes.

With some accumulation of knowledge, I will continue to output insights. From a technical perspective, I will bring you unique insights and market value.

1. What are Runes?

In the past year, the biggest narrative in web3 has been the explosion of the inscription ecosystem, with Ordinals being the initial starting point. It is a technology that assigns a unique serial number to each satoshi on BTC. For further reading: Understanding the Bitcoin Ordinals Protocol and BRC20 Standard: Principles, Innovations, and Limitations

The core founder, Casey, submitted the basic version of the Runes code in September last year, but the mainnet has not yet been launched. Therefore, during the inscription craze in September, projects like RuneAlpha forked the code early and issued protocols like RunesAlpha. Although there are claims of plagiarism, the rapid growth of total market capitalization to hundreds of millions in just a few months shows the immense potential of the Runes protocol.

The official version of the Runes protocol, designed by the founder of the Ordinals protocol, Casey, is expected to be officially announced around April 20, 2024. It will be launched directly on the BTC mainnet, so various project parties wishing to issue Runes assets, as well as wallets and NFT/FT trading markets wanting to support Runes, will face one of the toughest challenges in the blockchain industry: how to sprint directly to the mainnet without a testnet!

The official Twitter statement is highly confident~ And here’s a new word to learn: Seppuku

This article will systematically sort out the changes in the underlying fields of the Runes project, allowing everyone to fundamentally understand the differences between Runes and FT protocols like BRC20 and ARC20, and make rational decisions by comparing their advantages and disadvantages.

2. How is additional information recorded on Bitcoin?

There are two mainstream off-chain data attachment solutions on Bitcoin: engraving and etching.

2.1. Basic Principles of Etching

Runes use etching technology, which is a simple and intuitive way to record information on the chain: that is, writing into the op-return field of the UTXO (Unspent Transaction Output) in BTC, a function enabled in Bitcoin Core client version 0.9 (2014). OP-RETURN creates a clear, verifiable, non-consumable output, allowing data to exist on the blockchain, similar to UTXO outputs, but cannot be consumed.

In BTC blockchain explorers, you can easily see that this transaction has attached an op-return message, as shown in the image below:

Here, the output #3 is actually floating; although it occupies an output position of the UTXO of this transaction, it is a closed-loop rectangular shape, indicating that it cannot be transferred or consumed again. Thus, it acts like a note section of the transaction, remaining in Bitcoin's storage space, indexed by the transaction hash.

You may notice that there is a RUNETEST after OPRETURN; this is the result of decoding the specific content. By clicking the detail button, you can find a code string like 52554e455f54455354, which is actually a hexadecimal encoded data string. After decoding, it becomes RUNE_TEST. Similarly, there are other encodings in the details, which, when decoded, will form a string, likely in JSON format, reflecting the deployment, minting, issuance, and other meanings of Runes assets.

2.2. Basic Principles of Engraving

In fact, in protocols like Ordinals/BRC20, metadata is embedded on-chain by writing it into the witness data of the transaction. This engraving process is achieved through Segregated Witness (SegWit) and Pay-to-Taproot (P2TR), which includes two phases: commit and reveal, completing the process with two transactions.

P2TR is a type of transaction output introduced in the Taproot upgrade in 2021, allowing different transaction conditions to be stored more "privately" on the blockchain. The reason for the enhanced privacy is that the specific complete content can only be seen when revealed. Specifically, the generation of a P2TR address uses a script hash, and when spending, the actual script (containing the inscription data) is provided. Therefore, to upload inscription data, a UTXO (commit transaction) must first be generated that pays to the P2TR address created by this script. When spending this UTXO, the actual script must be provided in the witness script, thus uploading the inscription data to the chain (reveal transaction).

The Ordinals protocol is quite easy to understand: after completing this engraving process (commit and reveal), both transactions are on-chain, and the Ordinals protocol defines that this inscription is bound to the first sat of the first input. Thus, the binding process is engraving, and the result is the inscription.

2.3. Comparison of the Two Data On-Chain Solutions

Etching:

• Advantages: Simple, intuitive, and clear logic; low transaction costs; does not occupy full node memory pool.

• Disadvantages: Limited to 80 bytes in length; requires highly compressed data encoding.

Engraving:

• Advantages: Almost no size limitation; has certain privacy protection capabilities; offers various play styles (time locks, proof of work), etc.

• Disadvantages: Requires two transactions to be on-chain, leading to higher final costs; long commit duration puts pressure on the full node memory pool.

3. Interpretation of Runes' Underlying Design

The initial code of the Runes protocol was released by Casey in Ordinals version 0.11, and the latest Ordinals has evolved to version 0.18. The significant version changes give us the opportunity to step into the design process of a top-level protocol, similar to how Shijun previously interpreted standards like ERC721/ERC3525/ERC3475. For further reading:

Let’s explore the field changes between the starting and ending versions of Runes to interpret the value of Runes according to regulations.

3.1. Interpretation of Runes Version 0.11

The initial Runes overall fields were divided into three parts: edicts (asset transfer information), etching (asset deployment information), and burn (destruction).

Specifically, when the op_Return of a transaction decodes to present the edicts information correctly, the off-chain parser will calculate that the user's assets have been transferred, with the output being the target destination of the transfer.

Similarly, the content of etching directly presents the main information for asset deployment. We can compare it with ERC721; the biggest difference is that limit and term restrict the number of mints and the minting range. This is a fundamental difference between inscriptions, runes projects, and Ethereum smart contract asset issuance. Due to the lack of smart contract verification on-chain, there is no real-time verification capability. If a project party issues assets on-chain while running a new inscription protocol to customize its whitelist minting, token economics release rate, royalty payments, etc., it will lack consensus, and no one will participate in the project. Therefore, inscription protocols (BRC20, Atomical, Runes) have unified the asset issuance methods and the ways users participate in minting, promoting a fair launch concept that fully opens user participation, further preventing project parties from excessively intervening in asset market perceptions.

Even if project parties accumulate assets through hoarding to control the market, they need to pay a huge gas cost, which can be perceived by users and freely chosen.

The initial version of the Runes protocol design was already quite complete. Therefore, the evolved RuneAlpha, even if it is a clone, occupies a considerable market scale, with a cumulative 820,000 transactions and consuming 312 BTC in fees.

Users can easily use the design of the rune field itself to achieve asset composition and splitting. Moreover, once Runes assets are cross-protocol combined with Ordinals, Atomical, and other assets, they can leverage the diverse expressiveness of op_Return to achieve splitting.

What has the latest Runes protocol achieved in version 0.18, and what considerations led to such fields?

3.2. Interpretation of Runes Version 0.18

Understanding Runes 0.18 is quite challenging due to the lack of a testnet; we can only see the logic from Casey's source code. The final sorted fields can be divided into four aspects:

First, edicts still define the direction of asset transfer, which is basically consistent with RuneAlpha, but the difference is the addition of a pointer parameter, which is used to modify the default transfer direction of the asset. The original default transfer was the 0 position; with this parameter, it can be set to 1 or others. The design concept is to adapt to multiple Runes assets being transferred simultaneously, reducing the op_Return encoding amount, ultimately lowering user transaction costs.

Secondly, a Mint field has been added. Since its mint is at the same level as edicts, it means that a transaction can only mint one asset, which is different from the previous RuneAlpha, where the deliberate design allowed a transaction to mint a large number of new assets. This balances the starting line for technical asset holders and ordinary users, as everyone must compete for gas to obtain assets.

Major Changes in Asset Deployment Methods

The last significant change is in etching, which is the detailed design of asset deployment. The complete field content is as follows:

It’s quite complex, indeed, for deploying new assets, so let’s explain it in detail~

First, a significant change is the design to reduce the opReturn encoding amount. Since opReturn is limited to 80 bytes in length, every encoding space must be cherished. Therefore, Casey changed the asset ID from a unique ID value generated by the block height + transaction sequence number to a string format of block height + colon + transaction sequence number. Since the Bitcoin mainnet has only over 800,000 block heights, the final ID encoding saves half the space. Don’t underestimate this; in bulk minting and transferring scenarios, it significantly reduces costs.

Secondly, to ensure fairness for participants, the terms field now means that asset deployment and minting no longer start based on the block height of the transaction on-chain, as it was in RuneAlpha, but rather the height and offset specified by the issuer as the start and end points. This way, users do not need to constantly monitor the memory pool to discover the latest minting opportunities and do not have to worry too much about falling into phishing scams. After all, project parties can deploy assets in advance and then conduct a series of operational promotional activities, ultimately allowing users to participate. Besides the height range as a measure of participation time, there is also a cap to control the total number of mints, further regulating the scale of asset issuance. It is no longer unlimited minting but limited issuance, first come, first served.

As an asset issuance protocol, controlling the scale and rights of the issuer is a significant challenge. For inscriptions, the most crucial aspect is the asset name. In Runes, names are a scarce resource, with a name length release rule accompanying the halving cycle. Initially, only longer names can be deployed, and over time, shorter names can be deployed.

One can imagine that every time a name length release cycle occurs, it will trigger a rush similar to domain name registration. How can we prevent project parties from being registered first?

This introduces the most significant change in the deployment of Runes: the deployment process is no longer just a single op_Return transaction but an engraving. As mentioned earlier, the etching technology can provide some privacy protection through commit and reveal. The new version's premine serves this purpose, requiring a certain interval between the commit and reveal transactions. Only when revealed does the market know the name the issuer intends to use. At this point, even if other hackers want to create phishing assets, even if experts see the name in the memory pool, they cannot bypass this advance notice limitation, thus protecting the issuer's control over the name.

In the final version 0.18, a turbo field has also been added, which currently does not have a clear public function, implying participation in future changes at other protocol layers.

4. How to Evaluate the New Version of the Runes Protocol

Through the interpretation of the underlying fields above, Shijun cannot help but admire Casey's unique insights into asset issuance. In just two months, he designed and implemented a protocol that closely fits market demand pain points. This is a market that measures value by price. The inscription protocol initially opened up a lot of imaginative space as a completely differentiated smart contract model, allowing a large number of users to genuinely enter the BTC circle, further triggering the BTC L2d boom. However, the initial roughness of the inscription protocol led to a proliferation of low-quality assets, with rampant piracy and rug pulls tarnishing the inscription ecosystem. The emergence of Runes, with a higher degree of customized issuance management, will bring order to the market.

Moreover, the Runes protocol is embedded within the Ordinals protocol itself, leveraging the user base of Ordinals from the start, allowing the issuance of the Runes protocol to stand on the shoulders of giants. As an FT protocol, it compensates for the previous limitations of Ordinals, which only served as NFTs and lacked market operation play styles. Finally, using the op_Return method to record on-chain data allows Runes assets to possess any institutional and replicable ledger capabilities, further reducing centralization and enabling Runes assets to have a certain level of security comparable to BTC.

What are the drawbacks of the Runes protocol? Indeed, there are some. First is the market timing issue. Although Casey chose to launch the Runes protocol simultaneously with the BTC halving, the highly tense development timeline, even changing protocol content just yesterday, has resulted in fewer institutions being able to access the Runes protocol immediately. Consequently, the protocol ecosystem will require more time to ferment. Secondly, the complexity of the rules has increased. The rules for issuance management are already quite complex, but the name changes allow issuers to initially choose longer names, combined with special dot symbols, making the maximum length of a Runes protocol name reach: B•C•G•D•E•N•L•Q•R•Q•W•D•S•L•R•U•G•S•N•L•B•T•M•F•I•J•A•V, almost 55 characters long. This inadvertently amplifies the risk of users being phished, and it is also challenging for mobile plugins and other interfaces to display it fully. Lastly, there is the future compatibility issue. The now-popular Atomical protocol has already moved towards the AVM stage, allowing inscriptions to break free from mere token speculation and further transition into the BTC L2 or BVM narrative. This indicates that Casey is slightly lagging behind, limiting the Runes project to only the issuance aspect.

References for this article:

• Runes protocol encoding and decoding analysis: https://github.com/okx/js-wallet-sdk
• Official source code of the Runes protocol: https://github.com/ordinals/ord