Author: Secret Ape Research Institute Yunwen Liu

I know that when this topic is brought up, 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 are particularly concerned about asset safety, you have to consider, what if Ethereum fails? Who can catch DeFi? Moreover, token schemes are compatible with the Bitcoin protocol and do not disrupt its original functionality; if you don't like 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 blockchain emerged around 2010 within the Bitcoin community. The initial discussions envisioned transferring real-world assets—such as: real estate, stocks, fiat currency—onto Bitcoin for decentralized trading. However, due to legal factors, transferring assets like real estate and stocks is not so straightforward. Even if you pay someone with a digital asset token for your house, the government may not recognize it, or the real-world property title may not be automatically updated, and various taxes may need to be paid. Moreover, under regulation, on-chain trading cannot be conducted freely.

Therefore, a more appealing approach is to issue tokens pegged to stable currencies, i.e., stablecoins. Unlike NFTs, stablecoins are still fungible tokens, just differentiated from the original Bitcoin. When issued as tokens, their value is determined by the price of the real-world assets they represent, rather than the original cryptocurrency price (if the cryptocurrency price rises significantly higher than the asset price, abandoning the asset isn't impossible). This is why tokens on Bitcoin are typically denominated in satoshis.

Issuing digital currency as an asset token requires solving two main problems:

  1. How to represent real-world assets using Bitcoin;

  2. How to set complex transaction rules and contracts in Bitcoin's very limited scripting language.

The following content focuses on the above two points, summarizing the current major 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 token protocols on Bitcoin is unknown, and the idea may have originated from discussions in Bitcoin forums or communities. The Colored Coins 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 operation in 2013.

The mechanism of colored coins is to mark a satoshi as a special coin, writing asset-related information into that satoshi—this process is called coloring. You can color a satoshi into different colors, marking it with different tags; however, coins of the same color cannot be distinguished from one another, for example, a pile of satoshis colored as dollars remain fungible. Earlier protocols utilized the nSequence field, adding a tag to the nSequence of the first input UTXO in a transaction. However, the nSequence storage limit is only 4 bytes, so later token designs generally switched to using the OP_RETURN field, which can store more metadata.

Colored Coins are primarily mentioned because they were the first token project on Bitcoin. As the project's development has not been ideal and it has not gained widespread use, it has gradually been forgotten. The problem faced by Colored Coins at the time was that Bitcoin's functionality could not support such an advanced idea, making it difficult to implement and run efficiently and stably. This may also explain why Vitalik turned to the opposite of Bitcoin after the Colored Coins project, being so persistent about smart contracts.

Since colored coins exist in the form of satoshis, their verification is similar to verifying the validity of a UTXO, requiring the entire chain to be downloaded. This problem will later be solved 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 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, indicating that UTXO marked with OP_RETURN cannot be spent, and the actual token is the i-th output recorded in OP_RETURN. The value of this output is typically 0.00000546 BTC—the minimum allowed to send—and since the value of the token is not tied to BTC, there is no need to issue more than 0.00000546 BTC.

Verification 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 but has only recently returned to the Bitcoin ecosystem, preparing to issue BTC-USDT. Counterparty has staked a portion of Bitcoin and has its own token, XCP. From Twitter, they seem to be working on NFTs recently.

Learn more about OP_RETURN, reference:

  • An analysis of Bitcoin OP RETURN metadata

  • Manually constructing OP_RETURN to send USDT

Anchoring Bitcoin with sidechains: Rootstock & Liquid Network

Rootstock and Liquid Network emerged around 2017, both as 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 similar tokens 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, functions similarly to adapt to the Ethereum ecosystem, with smart contract code written in Solidity. Therefore, the tokens here are issued on the basis of RBTC and are not directly linked to BTC.

Since this article primarily focuses on public chains and the 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

Launched in 2016, RGB (Really Good for Bitcoin) was initially designed as a competitor to colored coins. However, facing similar challenges, it shifted to 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, as of 2024, full contract functionality remains limited.

The RGB concept is to keep off-chain data and smart contract code outside of Bitcoin, using Merkle root to provide commitment for transaction verification and token issuance, with the Bitcoin chain only verifying the commitment of transactions and finality to prove that double spending has not occurred.

Notably, RGB uses both client-side validation and single-use seal technology, meaning it does not mark tokens on the UTXO. 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, not publicly broadcasted; some data may only be privately exchanged between the two parties involved in the transaction, while other unrelated parties may be completely unaware. The off-chain state is maintained by Bitcoin, with the blockchain functioning as a timestamp, proving the order of states.

A single-use seal—also the most common representation 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 at some point this UTXO is spent, 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 USDT tokens or the amount of tokens 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 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 trace through the on-chain transaction to see where this USDT was saved 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 received this USDT.

RGB can also operate on the Lightning Network, as 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 incorporate commitments into the Bitcoin chain in a more flexible manner.

Learn more about RGB, reference:

  • RGB Blueprint

Only supports tokens, does not support smart contracts: Taproot asset

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 here).

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 so that each satoshi has a unique serial number and can be sorted. This idea emerged around the same time as colored coins but was only revisited last year. Moreover, with the introduction of SegWit and Taproot features, its implementation became less challenging. Ordinals make each 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 transactions, rather than in the OP_RETURN field used by previous projects, allowing for metadata up to 4MB in size to be stored. 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 basis of Nervos Network), but now its applicability is very broad, not limited to CKB and BTC; any two UTXO chains can theoretically be bound together using this protocol.

RGB++ advances the Client-Side Validation and Single-Use-Seals concepts. 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 is no backup or way to recover it. Additionally, since users only save data related to their own tokens, it can be difficult to verify other data. The isomorphic binding layer solution binds tokens not only to the OP_RETURN field of Bitcoin UTXO but also to the corresponding Bitcoin transaction information in CKB chain transactions (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 if the corresponding UTXO has been spent and whether the newly generated UTXO is bound to the token transaction information.

Noteworthy features of RGB++:

  • Solving data availability issues through bidirectional binding:

    • CKB Cell commits to being bound in the OP_RETURN field of UTXO

    • UTXO information is bound in 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 each project, we have compared the above projects in the table below. Key indicators 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 strongest to weakest is: On-chain ≥ Isomorphic Chain ≥ Sidechain > Off-chain;

  • Asset Carrier: Token schemes directly associated with BTC are superior to non-directly associated schemes;

  • Fungibility: This refers to whether the project's native tokens can be exchanged for one another, not that the project does not support issuing NFTs, which can be implemented by adding additional protocols;

  • Expressiveness: Refers to the ability to handle complex smart contracts.