I know, I know, when this topic comes up, Bitcoin maximalists may argue, “Isn’t Bitcoin supposed to be digital gold? Why bother with tokens? Why USDT?” But with nearly all DeFi projects built on Ethereum, there’s an undeniable risk of a single point of failure. Plus, token issuance is compatible with the Bitcoin protocol and won’t interfere with its original functionality. If you’re not into these tokens, simply don’t use the clients, and you won't be really affected.
Issuing Tokens on Bitcoin: Why Not?
The idea of issuing tokens on Bitcoin—moving real-world asset transactions onto the Bitcoin blockchain—has been around since about 2010. Back then, people imagined trading assets like real estate, stocks, and fiat currencies in a decentralized manner. However, legal challenges made transferring these digital properties difficult. On-chain trading is never easy under regulations. Even if you successfully transferred a digital asset representing, for instance, your house to someone, governments may not recognize the transaction or change the ownership in real-world. You still have to deal with taxes and comply with regulations.
As a result, stablecoin projects like USDT have gained more attention. They are fungible tokens differentiated from Bitcoin. When emerge as tokens, their values are tied to the real-world assets they represent, no longer linked to the original cryptocurrency price. (If the value of the cryptocurrency rises significantly above the asset’s price, giving up the asset remains an option.) This is why tokens on Bitcoin usually use Satoshi as their unit.
Issuing tokens on Bitcoin involves two key challenges:
How to represent real-world assets with Bitcoin, ensuring the validity of asset states and transactions.
How to create complex contracts with Bitcoin’s limited Scripting language
Below, we provide an overview of current Bitcoin token issuance solutions and compare them in terms of several metrics, such as data availability, asset carrier, expressiveness, and scalability.
The First Token on Bitcoin: Colored Coins
The exact origin of the idea to design a token protocol on Bitcoin is unclear, but it likely came from discussions within the Bitcoin Forum or community. These discussions lead to the first token project on Bitcoin—Colored Coins. The Colored Coin was initiated by Yoni Assia in 2012. Together with Vitalik Buterin, Lior Hakim, Meni Rosenfeld, and Rotem Lev, he wrote the Colored Coins white paper, and in 2013, the project launched .
The main idea is marking a single Satoshi as a special coin by embedding asset-related information in it, known as "coloring". You can color a Satoshi with different tags, and tokens of the same color remain fungible. For instance, a bunch of Satoshis colored as USD are still fungible tokens. Early protocols used the nSequence field, marking one of the input UTXO’s nSequence with a flag. However, since nSequence only stores 4 bytes, later token designs switched to using the OP_RETURN field to store more metadata.
Colored Coins are now mentioned because it was the first token project on Bitcoin, even though the project didn’t develop well and saw little adoption. One challenge Colored Coins faced then was that Bitcoin’s capabilities couldn't fully support such an advanced idea, making it difficult to run efficiently and reliably. This may explain why Vitalik Buterin, after working on Colored Coins, finally launched Ethereum and became focused on smart contracts.
Because Colored Coins exist in the form of Satoshi, validating them is similar to validating UTXOs—it requires downloading the entire blockchain. This issue was later addressed by client-side validation.
Using OP_RETURN for Tokens: Counterparty & Omni Layer
Unlike Colored Coins, Counterparty and Omni Layer (the protocol behind USDT) do not directly color Satoshis. Instead, they create a UTXO with 0 as its value and store metadata in the UTXO’s OP_RETURN field. The OP_RETURN field holds 80 bytes, marking the UTXO within as unspendable. The actual token is the i-th output indicated by the OP_RETURN’s data, whose value typically set at 0.00000546 BTC, the smallest amount allowed. Since the token’s value is separate from BTC, there's no need to send more than the minimum amount.
Both Counterparty and Omni Layer store metadata on-chain and require on-chain verification.
Omni Layer was active on Ethereum for a long time until its recent return to Bitcoin with plans of issuing BTC-based stable coins. Counterparty, which has its own token XCP, has been recently focusing on NFTs, as seen from their Twitter updates.
For more on OP_RETURN, check out:
Side-Chains: Rootstock & Liquid Network
Rootstock (RSK) and Liquid Network are both side-chains that appeared around 2017. They use two-way peg to move Bitcoin to their respective EVM-compatible side-chains, where you can get involved in DeFi and dApps. They have issued their own tokens similar to WBTC (Rootstock’s RBTC, Liquid’s L-BTC), catering to users who want to build in Ethereum using BTC.
On Rootstock, issuing tokens follows the same process as that in Ethereum. I'd rather say that Rootstock is largely designed to be Ethereum compatible (for instance, you write contracts with Solidity), except for mining, the only connection it has with Bitcoin. Rootstock tokens are all issued based on RBTC, not directly on BTC.
Since this article mainly focuses on public chains, we won't get into Liquid, a federated side-chain.
For more on Rootstock, check out:
💡
Among these projects mentioned so far, some have disappeared (Colored Coins), while others are using Bitcoin's name but selling Ethereum's stuff. This is mainly because after capital flowed into Ethereum, DeFi and dApps gained market dominance. So for those DeFi projects which are not into Ethereum, it became harder to gain attraction. On Ethereum, tokens are issued and traded through smart contracts following standards like ERC-20. In the last two years, Bitcoin has also unlocked smart contract functionality (e.g., BitVM), and token standards like BRC-20 have emerged.
Smart Contracts on Bitcoin: RGB
RGB (Really Good for Bitcoin), launched in 2016, was initially designed as a competitor to colored coins. Facing similar challenges, it pivoted towards enabling smart contracts on Bitcoin. Although its main focus is on running smart contracts rather than issuing tokens, full contract functionality remains limited as of 2024, due to the constraints of its virtual machine, AluVM.
The idea behind RGB is to move as much data and smart contract code off-chain as possible, providing commitment for transaction validation and token insurance via Merkle roots. This set up leaves Bitcoin to only handle the validation and finality for transaction commitment, and ensure no double-spending.
A key innovation in RGB is the use of client-side validation and single-use seals, instead of marking UTXO to represent tokens. The two ideas, originally proposed by Peter Todd in 2013, were adapted by Giacomo Zucco and Maxim Orlovsky for the RGB protocol.
In client-side validation, transaction data and code related are kept off-chain, without being broadcasted to the network. Some data may be only exchanged privately between the two parties involved. Bitcoin is mainly used to maintain the sequence of state changes through timestamps.
A single-use seal is a digital one-time seal tied to a UTXO. Since each UTXO can be spent only once, single-use seals write the off-chain state information into a UTXO. This way, if at some point this UTXO is spent, we know that the state has been updated. The updated state info will be written into a newly created UTXO. This off-chain state information can be the ownership of a USDT token, or the number of tokens in a certain contract.
For instance, if Alice wants to transfer a token to Bob, this token is not on Bitcoin since its information is maintained off-chain. But it is associated with a UTXO controlled by Alice. The token’s information is kept in the OP_RETURN field (value = 0) of the transaction that generated that UTXO. This way, only Alice can spend the token, and Bob can trace the on-chain history of this token (e.g., which UTXOs it was previously in; whether these UTXOs and the transactions are valid). When Alice initiates a transaction, by sending the token’s commitment information over to a UTXO controlled by Bob, Bob can ensure that he now owns the token.
RGB can also work on the Lightning Network, as its states are off-chain and only commitments have to be sent on-chain. After the Taproot upgrade, RGB can embed commitments into a Taproot transaction, making integrating commitment on Bitcoin more flexible.
For more on RGB, check out:
Taproot Assets: Only Tokens, No Smart Contracts
Taproot assets are developed by the Lightning Network Daemon (LND) team. Its approach is similar to RGB’s but focuses solely on tokens without supporting smart contracts (refer to the clarification on Taproot here).
For more on client-side validation, RGB, and Taproot Assets, check out:
Making Each Satoshi Unique: Ordinals & Inscriptions
In early 2023, Casey Rodarmor launched the Ordinals protocol, which allows each Satoshi to be given a unique serial number, making them "ordered." This idea dates back to the same era as Colored Coins, but only recently became feasible due to upgrades like SegWit and Taproot. By giving each Satoshi a unique identity, Ordinals allows for the creation of NFTs directly on the Bitcoin.
Inscriptions is such a case. The metadata of its NFTs is stored on-chain in the transaction witness data, rather than in the OP_RETURN field. This allows for up to 4MB of metadata storage. Unlike Ethereum NFTs which are partially stored off-chain, Inscription data is fully on-chain, including metadata and images.
For more on Ordinals, check out:
Binding UTXO Chains: RGB++ Isomorphic Binding
RGB++ was originally designed as an isomorphic binding protocol between BTC and CKB (the foundation of Nervos Network), but has evolved into a broader solution ever since, supporting any two UTXO chains to be isomorphically bound together.
RGB++ enhances RGB's client-side validation and single-use seals by addressing issues like data availability. As mentioned earlier, the biggest issue with the RGB is that the data is saved locally by the users themselves. Once they lose the data, there is no backup and impossible to retrieve. Moreover, since users only save the data related to their own tokens, it is difficult to verify other data.
One key feature of isomorphic binding is that token data is bound not only to Bitcoin’s OP_RETURN field, but the corresponding Bitcoin transaction information is also bounded to CKB’s transaction data (which is done in the Lock Script of CKB’s Cell with a special IB-lock-script). When determining the validity of the transactions on CKB, Lock Script will use the BTC light client data on CKB to check whether the corresponding UTXO has been spent, and whether the newly generated UTXO contains the current transaction information (which is partial without a signature).
Key features of RGB++:
Solves the data availability issue through two-way binding:
Compatible with Lightning Network and Fiber Network ( the Lightning Network Based on CKB)
Multiple assets supported
Capable to bind any UTXO chains
For more on RGB++, check out:
To better understand the strengths and limitations of each project, I made a comparison chart below. Key metrics to focus on:
Data availability: Isomorphic-chains and side-chains are roughly comparable, while off-chains are weaker. The order from strong to weak is: On-chain ≥ isomorphic chain ≥ side-chain > off-chain
Asset carrier: Tokens directly linked to BTC tokens are superior to indirect ones.
Fungibility: Refers to whether the native asset issued by the project itself is interchangeable, NOT suggesting that the project can't support NFT, which is achievable by adding additional protocols.
Expressiveness: Measures the capacity of handling smart contracts.
Written by ✍🏻 Yunwen Liu
Yunwen Liu is a cryptographer at Cryptape. She completed her Ph.D at COSIC, KU Leuven. She published 20+ research papers in venues including Eurocrypt and Journal of Cryptology. She has served on the program committees of Eurocrypt 2022 and ToSC 2022/2023.
By the same author:
