Source: Nervos CKB
I know, when it comes to this issue, BTC purists may think: Isn’t it better for BTC to just be a digital gold? Why must there be Tokens? Why does it have to be USDT? However, if you are particularly concerned about asset security, you have to think, what if Ethereum goes down? Who can catch DeFi? Moreover, Token solutions are compatible with BTC protocols and will not destroy the original functions. If you don’t like it, you don’t have to download the Token client, and it won’t have a big impact on you.
IssuanceToken on Bitcoin: Why not?
On BTC, issuanceToken is used to transfer real-world asset transactions to on-chain. This idea first appeared in the BTC community around 2010. The initial discussion in the community envisioned the transfer of real-world assets such as real estate, stocks, Fiat Currency, etc., to on-chain for Decentralization trading. However, due to legal factors, the transfer of assets such as real estate and stocks is not so easy. Even if you pay the digital assetToken of your house to another person, the government may not recognize it, or automatically change the real-world property certificate, and may also require various taxes. Moreover, under regulation, on-chain transactions are not allowed at will.
Therefore, a more appealing approach is Token issuance pegged to Fiat Currency, namely Stable Coin. Unlike Non-fungible Tokens, Stable Coins are still fungible Tokens, but distinguished from the original BTC. When they appear as Tokens, their value is determined by the price of the real-world assets they represent, rather than the original Digital Money price (if the price of Digital Money rises much higher than the asset price, it is also possible to abandon the asset). This is why Tokens on BTC are usually denominated in Satoshis (Satoshi).
To tokenize Digital Money as an asset, two main problems need to be addressed:
- How to represent real-world assets with BTC;
- How to set up complex trading rules and contracts in the very limited BTC scripting language.
The following content focuses on the above two points, summarizes the existing BTC asset issuance schemes, and compares them from several aspects such as data availability, asset carrier, expressiveness, and scalability.
The first Token on BTC: Colored Coins
The original person who designed the Token protocol on BTC is unknown. The idea may have originated from discussions on BTC forums or communities. The Colored Coin project was initiated by Yoni Assia in 2012. At that time, he co-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, which is called coloring. You can color a Satoshi in different colors and add different tags, but the coins of the same color still cannot be distinguished. For example, a pile of Satoshis colored as dollars is still homogeneous. The earlier protocols used the nSequence field and added a tag in the nSequence of the first input UTXO of the transaction. However, the storage limit of nSequence is only 4 bytes, so most of the later Token designs switched to the OP_RETURN field, which can store more metadata.
The reason why Colored Coin was mentioned mainly because it was the first Token project on BTC. Due to the development of the project not being ideal and not being widely used, the project itself has gradually been forgotten. The problem faced by Colored Coin at that time was that the functionality of BTC could not support this advanced idea. It is difficult for this idea to be implemented and operate efficiently and stably. This may also be why Vitalik turned to the opposite of BTC after the Colored Coin project and became so persistent in Smart Contracts.
Since Colored Coin exists in the form of Satoshis, its validation is similar to validating the validity of a UTXO, and requires 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][3]And Omni LayerThe protocol behind USDT does not directly color the currency in the blockchain, but sets a UTXO with a value of 0 in the transaction, and stores the metadata in the OP_RETURN of this UTXO. OP_RETURN can store 80 bytes, marking that the UTXO with OP_RETURN cannot be spent, and the real token is recorded in the i-th output of 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 tied to BTC, there is no need to send more than 0.00000546 BTC worth of tokens.
The verification of these projects needs to be done on-chain, and the metadata is stored on-chain.
For a long time, Omni Layer has been a player on the ETH blockchain, until recently returning to the BTC ecosystem, preparing to issuance BTC-USDT. Counterparty stake some BTC and have their own Token XCP. From Twitter[4]Recently, it seems that NFT is being worked on.
For further information about OP_RETURN, please refer to:
- An analysis of Bitcoin OP RETURN metadata[5]
- Manually construct OP_RETURN to send USDT[6]
Anchoring BTC with Sidechains: Rootstock & Liquid Network
Rootstock[7][8]And Liquid Network[9]These two projects appeared around 2017 and are both sidechain solutions - they use a two-way peg to swap Bitcoin to a sidechain and use various DeFi and dApps on an EVM-compatible sidechain. They are similar to WBTC.The token (RSK has RBTC, Liquid has L-BTC) is mainly aimed at people who want to build on the Ethereum ecosystem using BTC.
The method of issuanceToken on Rootstock is the same as that on ETH network, or it can be said that apart from Mining, Rootstock sidechain is designed to adapt to the ETH network ecosystem. For example, Smart Contract code is also written in Solidity. Therefore, the Tokens here are issued based on RBTC and are not directly related to BTC.
Since this article mainly follows the public chain, and the Liquid Network is a consortium chain, we will not delve into it here.
To learn more about RSK, please refer to:
- RSK: A Bitcoin sidechain with stateful smart-contracts (RSK paper)[10]
- RSK money[11]
- FAQs[12]
Some of the projects mentioned earlier have disappeared (such as Dyed Coins), and some are selling the ETH ecosystem under the guise of BTC. This is mainly because after embracing capital, Ethereum has taken absolute market advantage in Decentralized Finance and dApps. Therefore, it is difficult for Decentralized Finance 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. The BTC ecosystem has also started unlocking contract functions in the past two years, such as BitVM, and there is also a token standard called BRC-20.
Implementing Smart Contract on Bitcoin: RGB
Born in 2016, RGB (Really Good for Bitcoin)[13]Originally designed as a competitor to colored coins. However, facing similar challenges, it shifted towards enabling smart contracts on Bitcoin. Although its primary focus is on running smart contracts rather than issuing tokens, due to the limitations of their virtual machine AluVM, as of 2024, the full contract functionality is still limited.
The idea of RGB is to put the data and smart contract code that can be obtained off-chain outside of BTC, and provide transaction verification and token issuance commitments through Merkle root. The BTC chain only verifies transaction commitments and ensures finality, proving that double spending has not occurred.
One noteworthy aspect of RGB is the use of both client-side validation and one-time sealed strip technology, so it does not mark tokens on UTXO. These two concepts were first introduced by Peter Todd in 2013.[14]The proposed RGB protocol was designed by Giacomo Zucco and Maxim Orlovsky based on this.
Client-side validation allows the data and code used for transactions to be kept off-chain, not publicly broadcast, and some data may only be exchanged privately between the parties to the transaction, with others unrelated to the transaction being completely unaware. The off-chain state is maintained with BTC, and the blockchain acts as a Timestamp, proving the chronological order of states.
While a single-use seal, which is also the most common appearance of client-side verification, is a digital version of a one-time seal. It writes off-chain state information to a UTXO by leveraging the property that each UTXO can only be spent once. This way, if this UTXO is spent at some point, 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 USDT Token or the number of Tokens in a certain contract.
For example, Alice wants to transfer a USDT to Bob, which does not exist on-chain but is maintained off-chain. However, it is associated with a UTXO controlled by Alice. Its information is stored in the OP_RETURN field of the zero-valued UTXO 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 past transactions through on-chain transactions, whether these UTXOs are valid, and whether the transactions are legal. Therefore, when Alice initiates a transaction to transfer the commitment information of this USDT to a UTXO controlled by Bob, Bob can confirm that he has obtained this USDT.
RGB can also operate on the Lighting Network, as its state is off-chain, and only needs to put the commitments on-chain or on the Lighting Network. After the Taproot upgrade, RGB can embed commitments into a Taproot transaction, which allows RGB to embed commitments into Bitcoin on-chain in a more flexible way.
For further understanding of RGB, please refer to: RGB Blueprint[15]
Only support Token, not Smart Contracts: Taproot asset
Taproot Asset is Lightning Network Daemon (LND)[16][17]The project developed by the team. Its principle is similar to RGB, but it does not support complex smart contracts, only supports tokens (refer to the Taproot entry herethe explanation）。
For further understanding of Client-Side Validation, RGB, and Taproot, refer to:
- Client-side validation[18]
- Off-Chain Transactions: The Evolution of Bitcoin Asset Protocols[19]
- Counterparty vs RGB vs TARO[20]
Make every Satoshi unique: Ordinals & Inions
Casey Rodarmor released Ordinal Protocol in early 2023[21]The project initially came from such an idea: how to give a number to each satoshi, so that each satoshi has a unique serial number and can be sorted. This idea was concurrent with colored coins, but was only reintroduced last year. Moreover, with the addition of SegWit and Taproot functions, its implementation became less difficult. Ordinal makes each satoshi different from each other, which allows NFTs to be directly issued on the Bitcoin chain.
Inions[22] One such NFT project is one. The data of the NFT is stored in the witness data of the transaction, instead of the OP_RETURN field used by the previous project, which allows for metadata up to 4MB in size. Unlike NFTs on Ethereum, Inion is on-chain storage, including metadata and images.
For further understanding of Ordinals, please refer to:
- Ordinals: A common ground for Ethereum and Bitcoin maximalists?[23]
- The Ultimate Guide to Bitcoin Ordinals and Inions[24]
Bind any UTXO chain bidirectionally: RGB++ Isomorphically Bound
RGB++[25][26]Initially as BTC and CKB (Nervos NetworkThe isomorphic binding protocol (isomorphic binding protocol) between UTXO-based chains first appeared in the context of CKB and BTC, but now it has a wide range of applications and is not limited to just CKB and BTC. In theory, this protocol can be used to bind any two UTXO chains together.
RGB++ further extends the ideas of Client-Side Validation and Single-Use-Seals in the RGB protocol. As mentioned earlier, the biggest issue with the RGB protocol is that data is stored locally by the users themselves. If users accidentally lose their data, there are no backups and no way to retrieve it. Moreover, it is difficult to verify other data because users only store data related to their own tokens. The solution proposed by the homomorphic binding layer is to not only bind the tokens to the OP_RETURN field of BTC UTXO, but also bind the corresponding BTC transaction information to the on-chain transactions of CKB (by using CKB Cell…[27]In the Lock, a special IB-lock- is used to achieve it). When judging whether the CKB on-chain transaction is legal, the Lock will use the data of the BTC light client on CKB to see if the corresponding UTXO has been spent, and whether the new UTXO generated after being spent is bound to the current Token transaction information (as part of the information without signature).
RGB++ Worth following features:
- Solve the data availability problem through bidirectional binding: CKB Cell commits to bind to the OP_RETURN field of UTXO; UTXO information is bound to the Output Cell of CKB transaction.
- Compatible with Lighting Network and Fiber Network (Lighting Network based on CKB)
- Support for multiple assets
- Can be bound with any UTXO chain
For further understanding of RGB++, refer to: 01928374656574839201
- RGB++ Protocol Light Paper[28]
- The Ultimate Guide to RGB, RGB++, and Client-Side Validation[29]
In order to have a clearer understanding of the advantages and limitations of each project, we will compare the above projects in the following table. The key indicators that need to be followed 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 of this item from strong to weak is: on-chain > isomorphic-chain > sidechain > off-chain;
- Asset Carrier: Token schemes directly associated with BTC are superior to schemes that are not directly associated;
- Homogeneity (Fungibility): Here, it refers to whether the native Token of the project can be interchanged, rather than indicating that the project does not support the issuance of Non-fungible Tokens. The latter can be achieved by adding additional protocols.
- Expressiveness: refers to the ability to handle complex smart contracts.
Some links mentioned in the text:[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
knowledge-base/ultimate_guide_to_rgb_rgbpp_and_client_side_validation[29]
