Understanding the New Protocol "Rune" Proposed by Ordinals Founder as a Replacement for BRC20 and the Story Behind It
The self-created "art gallery" has become a paradise for speculators, which makes Casey very uncomfortable.Author: BlockBeats
Today, Casey Rodarmor, the founder of the Bitcoin NFT protocol Ordinals, proposed a new design concept for a Bitcoin FT protocol called "Rune," also known as the "Rune" protocol.
What distinguishes this protocol from existing FT protocols on the Lightning Network, such as BRC-20 and Taro/RGB? Why did Casey suddenly propose the concept of the "Rune" protocol? What progress has been made in less than a day since the concept was introduced?
Rhythm BlockBeats will provide you with a detailed overview of all aspects of the "Rune" protocol to date.
Design Starting Point of the "Rune" Protocol
Casey Rodarmor summarized the biggest feature of the "Rune" protocol in one sentence—a simple, UTXO-based FT protocol that provides a good user experience for Bitcoin users.
Casey believes that if the protocol has a small on-chain "footprint" and promotes trusted UTXO management, it may reduce "harm" compared to existing Bitcoin FT protocols. At least, the current popularity of BRC-20 has already created a large number of "garbage" UTXOs.
Casey compared the "Rune" protocol with other existing Bitcoin FT protocols in the following four aspects:
Complexity: How complex is the protocol? Is it easy to implement? Is it likely to be widely adopted?
User Experience: Are there any implementation details that could negatively impact user experience? In particular, protocols that rely on off-chain data have a lighter on-chain "footprint" but introduce significant complexity. Additionally, users either run their own servers or find existing servers to interact with.
State Model: UTXO-based protocols naturally fit Bitcoin better and promote UTXO set minimization by avoiding the creation of "garbage" UTXOs.
Native Token: Protocols that require a native token for operation are cumbersome and extractive, making them less likely to be widely adopted.
The comparison results are:
BRC-20: Not UTXO-based and quite complex, as it requires using the Ordinals protocol for certain operations.
RGB: Very complex, relies on off-chain data, and has been in development for a long time without widespread adoption.
Counterparty: Certain operations require the use of a native token, rather than being UTXO-based.
Omni Layer: Certain operations require the use of a native token, rather than being UTXO-based.
Taproot Assets (Taro): Somewhat complex, relies on off-chain data.
So how will the "Rune" protocol specifically be implemented to address the above pain points?
Implementation of the "Rune" Protocol
Overview
The balance of "Rune" tokens is directly contained within UTXOs, which can hold any number of "Rune" tokens.
If a transaction includes an output, and the script pubkey of that output contains an OP_RETURN followed by a data output representing the ASCII uppercase letter "R," then the transaction contains a protocol message. The protocol message consists of all data outputs following the first data output.
If invalid protocol messages and "Rune" tokens are inserted into a transaction, the "Rune" tokens will be burned. This will allow the "Rune" protocol to upgrade in the future, avoiding allocation errors of "Rune" tokens that have already been created/assigned in the old version of the protocol.
Integers are encoded as prefix variables, where the starting part of the variable determines the byte length of the "Rune" token.
Transfer of "Rune" Tokens
The first data output in the protocol message is decoded into an integer sequence, which will contain three pieces of information: "ID," "OUTPUT," and "AMOUNT." If the number of decoded integers is not a multiple of three, the protocol message will be considered invalid.
ID: Specifies which "Rune" token is being transferred. Each "Rune" token is assigned an ID when created, starting from 1, with earlier created "Rune" tokens having smaller ID values.
OUTPUT: Determines which output the allocation is assigned to.
AMOUNT: The number of "Rune" tokens being transferred. If the AMOUNT is 0, it represents the total number of remaining "Rune" tokens in the account.
After processing all operations contained in the complete integer sequence, if there are still "Rune" tokens that do not require operations, they are all allocated to the first non-OPRETURN output. Additionally, if "Rune" tokens are allocated to an OPRETURN output containing the protocol message, the "Rune" tokens may be burned.
Creation of "Rune" Tokens
If there is a second data output following the protocol message, the transaction is a "Rune" token creation transaction. This part of the data output will be decoded into two integers: "SYMBOL" and "DECIMALS." If there are any additional integers, it will be considered invalid.
SYMBOL: Equivalent to the ticker of BRC-20 (i.e., token name), supporting up to 26 characters, with usable characters being A-Z.
DECIMALS: Precision, determining how many decimal places the "Rune" token can support.
If the "SYMBOL" has not been used, the "Rune" token will be assigned an ID value, with the first created "Rune" token having an ID value of 1. The names BITCOIN, BTC, and XBT are prohibited. If the "SYMBOL" has been used, the creation will be invalid. In other words, the "Rune" protocol still does not support the creation of tokens with the same name.
Display of Bitcoin Balance in UTXOs
In a UTXO, the Bitcoin balance will be displayed as BITCOIN, BTC, or XBT, or displayed as ID value 0.
Why Did Casey Suddenly Propose the Concept of the "Rune" Protocol?
In the official manual of the Ordinals protocol, we can see that Casey's vision for the Ordinals protocol is to create "digital artifacts," or "NFTs," through Bitcoin. However, with the development of the Ordinals protocol, the number of inscriptions related to BRC-20 has accounted for over 85% of the total inscriptions.
Casey has been dissatisfied with BRC-20 for a long time, especially with his recent controversial tweets, which reflect his negative attitude towards BRC-20:
The Christmas gift I want most is for speculators to discover Taproot Assets (Taro), so they can stop minting BRC-20 tokens.
Can't we engrave "transfer inscriptions" for the holders of BRC-20 tokens to lock their balances, so they have to send the transfer inscriptions to themselves to unlock their balances?
In Casey's view, the "art gallery" he created has become a paradise for speculators, which makes him very uncomfortable. Not only has his "art gallery" turned into a "big casino," but Casey also has a very negative attitude towards FT itself:
In this blog post proposing the Rune protocol concept, Casey stated at the end of the article that "the world of FT is almost an irredeemable abyss filled with deception and greed."
The proposal of the Rune protocol concept can be seen as Casey's "surgical detox" for the Ordinals protocol—despite being the founder of the protocol, he has no way to unilaterally eliminate what he considers to be the "tumor" BRC-20 that is parasitic on the Ordinals protocol. Thus, he threw out this idea—here is the "art gallery," if you want to continue Degen, I have an idea, how about going to the "big casino" to Degen?
That said, Casey is merely proposing the concept of Rune as a Bitcoin FT protocol; he himself has no intention of implementing it. However, Casey's influence is evident, and we can already see how excited players are in less than a day.
What Developments Have Occurred in Less Than a Day for the Rune Protocol?
The Bitcoin NFT trading market Ordinals Wallet announced at 3 PM the deployment of the first token of the Rune protocol, $RUNE.
However, some pointed out in the comments of the tweet that this seems to be an invalid deployment…
Additionally, @TO has initiated a public bounty, offering a $100,000 reward to the first team that creates a Rune protocol indexer.
It is important to remind everyone that the validity of the deployment of $RUNE is currently inconclusive, as the protocol is still just a concept proposed by Casey, with no drafted standards or code produced yet. Beware of various scams!
Conclusion
Casey's proposal is more of a helpless statement to everyone—I have a better way than BRC-20, could you consider it and let Ordinals return to its original development direction?
So will BRC-20 "die"? I think there is no need to be overly pessimistic. Over the past few months, BRC-20 has attracted a large number of teams to build, and these teams are unlikely to give up just because of Casey's concept. Moreover, BRC-20 is also dynamically evolving; could it possibly combine with the Lightning Network to address some current pain points? These are all worth looking forward to.
Finally, a soul-searching question from Casey—
99.9% of FT are memes and scams; I'm not sure if creating a new FT protocol for Bitcoin is really a good idea?
