Author: 3P Labs
Colored Coin is a token based on Bitcoin that can distinguish different assets through coloring; Ordinals theory is a mathematical theory that can be used to design more complex token transfer processes; Taro protocol is a new type of second-layer network protocol that can achieve more efficient transaction processing.
Introduction
In the first part of the Ordinals vs Taro series, we briefly introduced the theoretical implementation of Taro asset minting and transfer operations in the Taro protocol. Here, we will review the implementation theory of Ordinals and Colored Coin for comparison, and further introduce the implementation and progress of Taro to explore the feasibility of Bitcoin’s second-layer network implementation in depth.
The article will be divided into the following four parts: Origin of Bitcoin Homogeneous Token Colored Coin, Ordinals Theory, Taro Implementation and Progress, and Further Reading: Atomicals Protocol.
- Brazil’s securities regulatory agency plans to establish a tokenized sandbox in 2024.
- Forbes Survey | How Did Zhao Changpeng Turn a Failed Token ICO into Unexpected Billions of Dollars
- India will push for cryptocurrency regulatory negotiations at the final FMCBG conference held in Morocco.
Review: Origin of Colored Coin
Colored Coin is a new token generated on the Bitcoin network proposed by Yoni Assia, Vitalik Buterin, and others in 2012 [1] [2]. Colored Coin was the prototype of the common ERC-20 tokens today, which was used to represent assets and conduct voting at that time, similar to the functions carried by ERC-20 today. On the former Colored Coin browser Coinprism, we can still see a series of assets issued by people in 2015, as shown in the snapshot left on the webpage in 2015: Coinprism Snapshot – archive.org.
Coinprism Snapshot
Principle
Colored Coin distinguishes a group of bitcoins from other bitcoins through “coloring”. There are two implementation methods for colored coins: the EPOBC protocol proposed by ChromaWay and open assets that use OP_RETURN to store metadata. Here, we will briefly introduce the implementation principle of open assets, which is also mentioned by Yoni and others in the Colored Coins whitepaper [3].
OP_RETURN was proposed in Bitcoin v0.9.0 and can be used to store a small amount of data on Bitcoin [4]. At first, it was limited to storing data of 40 bytes in length, which was later increased to 80 bytes. The Colored Coin whitepaper (2013) used 40 bytes of encoding to achieve coloring, while the Colored Coin protocol specification in 2016 [5] used a specification of 80 bytes in length. The Colored Coin protocol specification in 2016 is more complex and also involves the mini script language of colored coins, which will not be elaborated here. The original idea of colored coins was to use OP_RETURN to store specific encoding information in the output script of a transaction, and then rely on off-chain indexing programs to identify the legitimacy of these transactions (as seen in the Ordinals that appeared at the end of 2022).
Create Assets
In the original Colored Coin whitepaper, the data encoding for creating assets is shown below 
The encoding format in the Color Coin white paper
The encoded data starts with 0x0043438000 (“CCP”) to identify it as a Color Coin genesis transaction. This is followed by two bytes representing the current protocol version. The next two bytes are for additional issuance instructions, with all 0s indicating that the asset cannot be issued further, and all 1s indicating that the asset can be infinitely issued. The last 31 bytes are used to store information about coloring. A genesis transaction for an asset described in the white paper is as follows:
The encoded data in the output OP_RETURN indicates that this transaction is the genesis transaction for the asset. According to the encoding rules, the asset created by this transaction can be infinitely issued by a wallet with the address 17zt…sSrb (since the first input address is this address and the protocol allows it to be used as an issuance address). The addresses before the OP_RETURN output can be identified as the addresses receiving the genesis asset. The first three addresses will receive 9,900,000 units of the asset, while the last address will receive 19,900,000 units of the asset. It can be seen that each satoshi in the Color Coin corresponds to a colored asset.
Why is the received asset quantity subtracted by 10,000? This is because the protocol defines a default padding of 10,000 (LianGuaidding), which ensures that 10,000 satoshis are not colored to avoid dust transactions.
Asset Transfer
Asset transfers can be designed to be more complex, such as transferring multiple colored tokens of different colors in a single transaction. However, for the sake of simplicity, let’s assume that the transfer involves a single colored token. The transfer involves the input sequence number (sequence, a field in Bitcoin transaction inputs, usually visible as the nSequence field in browsers), which represents in binary which output the token will be transferred to. For example, 6 (110b) indicates that the token will be output to the first and second outputs, not the 0th or other outputs. A token transfer transaction is shown below, with the address information of the inputs and outputs omitted. The dark color in the figure indicates that the input or output has been colored.
Colorful Transfer Transaction
Representing it as the transfer state of the Color Coin, removing LianGuaidding and converting the sequence number to a readable form, the initial state can be obtained as follows. The colored markers in the outputs are indicated directly by the final state.
Color Coin Transfer State Representation
Starting from input 0 and traversing the sequence numbers, the transfer process is shown in the following figure:
Transfer State Changes
-
Transfer 5 colored assets from input 0 to output 1. At this time, subtract 5 from the sLianGuaice in outputs 0 and 1. Since it is transferred to 1 and input 0 is a colored asset, the colored value in output 1 is increased by 5.
-
Transfer 10 colored assets from input 1 to output 1. At this time, subtract min(5, 10) = 5 from output 1. Since it is transferred to 1 and input 1 is a colored asset, the colored value in output 1 is increased by 5.
-
Transfer 10 colored assets from input 1 to output 2. At this time, subtract min(5, 10) = 5 from output 2. Since it is transferred to 2 and input 1 is a colored asset, the colored value in output 2 is increased by 5.
-
Transfer 20 colored assets from input 2 to input 1. Subtract min(0, 20) = 0 from their sLianGuaice, but input 2 is not colored, so there is no change in the colored value in output 0.
Through this process, it can be seen that the transfer rules of colored coins are quite complicated. The off-chain indexing program needs to implement a UTxO calculation for the transfer of colored coins based on Bitcoin’s UTxO and a series of rules. The whitepaper on colored coins in 2012 also mentioned decentralized exchange technology, which completes the exchange of colored coins in one transaction. Unfortunately, the partial signature transaction technology (PSBTs – BIP0174) required for this technology was not included in BIP until 2017, which required a centralized platform to identify it through an order book (so is this still centralized?).
Dex in the whitepaper on colored coins
In addition, the v2 version of the colored coin protocol specification in 2016 further designed the bytecode, transfer address, and verification rules needed for colored coins. Unfortunately, due to the limitations of Bitcoin’s functionality at that time, this set of rules did not further develop, and the emergence of Ethereum in 2015 made such a design seem redundant, and colored coins ended their development here. Some people also say that the reason for the failure of colored coins is that they are coupled with native BTC and can be mistakenly sent as BTC in some cases, resulting in a reduction. However, the author believes that the reason for its failure is the inconvenience of circulation and the limited application scenarios.
Ordinal Theory: Ordinals
Time came to December 2022, thanks to the SegWit in 2017, partial signature transaction technology, and the Taproot upgrade activation in 2021, Casey Rodarmor invented the ordinal theory[7]: Ordinal is a numbering scheme for Bitcoin, which makes it possible to track and transfer individual sats[6], and it is numbered based on the order in which each Bitcoin is mined and the first-in-first-out rule when transacting.
The representation of ordinals:
-
Integer symbol:
2099994106992659This serial number is allocated according to the order of the mined sats. -
Decimal symbol:
3891094.16797, the first number is the block height of the mined sat, and the second number is the offset of the sat within the block. -
Degree symbol:
3°111094′214″16797‴, the specific degree representation principle is described in the ordinal theory manual -
Percentage symbol:
99.99971949060254%. Represents the position of a sat in the Bitcoin supply in percentage. -
Name:
satoshi(sat). Encodes the serial number using the characters from a to z.
Inscription
The ordinal theory is more about tracing the smallest unit of Bitcoin, sat. The rules designed by it make each sat have its own unique number. Based on the ordinal theory, some unique data on the chain can be associated with these sats, which is called “inscription”. Inscriptions are stored in taproot scripts, taproot scripts have few restrictions on content, and can obtain additional witness discounts, making the storage of inscriptions more economical. The Taproot script format for inscriptions is similar to:
It is stored in the input witness script of the Reveal transaction and is identified and exposed by the off-chain indexing node (ord) when traversing the block.
Due to the limitation of indexing and the inability to perform operations on-chain, Inscription needs to be implemented by ord’s openness when additional functionality needs to be implemented, such as recent parent-child inscriptions and curse inscription indexes several months ago. The basic idea of inscription is very similar to Colored Coin. They store data in transactions and index them off-chain, but the difference is that inscription stores data in the Taproot script of the input, while Colored Coin stores encoded data in an output.
With this, the Bitcoin ecosystem has been able to develop, allowing people to mint NFTs on-chain, and thanks to partial transaction signature technology, a trading market has also emerged. The technology of inscription itself is very similar to colored coins. They both store data on the chain and are indexed by off-chain indexing tools. However, due to different times and different functions they target, colored coins were limited by the functional deficiencies of Bitcoin at that time and did not get much development. What should make Ordinals develop and explode is its lower engraving cost (compared to the previous competitor bitcoin stamp[8]) and the market that has emerged due to the benefits of partial signature transaction technology, which makes it convenient for people to trade inscriptions.
BRC-20
Subsequently, the inscription-based BRC-20 protocol also appeared in March 2023. As mentioned in the previous article, this homogenized token implementation method has a beautiful aesthetic of violence, writing the token minting and transfer process on paper, and leaving the rest to the BRC-20 indexer, which is like adding another index on top of the Bitcoin indexer Inscription. Of course, in the actual implementation, the BRC-20 indexer can directly ignore other NFT minting and only focus on the minting and transfer of BRC-20.
Thus, BRC-20 also has a bit of the appearance of Bitcoin’s layer 2 network: the layer 2 network processes a series of transactions, periodically communicates with the main chain, and submits transactions to achieve bundling to ensure decentralization. In BRC-20, this is reflected in the indexer indexing the user’s account balance to ensure the validity of certain BRC-20 inscriptions (process transactions), and the transfer and minting process is implemented by the user themselves (submitting transactions to the main chain).
Interestingly, in the photos released at the recent Ordinals Summit, two concepts are mentioned in the PPT of brc20-swap displayed by domo, the founder of BRC-20: Inscription-Based Virtual Machines and Rollup, which seems to indicate that BRC-20 will also move towards layer 2 networks in the future.
Taro Implementation and Progress
In the previous article, the principle of how Taro assets are minted and transferred on-chain was introduced. So how is it actually implemented? Compared to the introduction of the principle in the previous article, here we will introduce the current implementation method and the latest progress of Taro.
Taro Implementation Details
Due to well-known reasons, it is not possible to join the test network with a locally deployed Lightning Network node for testing purposes. Therefore, the testing process will be explained through the Understanding Taproot Assets Protocol #2.
Asset Minting
As mentioned in the previous section, asset minting requires selecting the input UTxO and recording the root node information of a new Merkle Sum Tree (MS-SMT) in the asset tree.
After completing the asset minting process, the information of the asset can be obtained:
{
"assets": [
{
"version": 0,
"asset_genesis": {
"genesis_point": "ba779153a792a1d49433fd18e56311f8d212992e7d1405cb14af8dffb34e88ce:0",
"name": "fantasycoin",
"meta_hash": "04e552053fd4c8e2c01bc14cb9a0ce00f07d4ffdffff68fe455c70b934b22a43",
"asset_id": "20cecdb6626705bf26ad036084f7423082db6114f0de84046ebf2e84f6852874",
"output_index": 0,
"version": 0
},
"asset_type": "NORMAL",
"amount": "100",
"lock_time": 0,
"relative_lock_time": 0,
"script_version": 0,
"script_key": "02b4c71447e74672f8cd5b50a6b430fc73b3caff7866dc905a502fe8adefad3b31",
"script_key_is_local": true,
"asset_group": null,
"chain_anchor": {
"anchor_tx": "02000000000101ce884eb3ff....",
"anchor_txid": "ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356",
"anchor_block_hash": "0000000000000000000000000000000000000000000000000000000000000000",
"anchor_outpoint": "ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356:0",
"internal_key": "03d9f42daae1b7832d77d3ec83ddbb62e71266f6aedf6bcceb944e9672177c9301",
"merkle_root": "634ff6d86b8889f119f505a9bcba38fe4c6bda4b5a40a439fce37184badff63f",
"tapscript_sibling": null
},
"prev_witnesses": [
],
"is_spent": false
}
]
}
This output contains three important fields: asset_genesis, script_key, and chain_anchor
-
asset_genesis: explains the creation information of the asset, such as the metadata hash value, input UTxO number, and asset id
-
script_key: similar to the
ScriptPubKeyin P2TR transactions, the witness script that meets the conditions is required to spend this UTxO representing the asset (as mentioned in the previous section) -
chain_anchor: explains the transaction information of the asset anchored on the current chain, storing the transaction, transaction hash value, hash value of the block in which the transaction is located, and the output UTxO of the asset transfer
Similarly, in the genesis transaction ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356, corresponding outputs are also generated, and the output ScriptPubKey (through private keys or paths) needs to be satisfied to unlock this UTxO and use it in the next transaction. Moreover, in the next transaction for Taro asset transfer, the internal script_key requirement also needs to be satisfied.
One problem here is: how to ensure that this UTxO can be used to spend Taro assets normally? Perhaps the way to force the unlocking of the private key path can be removed (in P2TR, private keys or input scripts can be used to unlock UTxO), so that users can only spend Taro assets through script paths. Due to limited available information, the solution to this problem is not reflected. Perhaps this is also a problem that the Lightning Labs team is currently solving, as they stated on their GitHub page: the current code does not yet support the operation on the mainnet, which may cause users to lose Taro assets and UTxOs containing BTC.
In addition, there is no available information on the implementation details of the witness scripts. If deeper understanding is needed, it can only be found in the source code, which requires more time. Therefore, no further in-depth explanation will be provided here.
Asset Transfer
In Taro Asset, asset transfer requires both parties involved in the transfer to synchronize their universes. As mentioned earlier, Taro Universe stores the metadata of Taro assets and can be viewed as a database that stores this series of transaction information. Transactions are only sent to Bitcoin when there is a need to prove that these transactions and minting behaviors actually occurred (this seems to be a limiting mechanism, such as the discussion in the previous section on ensuring that UTxOs are definitely spent as Taro assets). Therefore, before the transaction, the parties involved need to synchronize information to ensure the validity of the transaction. Afterwards, when sending Taro assets to another address, a transfer message similar to a transaction is generated:
{
"transfer": {
"transfer_timestamp": "1684836471",
"anchor_tx_hash": "e4efa1c3272009193e961f383b29c1bc84cf6ed8eb0806bf94056a41387835b3",
"anchor_tx_height_hint": 2434958,
"anchor_tx_chain_fees": "12725",
"inputs": [
{
"anchor_point": "ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356:0",
"asset_id": "20cecdb6626705bf26ad036084f7423082db6114f0de84046ebf2e84f6852874",
"script_key": "02b4c71447e74672f8cd5b50a6b430fc73b3caff7866dc905a502fe8adefad3b31",
"amount": "100"
}
],
"outputs": [
{
"anchor": {
"outpoint": "b3357838416a0594bf0608ebd86ecf84bcc1293b381f963e19092027c3a1efe4:0",
"value": "1000",
"internal_key": "024a3cb06616bb1545d3a25417a3fa5ccc70c5fbe9ceed8666410ed83745bbe968",
"taproot_asset_root": "42ac8c2338032a0b0ea9b96916da31a8798eef30cbef2a80b8c6d60249e4698d",
"merkle_root": "42ac8c2338032a0b0ea9b96916da31a8798eef30cbef2a80b8c6d60249e4698d",
"tapscript_sibling": null,
"num_LianGuaissive_assets": 0
},
"script_key": "02258420ed4cf219965908102c6f8498da274c251a3463880763ba118c2d946c62",
"script_key_is_local": true,
"amount": "79",
"new_proof_blob": "00245663d6bf6a1...",
"split_commit_root_hash": "fdee0a27d560e5223b5e06b7a61d3df5b405942d21cf887fc96b16088874546a",
"output_type": "OUTPUT_TYPE_SPLIT_ROOT"
},
{
"anchor": {
"outpoint": "b3357838416a0594bf0608ebd86ecf84bcc1293b381f963e19092027c3a1efe4:1",
"value": "1000",
"internal_key": "033e42d7bdc3c5161c2dc440667b0f4fca4c4a7d32d13efac12a71994651b048ce",
"taproot_asset_root": "8aada842f74c2b11e9b5a0a716baa0c453855ab6ea316222a8a28e7e79506f41",
"merkle_root": "8aada842f74c2b11e9b5a0a716baa0c453855ab6ea316222a8a28e7e79506f41",
"tapscript_sibling": null,
"num_LianGuaissive_assets": 0
},
"script_key": "0225357fc148c441fbd5c5ea533fd6c33686697967a1cf8c493628788a535f433c",
"script_key_is_local": true,
"amount": "21",
"new_proof_blob": "00245663d6bf6a1de069c4562620f...",
"split_commit_root_hash": null,
"output_type": "OUTPUT_TYPE_SIMPLE"
}
]
}
}
Users who mint assets use the corresponding UTxO that anchors the assets as inputs and generate two outputs to two addresses. The information in “outputs” helps the recipient verify whether the received UTxO is valid. At the same time, the information in “outputs” also provides the recipient with the information needed to generate the next transfer, ensuring that the UTxO can be consumed normally by generating a valid witness script. Combining the previous discussion on the asset tree and the process of Taro asset transfer, “asset_id” can be used to index the leaf node representing the asset in the asset tree. The leaf node also stores the total amount of the asset, and this information is stored in the Taro Universe, which can be seen as an off-chain indexing program. Through “script_key”, the corresponding balance of the spendable assets can be queried in the corresponding MS-SMT of the asset. Wallets that meet the spendable conditions can use these outputs as inputs for the next transaction.
The above “transfer” is a “split” process (100 -> <79, 21>), so the output type to itself is “OUTPUT_TYPE_SPLIT_ROOT”. Similarly, there is also a merge operation, which merges assets under different “script_key” that can be consumed by a wallet into one.
The operations involving Taro assets are only reflected on the blockchain in the form of a LianGuaiy-To-Taproot (P2TR). The main asset transfer process still occurs off-chain. From this perspective, Taro Asset can be seen as a second-layer network of Bitcoin.
Recent Progress
The functions currently implemented on the Taproot-Asset page include:
-
Asset minting
-
Synchronization of Taro Universe
-
Sending/receiving assets
-
Importing/exporting asset proofs
-
Creating and managing CLI configuration files
From the latest version 0.2.3, the Lightning Labs team is still fixing legacy issues and improving the original program logic, such as adding the block height to the asset minting proof. On the program’s Github page, it is also mentioned that this code is not suitable for the mainnet and may result in the loss of Taro assets and BTC. In the official Slack discussion, developers also mentioned that the Lightning Network does not yet support Taro assets.
The v0.2.0 version that satisfies asset minting was officially released in May this year. This version has already implemented the functions of asset minting/transfer/reception. What remains is perhaps refining the transaction rules (as mentioned earlier) and fixing bugs in the program. Therefore, Taro assets still have a long way to go. Currently, they cannot meet the requirements for operation on the mainnet. I believe that in the next year or two, there may be hope to witness the official operation of Taro assets.
Expansion: Atomicals Protocol
Since I completed the previous article in this series and wrote this article, another competitor of Ordinals has emerged – Atomicals Protocol10 (Atomic Protocol). It is similar to Ordinals Inscription in terms of minting, both requiring a commit transaction as input and writing “envelope” in the witness script, and the data format is also very similar:
OP_FALSEOP_IF 0x0461746F6D // Push "atom" 4 bytes // Followed by a single push to denote the operation type // LianGuaiyload (CBOR encoded) for the operationOP_ENDIF
ARC-20
ARC-20 is a homogeneous token based on the atomic protocol. It has completely different minting and transfer rules from BRC-20.
Minting: ARC-20 also requires pre-deployment of tokens, which is done by sending Atomicals-formatted transactions. The deployment needs to specify the token’s name, minting height, associated image, minting quantity, and other information. After being indexed by the indexer, others can obtain token information and mint tokens through the indexer. ARC-20 also designs a minting method similar to mining. The deployer can specify the collision prefix of the commit tx and the collision prefix of the reveal tx. If these prefix information is set, the minter needs to select a nonce to change the hashes of the commit tx and the reveal tx to select the prefix that meets the condition (up to now, there is no requirement for collision of reveal tx, but the source code has this function). After the user finds a nonce that meets the condition, they will send the minted token name and the nonce that meets the condition to the encoded atomic protocol transaction to complete the minting on the Bitcoin chain, and the balance information will be indexed by the indexer.
Transfer: The transfer of ARC-20 is very similar to colored coins, but much simpler. ARC-20 is bound to the UTxO of Bitcoin. If these tokens are used as inputs, the i-th input will flow to the i-th output. If there are not enough outputs, i.e. the number of inputs is greater than the number of outputs, these tokens will flow to the first output.
Atomic Protocol
The advantage of this transfer method is that it avoids the need for minting transfer inscriptions like BRC-20, making the transaction of homogeneous tokens more convenient. If partial signature technology is used, the exchange of tokens and BTC within a single transaction can be completed through transaction consolidation, even the exchange of multiple different tokens. The disadvantage is that this implementation makes it too easy for users to lose tokens, especially when receiving multiple copies of the same type of token. After consolidating the UTxO, these UTxOs representing tokens can easily be spent as gas or even spent during the process of minting other tokens.
In addition, the atomic protocol also includes the design of NFT and domain names (independent of NFT). The document also contains unfinished contracts and events. Due to the lack of official documentation, it is not possible to continue the in-depth introduction.
Protocol Comparison
In this case, it is necessary to compare the Taro assets, Ordinals’ BRC-20 tokens, and the atomic protocol. The similarity between them lies in the fact that the minting and transfer of tokens are tracked and recorded by off-chain programs, but the rules of recording and their manifestation on the chain are not exactly the same.
Comparison of Various Protocols
Conclusion
Finally, after introducing these technologies, let’s discuss the possibility of Bitcoin implementation: in common Layer 2 network implementations, a separate blockchain network is usually built to execute transactions, and these executed proofs are then put into the main chain of Layer 1. This is also the basic principle of Rollup, regularly submitting proofs to the main chain. The Lightning Network, as a Layer 2 payment network for Bitcoin, also implements a similar Rollup technology. After establishing a channel, the two parties engage in a series of interactions, and when confirming, they close the channel and provide proof on the chain.
Taro assets are designed in a similar way to UTxO to achieve the minting and transfer of assets. Its purpose may be to be compatible with the Lightning Network, so that this exchange mode can also be effective on the Lightning Network. Both parties only need to use a similar Lightning Network mode to exchange assets, and finally, when back to Bitcoin, submit proof transactions to prove that these assets have been implemented in the Layer 2 network. If the implementation process of these assets is all done on Bitcoin, it can be seen as proof that each transaction has been submitted on Bitcoin, ensuring the validity of off-chain asset proofs. However, this implementation method heavily depends on the off-chain Taro Universe index. If the metadata is lost, it is likely to result in the loss of user assets. These indexes are highly decentralized. Perhaps they can be composed into a P2P network, forming a distributed storage similar to IPFS? The advantage of this is that it facilitates the circulation of homogeneous token-like assets, but the disadvantage is that non-fungible token assets become meaningless (just as someone might ask, why not use ERC721 directly?).
On the other hand, BRC-20 violently records minting and transfer data and indexers index the ledger information. Its disadvantages are obvious. Users need to first engrave the transfer inscription in order to transfer, and this is a condition that it has to meet due to its dependence on Ordinals. If BRC-20 does not depend on Ordinals but instead designs a set of designs similar to Ordinals to achieve better liquidity, it may not be able to leverage the popularity of Ordinals. Of course, the benefit of this is that the indexing method is very simple and does not require storing too much additional metadata (compared to the metadata information stored in Taro assets), but this also limits its scalability. As for Ordinals, as an NFT, it performs well in terms of functionality. Its data is stored on-chain and can be indexed (although miners can discard this part of the witness data), showing a different way from ERC-721. Ordinals itself cannot be considered a Layer 2 network, but after the existence of BRC-20, it shows the appearance of a Layer 2 network, but the data changes are manifested on Bitcoin, not in this Layer 2 network (indexer). It is only for ensuring accurate accounting.
It can be seen from this that both Taro assets and Ordinals have their own highlights, especially in the implementation of fungible tokens and non-fungible tokens. Taro has considered many aspects in the implementation of fungible tokens, such as using Taproot to compress transactions, enabling the exchange of large amounts of assets in a single transaction, and using a UTxO-style transaction model to meet the compatibility of the Lightning Network. However, its implementation of NFTs appears to be somewhat lacking compared to the distinctive on-chain data storage of Ordinals inscriptions, which sets it apart from ERC-721 tokens. Moreover, the user transaction process based on its implementation of BRC-20 tokens is cumbersome, but the interaction within Taro assets does not make users aware of all of this. Such contrasts clearly highlight the differences between fungible tokens and non-fungible tokens, especially on a blockchain like Bitcoin that is based on the UTxO model, where the underlying design choices made by the protocol are particularly important.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
