Asset Issuance on Bitcoin: Existing Projects and Their Guidelines

Article Author: Secret Ape Research Institute Yunwen Liu1

English Version: Issuing Assets on Bitcoin: A Simple Guide to Current Projects and Approaches2

I know that when it comes to this issue, Bitcoin purists might feel: isn't it better for Bitcoin to quietly serve as digital gold? Why do we need tokens? Why must there be USDT? However, if you are particularly concerned 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 it, you can choose not to download the token client and won't be significantly 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, transporting assets like real estate and stocks is not so easy. Even if you pay someone with a digital asset token of your house, the government may not recognize it, or automatically change the real-world property title, and you may also have to pay various taxes. Furthermore, trading on-chain cannot be done freely under regulation.

Therefore, a more attractive method is to issue tokens pegged to fiat currency, namely 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 designer of a token protocol on Bitcoin is unknown; 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 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 with different labels, but coins of the same color cannot be distinguished from one another; for example, a pile of satoshis colored as dollars remains fungible. The earlier protocols used the nSequence field, adding a tag 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 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 turned to the opposite of Bitcoin after the Colored Coins project, being so dedicated to smart contracts.

Since Colored Coins exist in the form of satoshis, their validation requires downloading the entire chain, just like verifying the validity 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; instead, they 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 actual token is the i-th output recorded in OPRETURN. The value of this output is usually 0.00000546 BTC—the minimum value 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 OPRETURN, you can refer to:_

Using Sidechains to Anchor Bitcoin: Rootstock & Liquid Network

Rootstock and Liquid Network emerged around 2017, both being sidechain solutions—using a two-way peg to swap Bitcoin onto 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), primarily targeting those who want to build on the Ethereum ecosystem using BTC.

Issuing tokens on Rootstock is done in the same way as 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:

RSK: A Bitcoin sidechain with stateful smart-contracts (RSK paper)
RSK money
FAQs

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 after Ethereum embraced capital, DeFi and dApps gained absolute market dominance, making it difficult for DeFi projects that do not engage with it to gain an advantage. 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

Born in 2016, RGB (Really Good for Bitcoin) 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, as of 2024, its full contract functionality remains limited due to the constraints of its virtual machine, AluVM.

The idea behind RGB is to keep off-chain data and smart contract code outside of Bitcoin, using Merkle roots to provide commitments for transaction verification and token issuance. The Bitcoin chain only verifies transaction commitments and finality, proving that no double spending has occurred.

Notably, RGB employs both client-side validation and single-use seals technology, 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 transaction parties, leaving others unrelated to the transaction 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 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 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. This way, only Alice can spend this USDT, and Bob can trace through on-chain transactions to see which UTXOs this USDT has been stored in, whether these UTXOs are valid, and whether the transaction is legitimate. Thus, 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 operate on the Lightning Network since its state is off-chain, only requiring commitments 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.

To learn more about RGB, refer to:

RGB Blueprint1

Token Support 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 tokens (refer to the explanation of the Taproot entry).

To learn more about Client-side validation, RGB, and Taproot, refer to:

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 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 NFT data is stored in the witness data of the transaction, 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 both metadata and images.

To learn more about ordinals, refer to:

Bidirectional Binding of Any UTXO Chain: RGB++ Isomorphic Binding

RGB++ initially emerged as an isomorphic binding protocol between BTC and CKB (Nervos Network foundation), but its applicability has broadened, 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 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. Moreover, since users only save data related to their tokens, it becomes challenging to verify other data. The isomorphic binding layer's solution is to not only bind tokens to the OP_RETURN field of Bitcoin UTXOs but also bind 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 the legality of a transaction 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 current token transaction information (as part of the information without signatures).

Notable features of RGB++ include:

Solving data availability issues through bidirectional 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 (a Lightning Network based on CKB)
Support for 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. The key metrics to focus on are:

Data availability: Isomorphic chains are nearly equivalent 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 solutions 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.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。