Bitcoin Asset Issuance: A Guide to Existing Projects and Their Approaches
TechFlow Selected TechFlow Selected
Bitcoin Asset Issuance: A Guide to Existing Projects and Their Approaches
What if Ethereum fails? Who can pick up DeFi?
Navigating Web3 tides with focused insightsAuthor: Yunwen Liu 1, Cryptape Research Institute
I know that when this topic comes up, Bitcoin purists might think: Can't Bitcoin just quietly serve as digital gold? Why must there be tokens? Why do we need USDT at all? However, if you truly care about asset security, you have to consider: what if Ethereum fails? Who would then support DeFi? Moreover, token schemes are compatible with the Bitcoin protocol and don't disrupt its original functionality. If you don't like them, you can simply avoid downloading token clients and won't be significantly affected.
Issuing Tokens on Bitcoin: Why Not?
The idea of issuing tokens on Bitcoin to bring real-world asset trading on-chain emerged around 2010 within the Bitcoin community. Initial discussions envisioned moving real-world assets—such as real estate, stocks, and fiat currencies—onto Bitcoin for decentralized trading. However, legal constraints make transferring assets like property or equities difficult. Even if you digitally transfer ownership of your house via a token to someone else, governments may not recognize it or automatically update physical property deeds, and various taxes could still apply. Furthermore, regulatory oversight limits free on-chain trading.
Thus, a more appealing approach is issuing fiat-pegged tokens—stablecoins. Unlike NFTs, stablecoins remain fungible tokens, merely distinguished from native Bitcoin. When represented as tokens, their value is tied to the price of the underlying real-world asset, no longer following the volatile pricing of cryptocurrencies (if crypto prices rise far above the asset value, one could even abandon the peg). This is why tokens on Bitcoin are typically denominated in satoshis.
Using cryptocurrency as asset-backed tokens requires solving two key challenges:
-
How to represent real-world assets using Bitcoin;
-
How to implement complex transaction rules and contracts within Bitcoin’s highly limited scripting language.
The following sections address these two issues by summarizing major existing Bitcoin tokenization frameworks and comparing them across dimensions such as data availability, asset carrier, expressiveness, and scalability.
The First Token on Bitcoin: Colored Coins
The originator of the first token protocol on Bitcoin is unknown—it may have originated from early forum or community discussions. The Colored Coin project was initiated in 2012 by Yoni Assia, who co-authored the Colored Coins whitepaper with Vitalik Buterin, Lior Hakim, Meni Rosenfeld, and Rotem Lev. The project launched in 2013.
Colored Coins work by marking a single satoshi as a special coin, embedding asset-related information into it—a process known as "coloring." You can assign different colors or tags to satoshis, though coins of the same color remain indistinguishable and thus fungible—for example, a group of satoshis colored as USD remain interchangeable. Early protocols used the nSequence field, embedding a marker into the nSequence of the first input UTXO. However, since nSequence supports only up to 4 bytes, later designs shifted to OP_RETURN, which allows storing richer metadata.
Today, Colored Coins are mainly remembered as Bitcoin’s first token experiment. Due to limited development and lack of widespread adoption, the project gradually faded. At the time, Bitcoin lacked the functional capabilities needed to support this forward-looking concept, making reliable and efficient implementation extremely difficult. This limitation may partly explain why Vitalik moved away from Bitcoin after working on Colored Coins, becoming deeply committed to smart contract platforms instead.
Since Colored Coins exist as satoshis, verifying them is equivalent to validating a UTXO, requiring full blockchain synchronization. This issue would later be addressed through 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 zero-value UTXOs and store metadata within the OP_RETURN field of such UTXOs. OP_RETURN allows 80 bytes of data, and UTXOs marked with OP_RETURN cannot be spent. The actual token corresponds to the i-th output, typically valued at 0.00000546 BTC—the minimum allowable transaction amount. Since token value isn’t tied to BTC, sending more than this minimal amount offers no benefit.
Validation for these projects occurs on-chain, with metadata stored permanently on the blockchain.
Omni Layer operated largely within the Ethereum ecosystem for years but has recently returned to Bitcoin, preparing to launch BTC-USDT. Counterparty secured a portion of Bitcoin and issued its own token, XCP. According to Twitter, they appear to be focusing on NFTs lately.
To learn more about OP_RETURN:
Anchoring Bitcoin via Sidechains: Rootstock & Liquid Network
Rootstock and Liquid Network, both emerging around 2017, use sidechain architectures—employing two-way pegs to move Bitcoin onto sidechains where users can access DeFi applications and dApps on EVM-compatible chains. They issue Bitcoin-anchored tokens similar to WBTC (RSK uses RBTC, Liquid uses L-BTC), primarily targeting developers who want to build with BTC in an Ethereum-like environment.
Token issuance on Rootstock mirrors that on Ethereum. In fact, Rootstock functions almost identically to Ethereum aside from shared mining with Bitcoin. Smart contracts are written in Solidity, and tokens are issued atop RBTC rather than directly linked to BTC.
Given this article’s focus on public blockchains, and considering Liquid Network is a consortium chain, it will not be discussed in depth here.
To learn more about RSK:
Many of the aforementioned projects have either disappeared (like Colored Coins) or leverage Bitcoin branding while essentially offering Ethereum-based ecosystems. This reflects Ethereum’s dominant market position in DeFi and dApps after embracing institutional capital, making it difficult for non-Ethereum-aligned projects to compete. Ethereum tokens are issued and traded via smart contracts compliant with standards like ERC-20. Only in recent years has Bitcoin begun unlocking smart contract capabilities (e.g., BitVM) and introducing token standards such as BRC-20.
Enabling Smart Contracts on Bitcoin: RGB
RGB (Really Good for Bitcoin), launched in 2016, was initially conceived as a competitor to Colored Coins. Facing similar limitations, it evolved toward enabling smart contracts on Bitcoin. Although primarily focused on running smart contracts rather than issuing tokens, RGB's capabilities remain constrained by its virtual machine AluVM, limiting full functionality as of 2024.
RGB’s design philosophy moves data and smart contract logic off-chain, using Merkle roots to commit to transaction validity and token issuance. The Bitcoin chain only verifies these commitments and ensures finality, preventing double-spends.
A notable aspect of RGB is its use of client-side validation and single-use seals, avoiding direct tagging of UTXOs to represent tokens. These concepts were first proposed by Peter Todd in 2013, later developed into the RGB protocol by Giacomo Zucco and Maxim Orlovsky.
Client-side validation keeps transaction data and code off-chain and private—not broadcast publicly. Some data may only be exchanged privately between transacting parties, leaving others unaware. Off-chain states are anchored to Bitcoin, with the blockchain acting as a timestamping mechanism to prove chronological order.
Single-use seals—a common manifestation of client-side validation—are digital equivalents of tamper-evident seals. Leveraging the fact that each UTXO can only be spent once, off-chain state information is embedded into a UTXO. When that UTXO is spent, it signals a state update, and the new state is recorded in a newly created UTXO. This off-chain state could represent USDT ownership or token balances within a contract.
For example, if Alice wants to transfer a USDT to Bob, the USDT isn’t stored on Bitcoin’s chain. Its state is maintained off-chain but linked to a UTXO controlled by Alice. The commitment data resides in the OP_RETURN field of a zero-value UTXO generated in the transaction creating Alice’s UTXO. Only Alice can spend this USDT, and Bob can trace through on-chain transactions to verify past UTXOs holding this USDT, checking their validity and legitimacy. When Alice initiates a transfer, committing the USDT state to a UTXO under Bob’s control, Bob can confirm he now owns the USDT.
RGB can also operate over the Lightning Network, as its state is off-chain—only commitments need anchoring on-chain or within Lightning. After the Taproot upgrade, RGB can embed commitments into Taproot transactions, allowing more flexible integration with Bitcoin.
To learn more about RGB:
Tokens Without Smart Contracts: Taproot Assets
Taproot Assets is a project developed by the Lightning Network Daemon (LND) team. Its mechanism resembles RGB but does not support complex smart contracts—only basic tokens (see explanation of the Taproot term for details).
To learn more about Client-side validation, RGB, and Taproot:
Making Every Satoshi Unique: Ordinals & Inscriptions
In early 2023, Casey Rodarmor released the Ordinal protocol. It began with a simple idea: how to number each satoshi so that every one has a unique ordinal number and can be ordered. Though conceptually contemporaneous with Colored Coins, it wasn’t revived until recently. Thanks to SegWit and Taproot upgrades, implementation became feasible. By making each satoshi distinct, Ordinals enable direct NFT issuance on Bitcoin.
Inscriptions is an NFT project built on this principle. NFT data is stored in the witness section of transactions—not in OP_RETURN fields used by earlier projects—allowing metadata up to 4MB. Unlike Ethereum NFTs, Inscriptions store both metadata and images directly on-chain.
To learn more about ordinals:
Bidirectionally Binding Any UTXO Chain: RGB++ Isomorphic Binding
RGB++ originally emerged as an isomorphic binding protocol between BTC and CKB (Nervos Network's base layer), but its applicability now extends broadly—not limited to BTC-CKB pairs. In theory, any two UTXO-based chains can be bound together using this protocol.
RGB++ further develops RGB’s concepts of Client-Side Validation and Single-Use-Seals. As previously noted, RGB’s main drawback is that users must store their own data locally. If lost, there is no backup or recovery option. Additionally, because users only retain data relevant to their own tokens, verifying other transactions becomes difficult. The isomorphic binding solution addresses this by not only anchoring tokens to Bitcoin UTXOs via OP_RETURN but also binding corresponding Bitcoin transaction data into CKB chain transactions—achieved by using a special IB-lock-script within the Lock Script of a CKB Cell. When validating a transaction on CKB, the Lock Script uses BTC light client data stored on CKB to check whether the referenced UTXO has been spent and whether the newly created UTXO properly binds the current token transaction information (as unsigned partial data).
Key features of RGB++:
-
Solves data availability via bidirectional binding:
-
CKB Cell commitments are bound to UTXO OP_RETURN fields
-
UTXO information is bound to output Cells in CKB transactions
-
-
Compatible with Lightning Network and Fiber Network (a CKB-based Lightning variant)
-
Supports multiple assets
-
Can bind to any UTXO chain
To learn more about RGB++:
To clearly understand the strengths and limitations of each project, we compare them in the table below. Key evaluation metrics include:
-
Data availability: Isomorphic chains and sidechains perform similarly, while off-chain solutions suffer lower availability. Ranking from strongest to weakest: on-chain ≥ isomorphic chain ≥ sidechain > off-chain;
-
Asset carrier: Token schemes directly linked to BTC are superior to those indirectly connected;
-
Fungibility: Refers to whether the project’s native tokens are mutually interchangeable—not whether NFTs can be supported, as NFTs can be added via extended protocols;
-
Expressiveness: Indicates capability to handle complex smart contracts.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
