Original article - Casey Rodarmor
Compile - Odaily
Yesterday, Ordinals creator Casey Rodarmor postedblog, introduced a new fungible token (FT) protocol Runes.
On whether Bitcoin needs FT, Casey Rodarmorits tweetsmeans that FT has two sides. On the one hand, 99.99% of FTs are shit and scams, which weaken the purity of Bitcoin; on the other hand, they bring a lot of fee income, developers and users to the Bitcoin ecosystem. “People love tokens and they are like cyberpunk casinos, so fee revenue is likely to be substantial and ongoing until concerns about (cyber) security budgets are fully alleviated.”
He added that FT protocols such as BRC-20, RGB and Taproot have already emerged. Compared to simple on-chain protocols, protocols like RGB and Taproot are complex and may pose challenges to the user experience. BRC-20 is very simple and can provide a good user experience compared to RGB/Taproot which requires off-chain data storage and retrieval infrastructure; but the problem with BRC 20 tokens is that they generate garbage UTXO and occupy bits coin space.
Rodarmor said Runes is a UTXO-based protocol that fits Bitcoin more naturally and promotes the minimization of UTXO collections by avoiding the creation of junk UTXOs.
The following content is from Casey Rodarmors blog post and compiled by Odaily
Im not sure if creating a new Fungible Token (FT) protocol for Bitcoin is a good idea. 99.9% of FT are scams and memes. However, they dont seem to be going away any time soon, just like casinos dont seem to be going away any time soon.
Creating a good FT protocol for Bitcoin may bring considerable transaction fee income, developer attention, and users to Bitcoin. Additionally, if the protocol has a smaller on-chain footprint and incentivizes responsible UTXO management, it may reduce harm compared to existing protocols. For example, the currently popular BRC-20 has led to the generation of a large amount of junk UTXO.
If we compare existing FT protocols, we will find that they have several important differences:
Complexity: How complex is the agreement? Is it easy to implement? Is it easy to adopt?
User experience: Are there implementation details that negatively impact user experience? In particular, protocols that rely on off-chain data have a lighter on-chain footprint but introduce significant complexity and require users to either run their own servers or discover and interact with existing servers.
State Model: UTXO-based protocols fit more naturally into Bitcoin and promote UTXO set minimization by avoiding the creation of “junk” UTXOs.
Native tokens: Protocols with native tokens required for protocol operation are cumbersome, withdrawable, and naturally less widely adopted.
Based on the above dimensions, the comparison results of the existing FT protocols in the Bitcoin ecosystem are as follows:
BRC-20: Not based on UTXO, and quite complex as it requires the use of ordinal theory in some operations;
RGB: Very complex, relies on off-chain data, has been developed for a long time and has not been adopted;
Counterparty: Has native tokens required for certain operations, rather than UTXO-based;
Omni Layer: Has native tokens required for certain operations, rather than UTXO-based;
Taproot Assets: A bit complicated and relies on off-chain data.
For Bitcoin, what would a simple, UTXO-based FT protocol with a good user experience look like? Next, I would like to introduce you to a very cool solution called Runes.
(1 Overview
Rune balances are held in UTXO; UTXO can contain any number of runes.
A transaction contains a protocol message if it contains an output whose script pubkey contains OP_RETURN followed by a data push with an ASCII uppercase R. The protocol message is all data pushed after the first one.
Runes input into transactions with invalid protocol messages will be destroyed, allowing future upgrades to change how runes are allocated or created, avoiding older clients from incorrectly allocating rune balances.
Integers are encoded as prefix varint, where the leading number in varint determines its length in bytes.
(2) Transfer
The first data push in a protocol message is decoded into a sequence of integers.
These integers are interpreted as a sequence of (ID, OUTPUT, AMOUNT) tuples. If the number of decoded integers is not a multiple of 3, the protocol message is invalid.
ID is the numeric ID of the run to be assigned
OUTPUT is the index of the output to be assigned
AMOUNT is the amount of runs to allocate
ID is encoded as delta. This allows the same rune to be assigned multiple times to avoid duplicating the full rune ID. For example, tuple: [( 100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]
Make the following assignments:
ID 100, output 1, 20 runes
ID 100, output 2, 10 runes
id 120, output 1, 5 runes
AMOUNT 0 is short for all remaining runes.
After all tuple allocations have been processed, any unassigned runes are assigned to the first non-OP_RETURN output (if any). Extra assignments will be ignored.
Runes can be burned by assigning them to the OP_RETURN output containing the protocol message.
(3)Issuance
If the protocol message has a second data push, it is an issue transaction. The second data push is decoded into two integers, SYMBOL and DECIMALS. If additional integers are left, the protocol message is invalid.
An issue transaction can create any number of issue runes using ID 0 in the assignment tuple, up to a maximum of 2^128 - 1 .
SYMBOL is a human-readable 26-bit base encoding symbol, similar to the symbol used in ordinal sat names. The only valid characters are A through Z .
DECIMALS is the number of digits after the decimal point that should be used when displaying issued runes.
If the SYMBOL is not already assigned, it is assigned to a published rune, and the published rune receives the next available numeric rune ID (starting from 1).
If SYMBOL is already allocated, or is BITCOIN, BTC or XBT, no new rune will be created. Issue transaction allocations using a rune ID of 0 will be ignored, but other allocations will still be processed.
(4) Attention
When displaying UTXO balances, the UTXOs native Bitcoin balance can be displayed with rune ID 0 and symbol BITCOIN, BTC or XBT.
In order to keep the protocol simple, (Runes) does not adopt a mechanism to avoid symbol squatting. In fact, an efficient and simple way to avoid symbol tying is to only allow allocation of symbols above a certain length, which decreases over time, and then eventually reaches zero and allows all symbols. This would avoid allocating short, ideal symbols early in the protocol and encourage latecomers to compete for ideal symbols - if such competition makes sense.
write at the end
Does this solution really work for the market? I have no idea.
Its just as simple as possible, doesnt rely on off-chain data, has no native tokens, and fits perfectly into Bitcoins native UTXO model. Such a scheme could attract users from other schemes with a worse on-chain footprint and turn the attention of developers and users to Bitcoin, encouraging them to adopt Bitcoin itself.
The world of FT, on the other hand, is a completely irredeemable abyss of deceit and greed, so it could be washed away.
