Author of this article: Yunwen Liu 1, Secret Ape Research Institute
I know that when this issue is raised, Bitcoin purists may wonder: Isn't it better for Bitcoin to quietly serve as digital gold? Why must there be tokens? Why must there be USDT? However, if you are particularly concerned about asset security, you must consider: What if Ethereum collapses? Who will catch DeFi? Moreover, the token schemes are compatible with the Bitcoin protocol and do not undermine its original functionality; if you dislike them, you can choose not to download the token client without significant impact.
Issuing tokens on Bitcoin: Why not?
The idea of issuing tokens on Bitcoin to transfer real-world asset transactions onto the chain emerged in the Bitcoin community around 2010. The initial discussion in the community envisioned transferring real-world assets—such as real estate, stocks, and fiat currency—onto Bitcoin for decentralized trading. However, due to legal factors, it is not so easy to move assets like real estate and stocks. Even if you pay another person with a digital asset token for your house, the government may not recognize it, or may not automatically replace the real estate title, and various taxes may apply. Moreover, trading on-chain is not freely permitted under regulation.
Therefore, a more attractive approach is to issue tokens pegged to stable currency, i.e., stablecoins. Unlike NFTs, stablecoins are still fungible tokens, just distinguished from the original Bitcoin. When they appear 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 price of the cryptocurrency rises significantly above the asset price, it is not impossible to discard the asset). This is why tokens on Bitcoin are usually expressed in satoshis.
To use digital currency as an asset token, two main issues need to be resolved:
How to represent real-world assets with Bitcoin;
How to set complex transaction rules and contracts within Bitcoin's very limited scripting language.
The following content focuses on the above two points, summarizing the major Bitcoin asset issuance schemes currently existing and comparing them in aspects such as data availability, asset carrier, expressiveness, scalability, etc.
The first token on Bitcoin: Colored coins
The earliest designers of token protocols on Bitcoin are untraceable; the idea may have originated from discussions in Bitcoin forums or communities. The colored coin project was initiated by Yoni Assia in 2012, when he, along with Vitalik Buterin, Lior Hakim, Meni Rosenfeld, and Rotem Lev, wrote the Colored Coins whitepaper, and the project began operating in 2013.
The operation of colored coins involves marking a satoshi as a special coin, writing related asset information into this satoshi—this process is called coloring. You can color a satoshi in different colors, tagging it with different marks, but coins of the same color still cannot be distinguished. For example, a batch of satoshis colored as dollars remains fungible. Earlier protocols used the nSequence field, adding a tag in the nSequence of the first input UTXO of the transaction. However, since nSequence has a storage limit of only 4 bytes, later token designs generally switched to using the OP_RETURN field, which can store more metadata.
Colored coins are primarily mentioned as the first token project on Bitcoin. Due to the project's less than ideal development and lack of large-scale application, it has gradually been forgotten. The issue faced by colored coins at that time was that Bitcoin's functionality could not support this relatively advanced idea; it was challenging to implement and operate efficiently and stably. This may also explain why Vitalik moved towards the other side of Bitcoin after the colored coin project, becoming so obsessed with smart contracts.
As colored coins exist in satoshis, their verification is the same as verifying the validity of a UTXO, requiring the entire chain to be downloaded. This issue will be addressed later through client-side validation.
Sending tokens with OP_RETURN: Counterparty & Omni Layer
Unlike colored coins, Counterparty and Omni Layer (the protocol behind USDT) do not directly color satoshis but 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, indicating that the UTXO marked with OP_RETURN cannot be spent; the actual token is the i-th output recorded in OP_RETURN. This output usually has a value of 0.00000546 BTC, which is the minimum allowed to be sent, and since the value of the token is not tied to BTC, there is no need to issue more than 0.00000546 BTC worth.
The validation of these projects needs to be conducted on-chain, with metadata stored on-chain.
Omni Layer was a player on the Ethereum chain for a long time before recently returning to the Bitcoin ecosystem to prepare for issuing BTC-USDT. Counterparty has staked a portion of Bitcoin and has its own token XCP. From Twitter, it seems they are currently working on NFTs.
For further understanding of OP_RETURN, refer to:
An analysis of Bitcoin OP RETURN metadata
Manually constructing OP_RETURN to send USDT 1
Using sidechains to anchor Bitcoin: Rootstock & Liquid Network
The two projects, Rootstock and Liquid Network, emerged around 2017, both as sidechain solutions—using a two-way peg method to swap Bitcoin onto the sidechain and utilizing various DeFi and dApps on EVM-compatible sidechains. They have tokens similar to WBTC (RSK has RBTC, Liquid has L-BTC), primarily targeting those who want to build in the Ethereum ecosystem with BTC.
Issuing tokens on Rootstock is the same as on Ethereum, or one could say that Rootstock, this sidechain, is designed for compatibility with the Ethereum ecosystem except for mining, where it works 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 mainly focuses on public chains, and the Liquid Network is a consortium chain, it will not be discussed in depth here.
For further understanding of RSK, refer to
RSK: A Bitcoin sidechain with stateful smart contracts (RSK paper)
RSK money
FAQs
Some of the projects mentioned earlier have disappeared (like colored coins), while others sell Ethereum's ecosystem under the guise of Bitcoin. This is mainly because, after Ethereum embraced capital, DeFi and dApps have occupied absolute market advantage, making it difficult for DeFi projects not playing along to gain an edge. Tokens on Ethereum are issued and traded through contracts, following standards like ERC-20. The Bitcoin ecosystem has also begun unlocking contract functionalities in the past two years, such as BitVM, and a token standard BRC-20 has emerged.
Implementing smart contracts on Bitcoin: RGB
RGB (Really Good for Bitcoin), born in 2016, was initially designed as a competitor to colored coins. But facing similar challenges, it shifted to enabling smart contracts on Bitcoin. Although it mainly focuses on running smart contracts rather than issuing tokens, due to the limitations of its virtual machine AluVM, complete contract functionality remains limited as of 2024.
The idea of RGB is to keep data accessible off-chain and smart contract code outside of Bitcoin, using Merkle root to provide transaction validation and token issuance commitments; the Bitcoin chain only verifies transaction commitments and finality, proving that double spending has not occurred.
It is worth mentioning that RGB simultaneously uses client-side validation and single-use seal technologies, thus it does not mark the UTXO to represent tokens. These two concepts were first proposed by Peter Todd in 2013, and Giacomo Zucco and Maxim Orlovsky designed the RGB protocol based on these ideas.
Client-side validation allows the data and code used in transactions to be stored off-chain, remaining private and not publicly broadcast; some data may only be exchanged privately between the two parties in the transaction, while others not related to the transaction may be completely unaware. The off-chain state is maintained through Bitcoin, with the blockchain serving as a timestamp to prove the order of states.
A single-use seal—also the most common form of client-side validation—is a digital version of a single-use seal. It leverages the property that each UTXO can only be spent once, writing off-chain state information into a UTXO. Thus, if this UTXO is spent at any moment, we know the state has been updated, and the updated state information is written into the newly generated UTXO. This off-chain state information can represent ownership of a USDT token or how many tokens are in a certain contract.
For example, if Alice wants to send a USDT to Bob, this USDT does not exist on the Bitcoin chain; its information is maintained off-chain, but it is linked to a UTXO controlled by Alice. Its information is stored in the transaction that generated this UTXO in the OP_RETURN field of a UTXO with a value of zero. Thus, only Alice can spend this USDT, and Bob can trace through on-chain transactions to see which UTXOs this USDT was stored in during past transactions, whether these UTXOs are valid, and whether the transaction is legitimate. Therefore, when Alice initiates a transaction to transfer the commitment information of this USDT to a UTXO controlled by Bob, Bob can confirm he has received this USDT.
RGB can also run on the Lightning Network because its state is off-chain; it only needs to place commitments on-chain or on the Lightning Network. After the Taproot upgrade, RGB can embed commitments into a Taproot transaction, allowing RGB to embed commitments into the Bitcoin chain in a more flexible manner.
For further understanding of RGB, refer to:
RGB Blueprint 1
Only supports tokens and 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).
For further understanding of Client-side validation, RGB, and Taproot, refer to
Client-side validation
Off-Chain Transactions: The Evolution of Bitcoin Asset Protocols
Counterparty vs RGB vs TARO
Making every satoshi unique: Ordinals & Inscriptions
Casey Rodarmor released the Ordinal protocol in early 2023. This project originally stemmed from the idea of how to number satoshis so that each satoshi has a unique serial number for sorting. This idea emerged around the same time as colored coins but was only reintroduced last year. Moreover, with the addition of SegWit and Taproot functionalities, its implementation became less difficult. Ordinals make every satoshi distinct, allowing NFTs to be issued directly on the Bitcoin chain.
Inscriptions is such an NFT project. The data for NFTs is stored in the witness data of the transaction, rather than in the OP_RETURN field used by previous projects, allowing metadata up to 4MB in size to be saved. Unlike NFTs on Ethereum, Inscriptions are stored on-chain, including metadata and images.
For further understanding of ordinals, refer to:
Ordinals: A common ground for Ethereum and Bitcoin maximalists?
The Ultimate Guide to Bitcoin Ordinals and Inscriptions
Two-way binding of any UTXO chain: RGB++ isomorphic binding
RGB++ initially appeared as an isomorphic binding protocol between BTC and CKB (the basis of Nervos Network), but now its applicability is broad, not limited to just CKB and BTC; in theory, any two UTXO chains can use this protocol to bind together.
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 the user. If a user accidentally loses this data, there is no backup or way to recover it. Also, since users only save data related to their own tokens, verifying other data becomes difficult. The isomorphic binding layer solution not only binds tokens to the OP_RETURN field of Bitcoin UTXOs but also binds the corresponding Bitcoin transaction information to the transactions on the CKB chain (achieved through a special IB-lock-script in the Lock Script of CKB Cells). When determining the legitimacy of a transaction on the CKB chain, the Lock Script will use data from the BTC light client on CKB to check if the corresponding UTXO has been spent and whether the newly generated UTXO is bound to the current token transaction information (as a non-signature portion).
Noteworthy features of RGB++:
Solving the data availability issue through two-way binding:
CKB Cell commitment bound in the OP_RETURN field of UTXO
UTXO information bound in the output Cell of CKB transactions
Compatible with the Lightning Network and Fiber Network (Lightning network based on CKB)
Supports multiple assets
Can bind to any UTXO chain
For further understanding of RGB++, refer to:
RGB++ Protocol Light Paper
The Ultimate Guide to RGB, RGB++, and Client-Side Validation
To better understand the advantages and limitations of each project, we will compare the above projects in the table below. Key indicators to focus on include:
Data Availability: Isomorphic chains and sidechains are similar, while off-chain data availability is weaker than other solutions. The ranking from strong to weak is: On-chain ≥ Isomorphic Chain ≥ Sidechain > 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 are interchangeable with each other; it does not imply that the project does not support issuing NFTs, which can be achieved by adding additional protocols;
Expressiveness: Refers to the ability to handle complex smart contracts.
