A Fairer Asset Issuance Method? An Extended Discussion on the Runes Protocol and the "Public Engraving" Issuance Mechanism
The author of this article combines some of the latest topics on Runes to write this piece, exploring the past of Runes and the Ordinals protocol, as well as similar asset issuance methods. It is believed that this will help everyone understand the Bitcoin ecosystem.Author: MiX
Editor: Faust, Geek Web3
On March 2, 2024, the founder of the Runes ecological infrastructure project Rune alpha engaged in a discussion with Casey, the founder of the Runes protocol, in a public issue on GitHub. Both parties explored how to expand the "public inscription" mechanism of the Runes protocol. Topics included:
- Should the requirement for "public inscription" to not reserve be relaxed?
- Pointed out the view that Runes inscriptions issued through "public inscription" do not have management rights.
- Proposed a set of issuance mechanism ideas based on the cooperation of inscription NFTs and rune FTs.
Due to a strong interest in Bitcoin derivative asset protocols, the author of this article combines some of the latest topics regarding Runes to write this article, exploring the past of Runes and the Ordinals protocol, as well as similar asset issuance methods, believing it will help everyone understand the Bitcoin ecosystem.
What is the Runes Protocol
The so-called Runes protocol is a protocol for issuing fungible tokens on the Bitcoin network, reconstructed by Casey, the founder of Ordinals, after releasing the Ordinals scheme. It is built based on the characteristics of Bitcoin UTXO, and the overall design concept is very simple.
It is worth mentioning that the Runes protocol plans to launch its mainnet during Bitcoin's 2024 halving (block height 840000), which is expected to be in late April this year. The Runes protocol is still in the process of optimization and version iteration.
Before briefly explaining the principles of Runes, let’s quickly understand the background and what the so-called "public inscription" really represents.
Casey, the proposer of Runes, initially did not intend to create a fungible token protocol. As early as December 2022, Casey released the Ordinals protocol, intending to permanently store NFT data on the Bitcoin blockchain. In simple terms, it means recording NFT metadata like inscriptions in the witness data of Bitcoin transactions (the witness mainly contains digital signature information), allowing any form of content (such as text, images, etc.) to be inscribed on specified satoshis.
Subsequently, the wheels of history began to turn. On March 8, 2023, an anonymous developer @domodata created a BRC-20 standard for issuing fungible tokens based on the Ordinals protocol, which established a unified format and attributes (Token name, total supply, maximum minting amount per transaction, etc.) for derivative asset data that needed to be uploaded to the Bitcoin chain, and then used an indexer to parse and track this information, displaying wallet accounts and asset amounts related to BRC-20 tokens.
The key point is that the issuance of BRC-20 relies on the Ordinals NFT protocol, so the initial issuance mechanism becomes similar to the NFT minting process, inherently possessing the "first come, first served" characteristic: whoever mints first owns it, which is completely different from the Ethereum ERC-20 asset issuance where "the project party first deploys the asset contract, defines the asset distribution mechanism, and can control it as they wish."
This Fair Launch characteristic allows most people to have a fair opportunity to participate in the initial issuance of fungible tokens, with no reservations or lock-ups by the project party, enabling everyone to participate at the very beginning of the asset issuance. Soon, BRC-20 sparked a wave of derivative asset issuance on the Bitcoin chain, even directly initiating this bull market. Therefore, it is evident that the "public inscription" issuance method is very important for the Runes protocol.
However, BRC-20 also brought many problems: every operation of BRC-20 assets must initiate specific transactions on the Bitcoin chain. With the popularity of BRC-20 assets, the Bitcoin UTXO dataset has rapidly expanded, leading Bitcoin core developers to publicly question BRC-20.
Casey, the founder of Ordinals, not only opposes BRC-20 but also does not recognize FT assets issued based on Ordinals. However, the popularity of BRC-20 made him feel that although 99% of tokens are scams and gimmicks, these things will still persist like a casino.
At the same time, BRC-20 has left "too many traces" on the Bitcoin chain, burdening Bitcoin nodes with data storage, but if someone proposes a set of asset protocols that can "lighten the load" on on-chain data, it might alleviate the problems brought by BRC-20.
Thus, Casey decided to build a "better fungible token protocol" for Bitcoin, and on September 25, 2023, he released the preliminary concept of the Runes protocol.
From a technical perspective, the Runes protocol is built on Bitcoin UTXO and additional information. Each transaction trigger must carry the off-chain generated digital signature information on-chain, and we can include messages in a specific format within the signature information. The Runes protocol uses the OP_RETURN opcode to mark "specific messages," which are the information related to changes in Runes assets.
Compared to the BRC-20 protocol, Runes has many advantages, the most important of which are:
Simplified transaction steps that do not generate unnecessary UTXOs, better "lightening the load" for Bitcoin nodes. Additionally, a BRC-20 transfer transaction only supports one recipient and one type of token, while Runes supports transferring to multiple recipients simultaneously and can transfer multiple types of Runes tokens.
Asset data storage and indexing are more straightforward: BRC-20 data is stored in JSON format within the witness data of specific transactions and is based on an account model, where asset balances are associated with designated accounts. In contrast, Runes protocol data is stored in the OP_RETURN field of specific transactions, and the asset recording method adopts the UTXO model, allowing it to be "isomorphically bound" to UTXOs on the Bitcoin chain.
When confirming a person's Runes asset status, it is only necessary to verify the special UTXOs associated with Runes assets that the person owns. Although some information still needs to be traced for calculations, there is no need to scan the complete UTXO set on the Bitcoin chain like BRC-20, making this lightweight approach more friendly for data indexing.
- Compatibility with UTXO functional expansion layers: The UTXO-based design of Runes allows it to better integrate with UTXO-based functional expansion layers such as CKB, Cardano, and Fuel. Through "UTXO isomorphic binding" similar to RGB++, these functional expansion layers can provide smart contract scenarios for Runes.
Having briefly discussed the technology, let’s return to the issuance mechanism mentioned at the beginning of this article. Casey designed two issuance methods for Runes: "fixed total supply" and "public inscription":
Fixed total supply means that the issuer directly inscribes all Runes and then distributes them, which is relatively more centralized.
Public inscription means setting parameters for the issuance of Runes, such as specifying a block height or timestamp. During the time period that meets the rules, the total amount of the rune will be determined by how much the user mints.
The scenarios and mechanisms corresponding to these two issuance methods are completely different, and we will only discuss "public inscription" below.
In fact, Sondotpin began discussing this topic from the Runes Issues #124 and received Casey's approval.
The specific content of Issues #165 is as follows:
Sondotpin: Currently, in public issuance, the project party/issuer cannot reserve Runes in advance, which limits the opportunity for the project party to design an excellent token economic model.
Casey: Please refer to the previous Issues #124. I am considering relaxing this requirement, allowing issuers to reasonably arrange runes during issuance, even beyond the set parameter range. If designed this way, relevant information will be prominently displayed on the details page of the Runes.
Sondotpin: Can we design a mechanism for multiple issuances, such as having two rounds of "public inscription" for Runes, with different parameters set for each round?
Casey: I am not inclined towards such an approach, because Runes inherently do not have a "manager." The issuance authority should not be held by a single entity with special privileges. However, you can add an inscription when issuing runes, and then issue new runes based on that inscription, allowing both rounds of issuance to be the same asset. Of course, you can also use a pre-mined approach and then issue through other distribution methods.
If the CTV function can be successfully launched in the future, there will be no need for protocol support; CTV can directly set conditional templates in advance, allowing for airdrops and public issuances that meet the conditions.
Personal views on the discussion between Casey and SonPin:
1. Reserving some tokens in the early stages of a project is indeed necessary.
In the early stages, project parties need a certain token reserve to incentivize the core team and unite the community. If the protocol can be implemented according to this discussion, it will complement the fairness and value of public participation in "public inscription," allowing more valuable foundational projects to participate in the Runes ecosystem through "public inscription."
2. Whether to reserve and how to reserve is a means of self-certification for the issuer.
In fact, Casey has repeatedly stated in YouTube videos that 99.9% of fungible tokens are scams, and we should not grandiosely claim to change the world. It is better to be frank and admit that this is an industry full of gambling and speculation, treating everyone sincerely. IT'S JUST FOR FUN!
From issue #124 to #165, we can see that Casey has gained more recognition for the use cases of fungible tokens. The method of "public inscription" should not be questioned; expanding on this basis, such as adding a reservation mechanism, gives the issuer the right to choose and self-certify, and is also a good way to prevent bad money from driving out good money.
3. There will be more innovative space for inscription NFTs and rune FTs.
Casey's proposal for a multi-round issuance mechanism combining inscription NFTs and rune FTs is quite interesting. In the background knowledge, we mentioned that both Ordinals and Runes are protocols designed by Casey, which should be considered parallel protocols. However, they are both included in the Ord project on GitHub, with significant technical overlaps and collaborations, such as sharing underlying logic like synchronized blocks.
Current hot projects like Runestone and Runecoin are also innovations combining inscriptions and runes. The way Runecoin operates is the most mainstream pre-mining of inscriptions, where holding the RSIC inscription issued by Runecoin will continuously mine the project's runes, and then FT will be distributed when the Runes protocol goes live at the end of April. We look forward to more projects bringing innovative methods in the future.
4. Runes issued through the "public inscription" method do not have ownership.
Casey originally expressed that "Runes do not have ownership," but the author believes this specifically refers to Runes issued through the "public inscription" method not having ownership. The two-round "public inscription" plan proposed by SonPin would inevitably involve an address with extremely high privileges to operate, which is not what the crypto field hopes to see.
Just like the project Runecoin, after issuing 21,000 RSIC inscription NFTs, it quickly sent the parent inscription to Satoshi's address, effectively making it so that no one could use it again, thus promising not to increase issuance through technical means. This operation itself brought a wave of praise, significantly enhancing its public image.
PS: What is a parent inscription? Due to the slow interaction speed and high gas fees on BTC, when the number of operations is large, a parent inscription is generally set up first to improve efficiency. In the transaction of the parent inscription, multiple child inscriptions can be processed in bulk, saving blockchain storage space and processing time during interactions.
Finally, let's mention what Casey referred to as CTV, or "Check Template Verify."
CTV is a proposed protocol upgrade for Bitcoin aimed at enhancing the smart contract and locking capabilities of the Bitcoin network by allowing users to specify templates for future transactions when creating transactions. The activation of CTV will enable users to create more complex transaction types, such as reliable airdrops and open inscriptions, without explicit support from the protocol.
This CTV proposal increases the programmability and flexibility of the Bitcoin network, and in this discussion, it was mentioned that, simply put, it allows for the creation of a template for unlocking conditions using UTXO, which has the potential to create more gameplay for Runes. For example, through "Runes protocol + CTV," ten users can jointly use CTV technology to mint runes together and preset commitments for future Bitcoin payment transactions.
