Source: Byte Yuan CKB
I know that when it comes to this issue, Bitcoin purists may think: Isn't it good for Bitcoin to be digital gold quietly? Why must there be tokens? Why must there be USDT? However, if you are particularly concerned about asset security, you have to think, what if Ethereum collapses? Who can take over DeFi? Moreover, the token scheme is compatible with the Bitcoin protocol and will not destroy the original function. If you don't like it, you can choose not to download the token client and it will not be greatly affected.
Issuing tokens on Bitcoin: Why not?
The idea of issuing tokens on Bitcoin to transfer real-world asset transactions to the chain appeared in the Bitcoin community around 2010. The initial discussion in the community envisioned moving real-world assets - such as real estate, stocks, fiat currencies, etc. - to Bitcoin for decentralized transactions. However, due to legal factors, it is not so easy to move assets such as real estate and stocks. Even if you pay your house’s digital asset token to another person, the government may not recognize it, or automatically replace the real-world property certificate, and you may need to pay various taxes. Moreover, it cannot be traded on the chain at will under supervision.
Therefore, a more attractive approach is to issue tokens pegged to legal currencies, that is, stablecoins. Stablecoins are different from NFTs. They are still fungible tokens, but they are distinguished from the original Bitcoin. When they appear as tokens, their value is determined by the price of the real-world assets they represent, and no longer has the original digital currency price (if the price of the digital currency rises too much higher than the asset price, it is not impossible to abandon the asset). This is why tokens on Bitcoin are usually in Satoshi.
Using digital currency as a token of an asset requires solving two main problems:
How to use Bitcoin to represent assets in the real world;
How to set up complex transaction rules and contracts in Bitcoin's very limited scripting language.
The following content focuses on the above two points, summarizes the current major Bitcoin asset issuance plans, and compares them from the aspects of data availability, asset carrier, expressiveness, and scalability.
The first token on Bitcoin: colored coins
The first person to design the token protocol on Bitcoin is no longer traceable, and the idea may have originated from discussions in Bitcoin forums or communities. The Colored Coin project was initiated by Yoni Assia in 2012. At that time, he wrote the Colored Coins whitepaper with Vitalik Buterin, Lior Hakim, Meni Rosenfeld, and Rotem Lev [1]. The project started running in 2013.
The working principle of colored coins is to mark a satoshi as a special coin and write the relevant information of the asset into this satoshi - this process is called coloring. You can dye a satoshi into different colors and put different tags on it, but coins of the same color cannot be distinguished from each other. For example, a bunch of satoshis dyed into US dollars are still homogeneous. Earlier protocols used the nSequence field, adding a tag to the nSequence of the first input UTXO of the transaction. However, the storage limit of nSequence is only 4 bytes, so later token designs have basically replaced it with the OP_RETURN field, which can store more metadata.
Colored coins are currently being mentioned mainly because it is the first token project on Bitcoin. Since the development of the project is not ideal and has not been widely used, the project itself has gradually been forgotten. The problem faced by colored coins at the time was that the function of Bitcoin could not support this relatively advanced idea. It was difficult for this idea to be implemented and run efficiently and stably. This may also be why Vitalik went the opposite side of Bitcoin after the colored coin project and was so obsessed with smart contracts.
Since colored coins exist in the form of satoshis, their verification is the same as verifying the validity of a UTXO, and both require downloading the entire chain. This problem will be solved later by client-side validation.
Using OP_RETURN to issue tokens: Counterparty & Omni Layer
Unlike colored coins, Counterparty[2] and Omni Layer[3] (the protocol behind USDT) do not directly color satoshis. Instead, they set a UTXO with a value of 0 in the transaction and store metadata in the OP_RETURN of this UTXO. OP_RETURN can store 80 bytes. The UTXO marked with OP_RETURN cannot be spent. The real token is the i-th output recorded in OP_RETURN. The value of this output is usually 0.00000546 BTC - the minimum value allowed by the system to be sent, and since the value of the token is not pegged to BTC, there is no need to issue more than 0.00000546 BTC.
Verification of these projects needs to be done on the chain, and metadata is stored on the chain.
Omni Layer has been a player on the Ethereum chain for a long time, and only recently returned to the Bitcoin ecosystem and is preparing to issue BTC-USDT. Counterparty has pledged a portion of Bitcoin and has its own token XCP. Judging from Twitter[4], it should be working on NFT recently.
For more information about OP_RETURN, please refer to:
An analysis of Bitcoin OP RETURN metadata[5]
Manually construct OP_RETURN to send USDT[6]
Anchoring Bitcoin with sidechain: Rootstock & Liquid Network
The two projects, Rootstock[7] and Liquid Network[8], appeared around 2017. Both are sidechain solutions - using a two-way peg to replace Bitcoin with a sidechain, and using various DeFi and dApps on the EVM-compatible sidechain. They have tokens similar to WBTC[9] (RSK has RBTC, Liquid has L-BTC), which are mainly aimed at people who want to use BTC to build on the Ethereum ecosystem.
The method of issuing tokens on Rootstock is the same as that on Ethereum, or it can be said that except for mining, the Rootstock sidechain is used together with the Bitcoin chain, and all other functions are designed to adapt to the Ethereum ecosystem, such as the smart contract code is also written in Solidity. Therefore, the tokens here are all issued on the basis of RBTC and are not directly related to BTC.
Since this article mainly focuses on public chains, and Liquid Network is a consortium chain, it will not be discussed in depth here.
For more information about RSK, please refer to:
Some of the projects mentioned above have disappeared (such as colored coins), and some are selling Ethereum ecosystem under the guise of Bitcoin. This is mainly because after Ethereum embraced capital, DeFi and dApps occupied an absolute market advantage, so it is difficult for DeFi projects that do not play with it to gain an advantage. Tokens on Ethereum are issued and traded through contracts, following standards such as ERC-20. In the past two years, the Bitcoin ecosystem has also begun to unlock contract functions, such as BitVM, and the token standard BRC-20 has also emerged.
Implementing smart contracts on Bitcoin: RGB
RGB (Really Good for Bitcoin)[13], born in 2016, was originally designed as a competitor to colored coins. But faced with similar challenges, it turned to enabling smart contracts on Bitcoin. Although it focuses on running smart contracts rather than issuing tokens, due to the limitations of their virtual machine AluVM, as of 2024, the complete contract function is still limited.
RGB's idea is to put all the data and smart contract code that can be obtained off-chain outside of Bitcoin, and use Merkle root to provide transaction verification and commitment to token issuance. The Bitcoin chain only verifies and finalizes transaction commitments to prove that no double spending has occurred.
RGB is worth mentioning for using both client-side validation and one-time seal technologies, so it does not mark UTXO to represent tokens. These two concepts were first proposed by Peter Todd in 2013[14], and Giacomo Zucco and Maxim Orlovsky designed the RGB protocol based on this.
Client-side validation allows the data and code used in transactions to be stored off-chain and not publicly broadcast. Some data may only be exchanged privately between the two parties of the transaction, and other people not related to the transaction may not know about it. The off-chain state is maintained with the help of Bitcoin, and the blockchain acts as a timestamp to prove the order of the state.
The one-time seal, which is also the most common form of client-side validation, is a digital version of the one-time seal. It uses the property that each UTXO can only be spent once to write the off-chain state information to a UTXO. In this way, if this UTXO is spent at a certain moment, we know that the state has been updated, and the updated state information is written to the newly generated UTXO. This off-chain state information can be the ownership of the USDT token or how many tokens are in a certain contract.
For example, Alice wants to transfer a USDT to Bob. This USDT does not exist on the Bitcoin chain, and its information is maintained off-chain, but it will be associated with a UTXO controlled by Alice. Its information is stored in the OP_RETURN field of the UTXO with a value of zero in the transaction that generated this UTXO. In this way, only Alice can spend this USDT, and Bob can track which UTXOs this USDT has been stored in in past transactions, whether these UTXOs are valid, and whether the transaction is legal through transactions on the chain. In this way, when Alice initiates a transaction to transfer the USDT commitment information to a UTXO controlled by Bob, Bob can be sure that he has obtained the USDT.
RGB can also run on the Lightning Network because its state is off-chain, and it only needs to put the commitment on the chain or on the Lightning Network. After the Taproot upgrade, RGB can embed the commitment into a Taproot transaction, which allows RGB to embed the commitment into the Bitcoin chain in a more flexible way.
For more information about RGB, refer to: RGB Blueprint[15]
Only supports tokens, not smart contracts: Taproot Asset
Taproot Asset is a project developed by the Lightning Network Daemon (LND)[16] team. Its principle is similar to RGB, but it does not support complex smart contracts, only tokens (see the explanation of the Taproot entry [17] here).
For more information about Client-Side Validation, RGB, and Taproot, see:
Client-side validation[18]
Off-Chain Transactions: The Evolution of Bitcoin Asset Protocols[19]
Counterparty vs RGB vs TARO[20]
Making Every Satoshi Unique: Ordinals & Inscriptions
Casey Rodarmor released the Ordinal Protocol[21] in early 2023. The project was originally inspired by the idea of how to number Satoshis so that each Satoshi has a unique serial number and can be sorted. This idea is from the same period as colored coins, but was only brought up again last year. And with the addition of SegWit and Taproot functions, its implementation has become less difficult. Ordinal makes each satoshi different from each other, which allows NFTs to be issued directly on the Bitcoin chain.
Inscriptions[22] is such an NFT project. The data of NFTs is stored in the witness data of the transaction, rather than the OP_RETURN field used by previous projects, so that metadata within 4MB can be stored. Unlike NFTs on Ethereum, Inscriptions are stored on the chain, including metadata and images.
For more information about Ordinals, refer to:
Ordinals: A common ground for Ethereum and Bitcoin maximalists?[23]
The Ultimate Guide to Bitcoin Ordinals and Inscriptions[24]
Bidirectional binding of any UTXO chain: RGB++ isomorphic binding
RGB++[25] was originally proposed as an isomorphic binding protocol between BTC and CKB (the basis of Nervos Network[26]). Now, it has a wide range of applications. It is not limited to CKB and BTC. In theory, any two UTXO chains can be bound together using this protocol. RGB++ takes RGB's Client-Side Validation and Single-Use-Seals ideas a step further. As mentioned above, the biggest problem with the RGB protocol is that the data is stored locally by the user. If the user accidentally loses the data, there is no backup and it cannot be recovered. Moreover, since the user only stores data related to his own tokens, it is difficult to verify other data. The solution of the isomorphic binding layer is not only to bind the token to the OP_RETURN field of the Bitcoin UTXO, but also to bind the corresponding Bitcoin transaction information to the transaction on the CKB chain (through the Lock Script of the CKB Cell[27], using a special IB-lock-script). When judging whether the transaction on the CKB chain is legal, the Lock Script will use the data of the BTC light client on the CKB to see whether the corresponding UTXO has been spent, and whether the newly generated UTXO after being spent is bound to the current token transaction information (as part of the information without signature).
RGB++ features worth noting:
Solve the data availability problem through two-way binding: CKB Cell commitment is bound to the OP_RETURN field of UTXO; UTXO information is bound to the Output Cell of CKB transaction.
Compatible with Lightning Network and Fiber Network (Lightning Network based on CKB)
Supports multiple assets
Can be bound to any UTXO chain
For more information about RGB++, refer to:
RGB++ Protocol Light Paper[28]
The Ultimate Guide to RGB, RGB++, and Client-Side Validation[29]
In order to more clearly understand the advantages and limitations of each project, we put the above projects into the table below for comparison. The indicators that need to be focused on are:
Data availability: isomorphic-chain and sidechain are almost the same, while the data availability of off-chain is weaker than other solutions. The ranking from strong to weak is: on-chain ≥ isomorphic-chain ≥ sidechain > off-chain;
Asset carrier: token solutions directly associated with BTC are better than those not directly associated;
Fungibility: This refers to whether the native tokens of the project are interchangeable, which does not mean that the project does not support the issuance of NFTs, which can be achieved by adding additional protocols;
Expressiveness: refers to the ability to handle complex smart contracts.
Some links mentioned in the article: [1]https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit?pli=1&tab=t.0#heading=h.pr8n14cpqri5
[2] https://www.counterparty.io/
[3] https://www.omnilayer.org/
[4] https://x.com/counterpartyxcp
[5] https://arxiv.org/pdf/1702.01024& nbsp;
[6] https://juejin.cn/post/6844903769327534088
[7] https://rootstock.io/
[8] https://liquid.net/
[9] https ://www.wbtc.network/
[10] https://eprint.iacr.org/2022/684.pdf
[11] https://wiki.moneyonchain.com/getting-started/what-do-i-need-to-know-first
[12 ] https://dev.rootstock.io/resources/faqs/
[13] https://rgb.tech/
[14] https://petertodd.org/2013/disentangling-crypto-coin-mining
[15] https:// rgb-org.github.io/
[16] https://docs.lightning.engineering/
[17] https://bitcoinops.org/en/topics/client-side-validation/
[18] https://bitcoinops.org/en/topics/client-side-validation/
[19] https://mirror.xyz/0x5CCF44ACd0D19a97ad5aF0da492AC0388469DfE9/h7XChxETK-cBfGdc0sTq_cCuWeo13-sp1j -g0ZYoYdc
[20] https://mandelduck.medium.com/counterparty-vs-rgb-vs-taro-8cd707d544f7
[21] https://docs.ordinals.com/
[22] https://ordinals.com/inscriptions
[23] https://blog.kraken.com/crypto-education/ordinals-a-common-ground-for-ethereum-and-bitcoin-maximalists
[24] https://www.nervos.org/knowledge-base/guide_to _inscriptions
[25] https://www.rgbppfans.com/
[26] https://www.nervos.org/
[27] https://docs.nervos.org/docs/tech-explanation/cell
[28] https://github.com/utxostack/RGBPlusPlus-design/blob/main/docs/light-paper-en.md
[29] https://www.nervos.org/knowledge-base/ultimate_guide_to_rgb_rgbpp_and_client_side_validation
Catherine
JinseFinance
Brian
Jasper
dailyhodl
cryptopotato
Bitcoinist