Asset Issuance on Bitcoin: Existing Projects and Their Solution Guidelines
The following content focuses on the above two points, summarizes the current major Bitcoin asset issuance schemes, and compares them in terms of data availability, asset carriers, expressiveness, scalability, and other aspects.Author: Secret Ape Research Institute Yunwen Liu 1
English version: Issuing Assets on Bitcoin: A Simple Guide to Current Projects and Approaches 2
I know that when it comes to this issue, Bitcoin purists might feel: isn't it good for Bitcoin to quietly be digital gold? Why do we need tokens? Why must there be USDT? However, if you particularly 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 undermine its original functionality; if you don't like them, you can choose not to download the token client and won't be greatly affected.
Why Issue Tokens on Bitcoin?
The idea of issuing tokens on Bitcoin to transfer real-world asset transactions onto the blockchain emerged around 2010 in the Bitcoin community. The initial discussions in the community envisioned moving real-world assets—such as real estate, stocks, and fiat currency—onto Bitcoin for decentralized trading. However, due to legal factors, moving assets like real estate and stocks is not that easy. Even if you pay the digital asset token of your house to another person, the government may not recognize it, or automatically change the real-world property certificate, and you may also need to pay various taxes. Furthermore, trading on-chain is not allowed under regulation.
Therefore, a more attractive approach is to issue tokens pegged to fiat currency, known as 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 cryptocurrency price rises too high compared to the asset price, it is not impossible to abandon the asset). This is why tokens on Bitcoin are usually denominated in satoshis.
Using cryptocurrency as a token for assets requires solving two main problems:
- How to represent real-world assets using Bitcoin;
- How to set complex transaction rules and contracts within Bitcoin's very limited scripting language.
The following content focuses on these two points, summarizing the major existing Bitcoin asset issuance schemes and comparing them in terms of data availability, asset carriers, 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 likely 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 way Colored Coins work is by marking a satoshi as a special coin, writing the relevant asset information into that satoshi—this process is called coloring. You can color a satoshi in different colors, tagging it differently; however, coins of the same color cannot be distinguished from each other. For example, a pile 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 mostly switched to the OP_RETURN field, which can store more metadata.
Colored Coins are mainly mentioned today because they were the first token project on Bitcoin. Due to the project's development not being ideal and lacking large-scale application, it has gradually been forgotten. The problem Colored Coins faced at the time was that Bitcoin's functionality could not support this relatively advanced idea, making it difficult for the concept to be realized and operate efficiently and stably. This may also explain why Vitalik moved towards the opposite of Bitcoin after the Colored Coins project, becoming so dedicated to smart contracts.
Since Colored Coins exist in the form of satoshis, their validation requires downloading the entire chain, just like validating the effectiveness of a UTXO. This issue will later be addressed through client-side validation.
Issuing 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 OPRETURN of this UTXO. OPRETURN can store 80 bytes, and the UTXO marked with OPRETURN cannot be spent; the real token is the i-th output recorded in OPRETURN. The value of this output is usually 0.00000546 BTC—the minimum amount allowed by the system—and since the value of the token is not tied to BTC, there is no need to issue more than 0.00000546 BTC.
The validation of these projects needs to be done on-chain, with metadata stored on-chain.
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 staked a portion of Bitcoin and has its own token, XCP. From Twitter, it seems they are currently working on NFTs.
To learn more about OP_RETURN, refer to:
Using Sidechains to Anchor Bitcoin: Rootstock & Liquid Network
Rootstock and Liquid Network emerged around 2017 as sidechain solutions—using a two-way peg to swap Bitcoin onto sidechains and utilize 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 on the Ethereum ecosystem using BTC.
Issuing tokens on Rootstock is done similarly to issuing on Ethereum, or it can be said that Rootstock, aside from mining, is designed to adapt to the Ethereum ecosystem, with smart contract code 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 Liquid Network is a consortium chain, it will not be discussed in depth here.
To learn more about RSK, refer to:
Some of the projects mentioned above have disappeared (like Colored Coins), while others sell Ethereum's ecosystem under the guise of Bitcoin. This is mainly because Ethereum, after embracing capital, has gained an absolute market advantage in DeFi and dApps, making it difficult for DeFi projects that do not engage with it 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 functionality 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. However, facing similar challenges, it shifted towards enabling smart contracts on Bitcoin. Although it primarily 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 behind RGB is to keep off-chain data and smart contract code outside of Bitcoin, using Merkle roots to provide transaction verification and token issuance commitments, with the Bitcoin chain only verifying transaction commitments and finality, proving that no double spending has occurred.
Notably, RGB employs both client-side validation and single-use seals, meaning it does not mark UTXOs 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 this foundation.
Client-side validation allows the data and code used in transactions to be stored off-chain, not publicly broadcasted; some data may only be exchanged privately between the parties involved in the transaction, while others unrelated 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—also the most common form of client-side validation—is a digital version of a one-time 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 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 can represent the ownership of USDT tokens or how many tokens are in a certain 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 is linked to a UTXO controlled by Alice. Its information is stored in the OP_RETURN field of the transaction that generated this UTXO, which has a value of zero. Thus, only Alice can spend this USDT, and Bob can track through on-chain transactions where this USDT has been stored in 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 that he has received this USDT.
RGB can also run on the Lightning Network because its state is off-chain, only needing 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.
To learn more about RGB, refer to:
Supporting Only Tokens Without 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 supporting tokens (refer to the explanation of Taproot entry).
To learn more about 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 originated from the idea of how to number satoshis, giving each satoshi a unique serial number for sorting. This idea emerged around the same time as Colored Coins but was only reintroduced last year. With the addition of SegWit and Taproot functionalities, its implementation became less difficult. Ordinals make each satoshi distinct, enabling NFTs to be issued directly on the Bitcoin chain.
Inscriptions is one such NFT project. The data of NFTs is stored in the witness data of transactions, rather than in the OP_RETURN field used by previous projects, allowing for metadata of up to 4MB in size. Unlike NFTs on Ethereum, Inscriptions are stored on-chain, including metadata and images.
To learn more about ordinals, refer to:
- Ordinals: A common ground for Ethereum and Bitcoin maximalists?
- The Ultimate Guide to Bitcoin Ordinals and Inscriptions
Bi-directionally Binding Any UTXO Chain: RGB++ Isomorphic Binding
RGB++ initially appeared as an isomorphic binding protocol between BTC and CKB (Nervos Network base), 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 RGB's Client-Side Validation and Single-Use-Seals. As mentioned earlier, the biggest problem with the RGB protocol is that data is stored locally by users. If a user accidentally loses the data, there is no backup and it cannot be recovered. Moreover, since users only save data related to their tokens, it becomes difficult to verify other data. 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 transactions on the CKB chain (achieved by using a special IB-lock-script in the Lock Script of CKB Cell). When determining whether a transaction on the CKB chain is valid, 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 current token transaction information (as part of the information without signatures).
Noteworthy features of RGB++ include:
- Solving data availability issues through bi-directional binding:
- CKB Cell promises bound to the OP_RETURN field of UTXO
- UTXO information bound to the output Cell of CKB transactions
- Compatibility with the Lightning Network and Fiber Network (Lightning Network based on CKB)
- Supports multiple assets
- Can bind with any UTXO chain
To learn more about RGB++, refer to:
To better understand the advantages and limitations of each project, we have compared the above projects in the table below. Key metrics to focus on include:
- Data availability: Isomorphic chains are similar to sidechains, 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 can be exchanged for each other and 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.
