Original Author: Trustless Labs

There are less than 3 days left until the 840,000th block for the BTC halving, which also means that the long-awaited Runes protocol for the entire BTC ecosystem is about to launch. As the largest fair launch in the BTC ecosystem, it may face significant competitive pressure, but it remains the most substantial and public alpha opportunity in the current crypto world.

Although platforms like OKX Wallet and Unisat have already provided public engraving platforms, running your own Bitcoin full node and index, and understanding the principles behind Runes operation will bring certain advantages in gaining more leverage in the competition.

In this article, Trustless Labs will introduce the Runes protocol from three aspects: technical implementation, distribution rules, and estimated costs.

The Runes protocol is an asset protocol for issuing fungible tokens on the Bitcoin network, deployed by Casey, the founder of Ordinals. The fundamentals of Runes are that it inherits the legitimacy of the Ordinals protocol, becoming the next window for fair distribution of assets on the BTC chain. The Ordinals community needs to leverage Runes to strive for pricing power over BTC ecosystem token assets. Casey even stated that if the Runes ecosystem does not reach a market value of 1 billion USD within a month of its launch, he would commit seppuku…

It can be expected that after the halving, the Runes protocol will bring very active on-chain interactions. Points of interest will include but are not limited to:

• The genesis rune hardcoded by Casey in the Runes protocol;

• Airdrops of Runes tokens corresponding to NFTs like RSIC and Runestone;

• Community-led deployment and FOMO of Runes tokens;

Principles

The BRC 20 method is known as engraving, which involves writing token data into the signature of the SegWit and binding the data to a specific satoshi. Essentially, this treats BTC as storage space, with transfers completely relying on off-chain BRC 20 index ledgers. To ensure the legality of transactions, BRC 20 transfers must first engrave the corresponding tokens into a transferable state, and then complete the transfer through a second transaction that moves the corresponding engraved UTXO.

The Atomicals method is known as coloring, where the balance of ARC 20 relies on the number of satoshis under a UTXO, strictly following the 1 token = 1 satoshi correspondence. Therefore, ARC 20 transfers can be processed by the BTC network as regular transactions, with a simpler index that utilizes BTC's native features.

The Runes method is known as etching, where a balance of Runes is bound to a UTXO. The data regarding the balance amount, token symbol, and other information is recorded under the OP-RETURN of the transaction. OP-RETURN can be seen as a note for this transaction (maximum 80 bytes), and the data it contains in JSON format indicates how many Runes tokens are represented by the UTXO of this BTC transaction. Recognizing these tokens requires the Runes indexer.

In summary, Runes bind to BTC UTXOs or treat BTC UTXOs as pointers to Runes tokens, with OP-RETURN serving as the assignment statement for the pointer.

When Runes tokens are transferred, the UTXO representing the Runes tokens must be used as input, with the transfer amount written in OP-RETURN, and a specified UTXO as the first output. A designated amount of Runes tokens will be transferred to the target address of UTXO 1, while the remaining Runes tokens will automatically bind to other UTXOs like UTXO 2 in order. UTXO 1 can be sent to someone else's address, while UTXO 2 can be sent back to oneself as change, thus completing a Runes transfer. Additionally, Runes also includes a burn function, allowing for token destruction.

Unlike BRC 20, which only uses BTC to store transfer records, Runes tokens are strictly UTXO-bound, allowing them to benefit from various advantages associated with BTC UTXOs. This method is similar to ARC 20, but the difference lies in that Runes' UTXOs can represent any number of tokens, while the quantity of ARC 20 is strictly related to the number of satoshis contained in the bound UTXO (making it difficult to split). However, ARC 20 is also less dependent on indexers, while the legality of Runes token transfers still requires records from the Ord index ledger.

struct Runestone {
edicts: Vec\<Edict>,
etching: Option\<Etching>,
mint: Option\<RuneId>,
pointer: Option\<u32>,
}
struct Edict {
id: RuneId,
amount: u128,
output: u32,
}

The flexibility of the JSON data under OP-RETURN allows for batch transfers of Runes tokens in one operation, including transferring different types of Rune assets like RuneA and RuneB in the same Bitcoin transaction.

Distribution Rules

In the initial distribution process of Runes tokens, the token deployer must first define the token information and distribution rules.

Token information includes the minimum divisible unit, asset name, name's symbol separator, symbol, etc. It is important to note that the name of Runes assets has no length limit and can include separators like •, which may be quite complex. Care should be taken to recognize these when minting new assets.

struct Etching {
divisibility: Option\<u8>,
premine: Option\<u128>,
rune: Option\<Rune>,
spacers: Option\<u32>,
symbol: Option\<char>,
terms: Option\<Terms>,
}

In the distribution rules section, Runes allows deployers to pre-allocate tokens to themselves, so it is important to recognize whether it is a fair launch. This feature can be used for the distribution of assets like Runestone and Rsic.

Under the Terms data of the distribution rules, it includes limits on the number of tokens minted in a single transaction, total mint counts, and the start and end blocks for minting. The total mint count can be set to unlimited, with no limits on time or quantity; the 0th rune UNCOMMON•GOODS deployed by Casey is an example of this.

struct Terms {
amount: Option\<u128>,
cap: Option\<u128>,
height: (Option\<u64>, Option\<u64>),
offset: (Option\<u64>, Option\<u64>),
}

At the same time, the user-initiated minting process needs to write the data type of Runestone under OP-RETURN (unrelated to the rune NFT Runestone). A single transaction can only mint once, so to gain more leverage, multiple UTXOs need to be used under one address.

Runes will start at block 840,000, and the ord index has already been updated to the latest version 0.18.1, which now fully supports querying Runes tokens, etching (equivalent to BRC 20's deploy), minting, and other functions. Casey has also stated that a portion of Runes tokens will be hardcoded into the ord indexer, activated at the halving block. These assets will be fairly distributed and can be freely minted. Names mentioned by Casey include COMMUNISTRUNE, ANARCHISTRUNE, and CYPERPUNKRUNE. The genesis rune named UNCOMMON.GOODS can already be seen in the index.

The deployment of Runes asset names is restricted by the Ord index, with names of 13-26 characters being freely deployable after block 840,000, while names of 12 characters are gradually unlocked. Every 17,500 blocks (approximately 120 days), the deployment of shorter names will be unlocked, so minting a 4-character token will require a waiting period of 3 years.

Although early super-long names are not conducive to speculation, they can be designed with special symbols to represent assets. These symbols conform to the Unicode standard, allowing for the inclusion of many emoji expressions. Choosing a good emoji is also something to consider when deploying memes.

Estimated Costs

The current Runes protocol code has basically been finalized and has been running on the testnet for some time, allowing for some cost predictions. We have already seen up to 497 Runes test tokens deployed on the signet testnet by running the ord index, and even more than 963 on the testnet. We have also conducted some experiments and tests on the signet to estimate the costs and progress of minting.

Signet testnet Runes tokens 0 ~ 9:

THESE•WILL•BE•WORTHLESS
GREG•GREG•GREG
CUBS•FIRST•RUNES•TOKEN
AMAZING•KODA•FART
SORA•PARTY•STARTS•FIVE•DOLLARS
WAKE•N•BAKE
RECURSIVE•ROBOTS•RUNES•TEST
FRENCH•WON
SATOSEA•XYZ

We minted several Runes tokens on the signet testnet using the ord command:

$ ord --index-runes --bitcoin-rpc-password xxx --bitcoin-rpc-username xxx -s wallet mint --fee-rate 1 --rune HARRY•POTTER•OBAMA•SONIC•IO•INU
{
"rune": "HARRY•POTTER•OBAMA•SONIC•IO•INU",
"pile": {
"amount": 1000,
"divisibility": 0,
"symbol": "🧹"
},
"mint": "645829 bdaf 105 cce cc0 12629 a 3 bbb 6 e 9 dfcfe 9 2fa 09499 ea 54 b 8709 2c 9100946"
}

The transaction is as follows: https://mempool.space/zh/signet/tx/645829bdaf105ccecc012629a3bbb6e9dfcfe92fa09499ea54b87092c9100946

Specify the destination as the address receiving Runes tokens:

$ ord --index-runes --bitcoin-rpc-password xxx --bitcoin-rpc-username xxx -s wallet mint --fee-rate 1 --rune MAOBY•THE•CUTEST•CAT --postage 1000 sat --destination tb 1 p 43 k 8 gxevpc 0x 3 hthv 9 dm 33589 gecn 8 mr 4 rk l3 03 js 3 gtvmpehltqg 2 mmc 4
{
"rune": "MAOBY•THE•CUTEST•CAT",
"pile": {
"amount": 100,
"divisibility": 0,
"symbol": "🐈"
},
"mint": "32125 d 247 a 282 ebf 53 b 89 3a 17 f 3 c 2c 99 a 774774923 3d c 010 bd 9 ae 2934540 c 981"
}

The transaction is as follows: https://mempool.space/zh/signet/tx/32125d247a282ebf53b893a17f3c2c99a7747749233dc010bd9ae2934540c981

It can be seen that a single mint transaction consumes about 230 vB in size. Based on market heat and FOMO sentiment, if we calculate the fee rate under extreme conditions as 300-1000 sats/vB, the cost of minting one would be approximately 0.0023-0.00069 BTC (150 u-50 u). Additionally, ord supports specifying a destination address, allowing for the splitting of UTXOs and concurrent batch minting to the target address.

If FOMO sentiment is high after the halving, with 3000 transactions per block being Runes mint transactions, and assuming an average fee rate of 200 sats/vB, the daily minting of Runes tokens would consume approximately 198.72 BTC in gas costs, providing some reference for calculating the early FOMO market value.