Token protocols war on top of Bitcoin

Bitcoin, often recognized as the “king” of cryptocurrencies, boasts the highest market value and operates under simple yet robust rules. Its decentralized nature and resistance to censorship have earned it the moniker “digital gold.” However, Bitcoin’s strengths — its immutable rules and resistance to control — have made it less appealing for mainstream adoption as a payment method… until now!

Innovative minds have developed token protocols that operate on the Bitcoin network to address this challenge. Building assets on top of Bitcoin leverages its unparalleled security and decentralization. This provides a strong foundation for new tokens, inheriting Bitcoin’s security. Additionally, these tokens can tap into the vast Bitcoin ecosystem and liquidity, potentially reaching a wider audience and benefiting from its established infrastructure.

In this article, we compare and analyze several fungible token protocols built on Bitcoin, including BRC-20, Runes, Taproot Assets, and LRC-20. We explore their distinct features, advantages, and potential use cases to illuminate this evolving landscape of Bitcoin-based assets.

BRC-20

The BRC-20 protocol was proposed as a fun experimental standard to see if the ordinal theory can facilitate fungibility on Bitcoin. It has very limited functionality (all functions are just JSON metadata) to be executed:

• deploy function — declares the token symbol and its rules, such as supply, whether anyone can mint it, tokens limit per mint call, etc.
• mint function — mints a certain amount of the mentioned tokens to the issuer’s address. This function can be used by anyone if it was stated during the deployment, so either only the issuer can mint, or anyone can mint
• transfer function — transfers a certain amount of tokens to another address

BRC-20 information about tokens is public, because of an OP_RETURN-based approach. It’s not impossible to say that publicity/privacy is bad or good, but we can say that implementing both approaches is good (so that the user can choose what suits them), and that’s not the case here. While anyone can see and recognize TXs with BRC-20 data, it still requires an additional module to parse BRC-20 metadata. BRC-20 tokens increase the demand for Bitcoin transactions, driving up fees due to heightened competition for limited block space. Additionally, the larger size and complexity of BRC-20 transactions consume more blockchain resources, further contributing to their higher cost compared to regular Bitcoin transactions. This congestion reduces the amount of transactions processed on the blockchain.

Runes

Runes is another protocol that uses ordinals theory and is partially OP_RETURN-based. The protocol supports the following operations:

• Etching — announces the rune (token), its name, symbol, terms (supply, pre-mine, cap), etc.
• Mint — mints a fixed amount of new units, subject to the terms of the mint.
• Transfer — transfers runes from the inputs to that transaction’s outputs.

Unlike BRC-20, runes are bound to UTXOs. Runes are always “anyone-can-mint”, but the issuer (who etches the runes) can pre-mine all supply during the etching. Also, it is possible to make tokens mintable only during a certain period, e.g., from block 841000 to 842000. Transactions with runes in the inputs will move them to outputs and can be configured, i.e., to which output, how much, and which runes will be moved, using the OP_RETURN op-code.

Taproot Assets

At first, taproot’s idea was to hide Bitcoin scripts inside the public key so the user could either spend it using the signature (or multi-signature) or by revealing the script and satisfying it. The validator nodes can then verify that the script was stored inside the public key and the user fulfilled its requirements. But there is another core idea — any data can be put in a taproot key (and the address bound with such a key), which is spent by regular signature. So, no additional data (at least in the Bitcoin blockchain) must be revealed.

Lightning Labs proposed the Taro protocol and its idea is to store metadata inside the Taproot key using the Merkle Trees, concretely — Sparse Merkle Tree. SMT is a key-value tree that has 2^n leaves (n = 256 in their case), and the position of the inserted data is determined by the key, which is the public key of the asset holder. The tree is also combined with Sum Trees, so every node stores an integer (the number of tokens in our case) and the sum of integers in child nodes. This approach allows efficient verification of the conservation rule (no coins are created from air).

So, in a nutshell, the protocol works as follows:

1. The issuer creates an empty tree and commits to its root using Taptweak (and making an on-chain TX). The Taproot key would look like Q = P + H(P||c) · G, where P is the issuer’s public key and c is SMT root.
2. When the issuer issues assets, it adds the recipient public key to the tree with a certain number of tokens, updating the root.
3. After committing to the new root (via on-chain TX), it can create a Merkle inclusion proof for the user.
4. When a user wants to spend these tokens, they contact the issuer and ask it to change the root by “transferring” the funds to another address. The issuer then again commits to the new root.

The protocol looks good, but an immediate problem with scalability appears — imagine an Issuer that has 1 billion users inside the tree. It is not hard to change this root for it, cause it’s always a one-taproot transaction on-chain, but it’s hard to process all off-chain requests, such as proof requests, transfers, new issuance, etc.

It’s also not very user-friendly because every time a user wants to spend the funds, the user needs to contact the issuer (of course, it can be a back-end service, but it looks as if the user does not own his funds). Conversely, it is done by “removing” funds from the user. Issuers should remember that certain funds are not spent but just locked, and if the user passes the verification, the user can return them.

Note. Some may wonder why we highlighted the absence of UTXO binding as a disadvantage. UTXO binding is interesting because it inherits the Bitcoin protocol double spending prevention and users’ behavior while working with UTXOs. Secondly, Lightning Network uses UTXOs as well, and a protocol bound to UTXOs is simpler to implement and follow the development cycle of LN and Bitcoin.

LRC-20

The LRC-20 protocol’s idea is to hide assets as pairs (Y, UV) inside the taproot key (Y is the token identifier and UV is the amount), making it invisible for regular Bitcoin nodes and users. The protocol assumes the existence of additional indexer nodes that can recognize LRC-20 transactions and notify users about them (together with proof of these transactions’ correctness). If the user doesn’t want to trust some existing node, then can run their own ones.

LTC-20 protocol works the following way:

1. The issuer announces the asset (provides asset info).
2. The issuer issues some tokens by tweaking the receiver’s key K and sends any amount of satoshis (dust amount) to the taproot address calculated from the key P = K + PXH · G, where PXH is a hash with tokens metadata (Y and UV).
3. The issuer sends this TX on-chain and provides proofs (Y, UV data, and user’s key K in open format) to YUV nodes so they can verify that the issuer indeed can issue these tokens and that everything is correct.
4. Users can then similarly spend these funds by asking for a counterparty’s public key and tweaking it with token metadata (the same way how issuer did that).

Issuers can manage tokens via freeze. This is done through the OP_RETURN op-code, which freezes or unfreezes certain UTXOs with LRC-20 tokens. Also, the protocol supports private payments by changing the amount in the taproot key to the Pedersen commitment with Bulletproofs+ range proof. Users can privately exchange tokens while proving that the token conservation rule is met. Another advantage is that users directly control their funds because they are linked to UTXOs, which can be spent only by them.

A disadvantage of the protocol is that the longer certain coins are “alive,” the bigger the chain of proofs that should be transferred becomes. However, this is only a problem for the users since nodes store the whole history anyway.

Conclusion

We can summarize all mentioned before in the following table:

Bitcoin, renowned for its robust security, has become a reliable foundation for tokenization (including RWAs). However, Bitcoin’s security comes at a cost. Transaction fees on the main blockchain can be high, particularly during periods of network congestion. This can make tokenization, which often involves multiple transactions, a pricey endeavor for some projects.

A promising solution lies in Bitcoin’s Lightning Network. Designed for fast, low-cost transactions, Lightning could become the ideal layer for peer-to-peer (P2P) token transfers. By keeping most transfers off the main blockchain, Lightning not only reduces costs but also improves scalability, ensuring the Bitcoin network isn’t overloaded.

We believe that the trade-off for tokenization on top of Bitcoins involves a hybrid approach. Key operations like token issuance and official announcements could be secured on the Bitcoin blockchain, while the bulk of trading and transfers occur via the Lightning Network. This would provide the best of both worlds: the security of the main chain for critical actions, and the speed and affordability of Lightning for everyday use.