Extended Discussion on the Runes Protocol and the "Public Inscription" Issuance Mechanism
TechFlow Selected TechFlow Selected
Extended Discussion on the Runes Protocol and the "Public Inscription" Issuance Mechanism
The Runes protocol is scheduled to launch on the mainnet at the time of Bitcoin's 2024 halving—block height 840,000—which falls in late April this year.
Navigating Web3 tides with focused insightsAuthor: MiX
Editor: Faust, Geek web3
On March 2, 2024, the founder of Rune Alpha—a Runes ecosystem infrastructure project—engaged in a public discussion on GitHub with Casey, the creator of the Runes protocol, debating how to expand the "public inscription" mechanism within the Runes protocol. Key topics included:
-
Should the restriction against reserving tokens during “public inscription” be relaxed?
-
The assertion that Runes issued via “public inscription” have no administrative rights
-
A proposed issuance mechanism combining inscribed NFTs and fungible Runes tokens (FT)
Driven by strong interest in Bitcoin-based derivative asset protocols, this article explores the historical context between Runes and the Ordinals protocol, along with innovative approaches to token issuance inspired by these recent discussions, offering insights valuable for understanding the evolution of Bitcoin’s ecosystem.
What Is the Runes Protocol?
The Runes protocol is a standard for issuing fungible tokens on the Bitcoin network. Created by Casey, the founder of Ordinals, it represents a new approach to fungible tokens built upon Bitcoin's UTXO model, featuring an elegantly minimalist design.
Notably, the Runes protocol is scheduled to launch on mainnet at Bitcoin’s 2024 halving event (block height 840,000), around late April this year. Currently, the protocol remains under active optimization and version iteration.
Before diving into the technical details of Runes, let's first understand its origins and what exactly is meant by 【public inscription】.
Casey, who introduced Runes, initially had no intention of creating a fungible token protocol. Back in December 2022, Casey launched the Ordinals protocol, aiming to permanently inscribe NFT data onto Bitcoin. In simple terms, this involves embedding NFT metadata directly into the witness data of Bitcoin transactions—fields primarily used for digital signatures—allowing arbitrary content (like text or images) to be etched onto specific satoshis.
(Image source: https://yishi.io/a-beginner-guide-to-the-ordinals-protocol/)
Then history began to turn. On March 8, 2023, an anonymous developer @domodata leveraged Ordinals—an NFT-focused protocol—to ingeniously create the BRC-20 standard for issuing fungible tokens. This standard defined a uniform format and attributes (token name, total supply, max mint per transaction, etc.) for derivative assets inscribed on Bitcoin, relying on indexers to parse and track ownership, displaying BRC-20 wallet balances accordingly.
Here’s the key point: BRC-20 issuance depends entirely on the Ordinals NFT inscription system, making initial distribution function similarly to NFT mints—naturally adopting a “first-come, first-served” model where early participants gain advantage. This stands in stark contrast to Ethereum’s ERC-20 model, where projects deploy contracts upfront, define allocation mechanisms, and retain full control over supply distribution.
This Fair Launch characteristic gave most users equal access to participate in the initial issuance of fungible tokens—no pre-mines, no locked reserves. Everyone could join from day one. As a result, BRC-20 quickly sparked a wave of derivative asset creation on Bitcoin, arguably catalyzing the current bull market. Hence, the “public inscription” method we are discussing today is critically important to the Runes protocol.
However, BRC-20 also brought significant issues: every BRC-20 operation requires a dedicated on-chain Bitcoin transaction, and as BRC-20 activity surged, the Bitcoin UTXO dataset rapidly expanded, prompting public skepticism from BTC core developers.
Casey, the Ordinals creator, not only opposed BRC-20 but outright rejected any FT assets built atop Ordinals. Yet, despite acknowledging that 99% of such tokens were scams or gimmicks, he recognized they would persist like casinos—unstoppable once established.
Meanwhile, BRC-20 left “excessive footprints” on the Bitcoin chain, burdening nodes with growing data overhead. A more efficient asset protocol minimizing on-chain data could help alleviate these concerns.
Thus, Casey decided to build a “better fungible token protocol” for Bitcoin, announcing the preliminary concept of Runes on September 25, 2023.
Technically speaking, the Runes protocol is built on Bitcoin’s UTXO structure and auxiliary data. Each transaction must publish digitally signed messages on-chain, which can carry specially formatted instructions. The Runes protocol uses the OP_RETURN opcode to mark these “special messages,” encoding all relevant asset state changes.
Compared to BRC-20, Runes offers multiple advantages, most notably:
1. Simplified transaction flow without generating redundant UTXOs, reducing load on Bitcoin nodes. Additionally, while a single BRC-20 transfer supports only one recipient and one token type, Runes enables multi-recipient and multi-token transfers simultaneously.
2. Simpler data storage and indexing: BRC-20 stores data in JSON format within witness fields and relies on an account-based model, linking balances to addresses. In contrast, Runes stores data in OP_RETURN fields using a UTXO-based model, enabling direct “isomorphic binding” with Bitcoin’s native UTXOs.
To verify someone’s Runes holdings, you only need to examine their Runes-linked UTXOs. While some historical tracing is still required, there's no need to scan the entire UTXO set as with BRC-20. This lightweight approach is far more indexer-friendly.
3. Compatibility with UTXO extension layers: Runes’ UTXO-native design allows better integration with platforms like CKB, Cardano, and Fuel. Using concepts similar to RGB++, these layers can provide smart contract capabilities for Runes through “UTXO isomorphic binding.”
Having briefly covered the technology, let’s return to the core topic of issuance mechanisms. Casey designed two distinct issuance methods for Runes: “fixed supply” and “public inscription”:
1. Fixed supply means the issuer mints all tokens upfront before distribution—more centralized in nature.
2. Public inscription sets issuance parameters—for example, specifying a block height or timestamp—whereby the final total supply equals the cumulative amount minted by users during the allowed window.
These two models serve very different use cases. Below, we focus exclusively on “public inscription.”
In fact, Sondotpin initiated this discussion in Runes Issue #124, receiving endorsement from Casey.
Issue #165 contains the following exchange:
-
Sondotpin: Under current public issuance rules, projects cannot reserve Runes ahead of time, limiting their ability to design robust token economies.
-
Casey: See prior discussion in Issue #124. I’m considering relaxing this rule, allowing issuers to reasonably allocate runes during issuance—even beyond original parameters. Any such exceptions would be prominently disclosed on the rune’s detail page.
-
Sondotpin: Could we design a multi-phase issuance mechanism—say, two rounds of “public inscription”—with different parameters per round?
-
Casey: I’m not inclined toward that approach, because Runes fundamentally lack a “manager.” Issuance authority shouldn’t rest with any single privileged entity. However, you could inscribe an NFT first, then issue new runes based on that inscription—effectively achieving dual issuance under one asset. Alternatively, you could pre-mine and distribute via other mechanisms.
If CTV functionality launches successfully in the future, explicit protocol support won't even be needed—CTV can natively enable conditional templates for airdrops and open mints once certain criteria are met.
Personal reflections on the discussion between Casey and SonPin:
1. Early token reservation is indeed necessary when launching a project
In the early stages, projects need token reserves to bootstrap operations, incentivize core contributors, and grow communities. If the proposed protocol updates go forward, they would complement the fairness and inclusivity of “public inscription,” enabling more fundamentally sound projects to enter the Runes ecosystem through fair launch mechanisms.
2. Whether and how to reserve tokens should be a choice—and proof—left to the issuer
Casey has repeatedly stated on YouTube that 99.9% of fungible tokens are scams—there’s no need to pretend otherwise. Be honest: this space is driven by gambling and speculation. Just admit it. IT’S JUST FOR FUN!
From Issue #124 to #165, we see Casey gradually embracing broader use cases for fungible tokens. The value of “public inscription” is unquestionable; enhancing it—such as adding optional reservation mechanisms—empowers issuers with self-verification tools and helps prevent bad actors from crowding out quality projects.
3. Greater innovation potential lies at the intersection of inscribed NFTs and fungible runes
Casey’s idea of combining inscribed NFTs and fungible runes in coordinated issuance phases is fascinating. As background knowledge, both Ordinals and Runes were created by Casey—they’re parallel protocols, yet integrated under the same “Ord” project on GitHub, sharing foundational logic like block synchronization.
Current trending projects like Runestone and Runecoin exemplify creative combinations of inscriptions and runes. Runecoin uses a popular “pre-inscription mining” model: holding its RSIC inscribed NFT continuously mines project runes, with final FT distributions occurring after the Runes protocol launches in late April. We look forward to more innovative models emerging in the future.
4. Runes issued via “public inscription” have no ownership
Casey originally said “Rune has no ownership,” but I believe this specifically refers to Runes issued via “public inscription” having no owner. SonPin’s proposal for two-stage public inscription would necessarily involve a highly privileged address performing actions—an outcome contrary to the ethos of decentralization.
For instance, after distributing 21,000 RSIC inscribed NFTs, the Runecoin team immediately sent the parent inscription to Satoshi Nakamoto’s address, rendering it unusable. This technical commitment against future minting earned widespread praise and goodwill.
PS: What is a parent inscription? Due to Bitcoin’s slow interaction speed and high fees, batch processing is often used. A parent inscription is created first, and within that single transaction, multiple child inscriptions are processed together—saving blockchain space and computation time.
Finally, let’s discuss CTV—“Check Template Verify.”
CTV is a proposed Bitcoin protocol upgrade that allows users to specify templates for future transactions when creating a current one, thereby enhancing Bitcoin’s smart contract and locking capabilities. Once activated, CTV will enable more complex transaction types—such as trustless airdrops and open etching—without requiring explicit protocol-level support.
The CTV proposal increases Bitcoin’s programmability and flexibility. Mentioned in this discussion, it essentially allows setting unlock conditions for UTXOs via templates, opening up new possibilities for Runes. For example, using “Runes + CTV,” ten users could jointly mint runes via CTV, pre-committing to future Bitcoin payment conditions or shared custody arrangements.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@MixWeb3
