Author of this article: Mysterious Ape Research Institute Yunwen Liu
I understand that when this issue arises, Bitcoin purists might think: Isn't it better for Bitcoin to quietly be digital gold? Why must there be tokens? Why must there be USDT? However, if you care about asset security, you have to consider, what if Ethereum collapses? Who can catch DeFi? Moreover, the token schemes are compatible with the Bitcoin protocol and do not disrupt the original functionality; if you dislike it, you can choose not to download the token client and won't be significantly affected.
Issuing tokens on Bitcoin: Why not?
The idea of issuing tokens on Bitcoin to transfer real-world asset transactions to the chain emerged around 2010 in the Bitcoin community. The initial discussion was about transferring real-world assets—such as real estate, stocks, and fiat currencies—onto Bitcoin for decentralized trading. However, due to legal factors, moving real estate and stocks is not that simple. Even if you pay another person with a digital asset token of your house, the government may not recognize it, or it may not automatically change the real estate certificate, and various taxes may need to be paid. Moreover, trading on the chain cannot be done freely under regulation.
Therefore, a more attractive approach is to issue tokens pegged to fiat currencies, i.e., stablecoins. Unlike NFTs, stablecoins remain fungible tokens, merely distinguished from the original Bitcoin. When appearing as tokens, their value is determined by the price of the real-world assets they represent, no longer tied to the original cryptocurrency price (if the cryptocurrency price rises significantly above the asset price, it is not impossible to abandon the asset). This is why tokens on Bitcoin are usually denominated in satoshis.
To use digital currency as an asset token, two main issues need to be solved:
How to represent real-world assets with Bitcoin;
How to set complex transaction rules and contracts in Bitcoin's limited scripting language.
The following content focuses on the above two points, summarizing the major existing Bitcoin asset issuance schemes, and comparing them in terms of data availability, asset carrier, expressiveness, scalability, and other aspects.
The first token on Bitcoin: Colored coins
The earliest person to design a token protocol on Bitcoin is unknown; the idea may have originated from discussions in Bitcoin forums or communities. The colored coins project was initiated by Yoni Assia in 2012, during which he wrote the (Colored Coins whitepaper) together with Vitalik Buterin, Lior Hakim, Meni Rosenfeld, and Rotem Lev, and the project began running in 2013.
The working principle of colored coins is to mark a satoshi as a special coin, writing the relevant information of the asset into this satoshi—this process is called coloring. You can color a satoshi into different colors, tagging them with different markers, but coins of the same color cannot be distinguished from each other. For example, a bunch of satoshis colored as dollars is still fungible. Earlier protocols used the nSequence field to add a marker in the nSequence of the first input UTXO of the transaction. However, since the storage limit of nSequence is only 4 bytes, later token designs basically switched to the OP_RETURN field, which can store more metadata.
Colored coins are mainly mentioned because they were the first token project on Bitcoin. Due to the project's unsatisfactory development and lack of widespread adoption, it has gradually been forgotten. The problem faced by colored coins at that time was that Bitcoin's functionality could not support this advanced idea, and it was difficult to implement and operate efficiently and stably. This might also explain why Vitalik moved to the opposite side of Bitcoin after the colored coins project, being so obsessed with smart contracts.
Since colored coins exist in the form of satoshis, their validation requires downloading the entire chain, just like validating a UTXO's validity. This issue will later be addressed through client-side validation.
Using OP_RETURN to issue tokens: Counterparty & Omni Layer
Unlike colored coins, Counterparty and Omni Layer (the protocol behind USDT) do not directly color the satoshis but instead set a UTXO with a value of 0 in the transaction, storing metadata in the OP_RETURN of this UTXO. OP_RETURN can store 80 bytes, marking that the UTXO of OP_RETURN cannot be spent; the real token is the i-th output recorded in OP_RETURN. This output's value is usually 0.00000546 BTC—the minimum allowed value for the system, and since the token's value is not tied to BTC, there is no need to issue more than 0.00000546 BTC.
The validation of these projects must be conducted on-chain, and metadata is stored on-chain.
The Omni Layer has been a player on the Ethereum chain for a long time, only recently returning to the Bitcoin ecosystem to prepare for issuing BTC-USDT. Counterparty has pledged a portion of Bitcoin and has its own token XCP. It seems they are recently working on NFTs based on Twitter.
Learn more about OP_RETURN, reference:
An analysis of Bitcoin OP RETURN metadata
Manually construct OP_RETURN to send USDT
Anchoring Bitcoin with sidechains: Rootstock & Liquid Network
Rootstock and Liquid Network appeared around 2017 and are both sidechain solutions—using a two-way peg method to swap Bitcoin to the sidechain and utilize various DeFi and dApps on EVM-compatible sidechains. They have tokens similar to WBTC (RSK has RBTC, Liquid has L-BTC), mainly targeting those who want to build on the Ethereum ecosystem using BTC.
Issuing tokens on Rootstock is the same as issuing on Ethereum, or it can be said that Rootstock, as a sidechain, is designed to adapt to the Ethereum ecosystem except for mining together with the Bitcoin chain. For example, smart contract code is also written in Solidity. Therefore, the tokens here are issued based on RBTC and are not directly linked to BTC.
Since this article primarily focuses on public chains, and Liquid Network is a consortium chain, it will not be discussed in depth here.
Learn more about RSK, reference
RSK: A Bitcoin sidechain with stateful smart contracts (RSK paper)
RSK money
AQs
Implementing smart contracts on Bitcoin: RGB
Born in 2016, RGB (Really Good for Bitcoin) was initially designed as a competitor to colored coins. However, facing similar challenges, it turned to enabling smart contracts on Bitcoin. Although its primary focus is on running smart contracts rather than issuing tokens, the full contract functionality remains limited as of 2024 due to the constraints of its virtual machine, AluVM.
The RGB approach is to handle off-chain data and smart contract code outside of Bitcoin, using Merkle root to provide transaction verification and token issuance commitments, while the Bitcoin chain only verifies the transaction commitment and finality, proving that no double spending has occurred.
A noteworthy aspect of RGB is its simultaneous use of client-side validation and single-use seal technology, which does not mark tokens on UTXOs. These two concepts were first proposed by Peter Todd in 2013, 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 broadcasted; some data may only be exchanged privately between the two parties in the transaction, and others not related to the transaction may remain unaware. The off-chain state is maintained by Bitcoin, with the blockchain serving as a timestamp to prove the order of states.
A single-use seal is a digital version of a single-use seal commonly seen in client-side validation. It uses the property that each UTXO can only be spent once to write off-chain state information into a UTXO. Thus, if this UTXO is spent at a certain moment, we know the state has been updated, and the updated state information is written into a newly generated UTXO. This off-chain state information could represent the ownership of the USDT token or how many tokens are in a particular contract.
For example, if Alice wants to transfer a USDT to Bob, this USDT does not exist on the Bitcoin chain; its information is maintained off-chain, but it will be related to a UTXO controlled by Alice. Its information is stored in the OP_RETURN field of a UTXO with a value of zero generated by that transaction. This way, only Alice can spend this USDT, and Bob can trace through on-chain transactions where this USDT was saved in past transactions, whether these UTXOs are valid, and whether the transactions are legal. Thus, when Alice initiates a transaction, transferring the commitment information of this USDT to a UTXO controlled by Bob, he can confirm he has received this USDT.
RGB can also run on the Lightning Network because its state is off-chain, requiring only the commitment to be placed on-chain or on the Lightning Network. After the Taproot upgrade, RGB can embed commitments into a Taproot transaction, allowing RGB to flexibly integrate commitments into the Bitcoin chain.
Learn more about RGB, reference:
RGB Blueprint
Supports tokens only, does not support smart contracts: Taproot assets
Taproot asset is a project developed by the Lightning Network Daemon (LND) team. Its principle is similar to RGB, but it does not support complex smart contracts, only tokens (see here for the explanation of the Taproot entry).
Learn more about Client-side validation, RGB, and Taproot, reference
Client-side validation
Off-Chain Transactions: The Evolution of Bitcoin Asset Protocols
Counterparty vs RGB vs TARO
Make each satoshi unique: Ordinals & Inscriptions
Casey Rodarmor released the Ordinal protocol in early 2023. This project originated from the idea of how to number satoshis, giving each satoshi a unique serial number for sorting. This idea coincided with colored coins but was only revisited last year. With the addition of SegWit and Taproot functionalities, its implementation became less challenging. Ordinals make each satoshi distinct, allowing NFTs to be issued directly on the Bitcoin chain.
Inscriptions is one such NFT project. The data for NFTs is stored in the witness data of transactions rather than the OP_RETURN field used by previous projects, allowing for metadata of up to 4MB to be saved. Unlike NFTs on Ethereum, Inscriptions are stored on-chain, including metadata and images.
Learn more about ordinals, reference:
Ordinals: A common ground for Ethereum and Bitcoin maximalists?
The Ultimate Guide to Bitcoin Ordinals and Inscriptions
Bidirectional binding of any UTXO chain: RGB++ Isomorphic Binding
RGB++ initially appeared as an isomorphic binding protocol between BTC and CKB (the foundation of Nervos Network), but now its applicability is broad, not limited to CKB and BTC; theoretically, any two UTXO chains can be bound together using this protocol.
RGB++ further develops the concepts of Client-Side Validation and Single-Use-Seals. As mentioned earlier, the main issue with the RGB protocol is that data is stored locally by users. If users accidentally lose the data, there are no backups and it cannot be recovered. Moreover, since users only save data related to their tokens, it becomes difficult to validate other data. The isomorphic binding layer solution binds not only the tokens to the OP_RETURN field of Bitcoin UTXO but also binds the corresponding Bitcoin transaction information to the transactions on the CKB chain (achieved by using a special IB-lock-script in the Lock Script of CKB Cell). When determining the validity of transactions on the CKB chain, the Lock Script uses data from the BTC light client on CKB to check whether the corresponding UTXO has been spent and whether the newly generated UTXO is bound to the token transaction information of the current transaction (as a part of the information without signature).
Notable features of RGB++:
Solving data availability issues through bidirectional binding:
CKB Cell promises binding in the OP_RETURN field of UTXO
UTXO information bound to the output Cell of CKB transactions
Compatible with Lightning Network and Fiber Network (Lightning Network based on CKB)
Supports multiple assets
Can be bound to any UTXO chain
Learn more about RGB++, reference:
RGB++ Protocol Light Paper
The Ultimate Guide to RGB, RGB++, and Client-Side Validation
To better understand the advantages and limitations of various projects, we will compare the above projects in the table below. Key metrics to focus on include:
Data availability: Isomorphic chains and sidechains are not much different, while off-chain data availability is weaker than other solutions. The ranking from strong to weak is: On-chain ≥ Isomorphic chains ≥ Sidechains > Off-chain;
Asset carrier: Token schemes directly associated with BTC are superior to those not directly associated;
Fungibility: This refers to whether the project's native tokens can be exchanged for one another, and does not imply that the project does not support issuing NFTs, which can be achieved through additional protocols;
Expressiveness: Refers to the ability to handle complex smart contracts.
