Introduction

In the previous article of the Ordinals vs Taro series, we briefly introduced the theoretical implementation of minting and transferring Taro assets in the Taro protocol. Here, we will review the theoretical implementation of Ordinals and Colored Coin for comparison, and further introduce the implementation and current progress of Taro to explore the feasibility of the Bitcoin Layer 2 network in depth.

The article will be divided into the following four parts: Bitcoin Homogeneous Token Origin Colored Coin, Ordinal Theory, Taro Implementation and Progress, Further Reading: Atomicals Protocol.

Review: Origin of Colored Coin

Colored Coins were proposed by Yoni Assia, Vitalik Buterin, and others in 2012 as a new token generated on the Bitcoin network[1] [2]. Colored Coins should be the prototype of the commonly seen ERC-20 tokens today, which were used at the time to represent assets and conduct voting, similar to the functions carried by ERC-20 today. On the former Colored Coins browser Coinprism, we can still see a series of assets issued by people in 2015, as shown in the snapshot of the webpage in 2015: Coinprism Snapshoot - archive.org.

Coinprism Snapshoot

Principle

Colored Coins distinguish a group of bitcoins from other bitcoins through "coloring." There are two ways to implement Colored Coins: the EPOBC protocol proposed by ChromaWay and the Open Assets that use OP_RETURN to store metadata. Here, we briefly introduce the implementation principle of Open Assets, which is also mentioned as a method 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]. Initially, it was limited to storing data of 40 bytes in length, which was later increased to 80 bytes. The Colored Coins whitepaper (2013) used a 40-byte encoding to implement coloring, while the 2016 Colored Coins protocol specification[5] used an 80-byte specification. The 2016 Colored Coins protocol specification is more complex, involving the mini-script language of Colored Coins, which is not 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 appearance of Ordinals at the end of 2022).

Asset Creation

In the original Colored Coins whitepaper, the data encoding for creating assets is as follows:

Encoding format in Colored Coins whitepaper

The encoding data starts with 0x0043438000 ("CCP") to identify it as a genesis transaction of Colored Coins, followed by two bytes representing the current protocol version. The next two bytes indicate the issuance description, where all 0s mean the asset cannot be issued further, and all 1s mean the asset can be issued infinitely. The last 31 bytes are used to store information about coloring. A genesis transaction of an asset described in the whitepaper is as follows:

The encoding data in the OP_RETURN output indicates that this transaction is the genesis transaction of the asset. According to the encoding rules, the asset created by this transaction can be infinitely issued by the wallet with the address 17zt…sSrb (because the first input address is this address, according to the protocol, it can serve as the issuance address), and 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 of the asset, while the last address will receive 19,900,000 of the asset. It can be seen that in Colored Coins, each satoshi is colored corresponding to a certain colored asset.

Why is the received asset quantity reduced by 10,000? This is because the protocol defines a default padding of 10,000, which allows 10,000 satoshis to remain uncolored to avoid dust transactions.

Asset Transfer

The transfer of assets can be designed to be more complex, such as transferring multiple colored tokens of different colors in one transaction. However, for the convenience of representing the transfer process, it is assumed here that the transfer is of a single colored token. The transfer involves the input sequence number (sequence, a field in the input of a Bitcoin transaction, usually visible as the nSequence field in the browser), which in its binary form indicates to which output the token will be sent. For example, 6 (110b) indicates that the token will be sent to the first or second output, not the 0th or other outputs. A token transfer transaction is shown below, omitting the input and output address information. The dark color in the image indicates that the input or output has been colored.

Colored transfer transaction

Representing it as the transfer state of Colored Coins, removing the padding and converting the binary sequence number into a readable form, the initial state is as follows, and the colored markers in the output are directly marked.

Illustration of Colored Coins transfer state

Starting from the 0th input, the transfer process of the state is shown in the following figure.

Transfer state changes

• From input 0, transfer 5 colored assets to output 1. At this point, the space in outputs 0 and 1 is reduced by 5. Since it is transferred to output 1 and input 0 is a colored asset, the colored value in output 1 is increased by 5.
• From input 1, transfer 10 colored assets to output 1. At this point, the space in output 1 is reduced by min(5, 10) = 5. It is transferred to output 1, and since input 1 is a colored asset, the colored value is increased by 5.
• From input 1, transfer 10 colored assets to output 2. At this point, the space in output 2 is reduced by min(5, 10) = 5. It is transferred to output 2, and since input 1 is a colored asset, the colored value is increased by 5.
• From input 2, transfer 20 colored assets to input 1. The space in both of them is reduced by min(0, 20) = 0. However, input 2 is not colored, so there is no change in colored value in output 0.

Through this process, it can be seen that the transfer rules of Colored Coins are quite complex, and off-chain indexing programs need to implement a UTxO calculation for the transfer of Colored Coins based on Bitcoin's UTxO, following a series of rules. The 2012 Colored Coins whitepaper also mentioned decentralized exchange technology, which completes the exchange of Colored Coins in a single transaction. Unfortunately, the technology required partial signature transaction technology (PSBTs - BIP0174), which was not included in BIP until 2017, requiring a centralized platform to identify and implement it through an order book (so, is this still decentralized?).

Dex in the Colored Coins whitepaper

Furthermore, the v2 version of the 2016 Colored Coins protocol specification further designed the bytecode, transfer address, and verification rules required for Colored Coins. Unfortunately, this set of rules did not receive further development due to limitations imposed by Bitcoin's functionality at the time. Additionally, the emergence of Ethereum in 2015 further made such designs seem redundant, leading to the end of the development of Colored Coins. Some say that the reason for the failure of Colored Coins is its coupling with native BTC, which in some cases may be mistakenly sent as BTC and reduced. However, the author believes that its failure is due to the inconvenience of circulation and limited application scenarios.

Ordinal Theory: Ordinals

Fast forward to December 2022, thanks to the 2017 SegWit, partial signature transaction technology, and the 2021 Taproot upgrade activation, Casey Rodarmor invented Ordinal Theory[7]: Ordinals are a numbering scheme for Bitcoin, making it possible to track and transfer individual satoshis[6]. It assigns a unique number to each satoshi based on the order in which they were mined and follows a first-in, first-out rule when numbering transactions.

Representation of Ordinals:

• Integer symbol: 2099994106992659 - This number is assigned based on the order of mined satoshis.
• Decimal symbol: 3891094.16797 - The first number is the block height of the mined satoshis, and the second number is the offset within the block.
• Degree symbol: 3°111094′214″16797‴ - The specific degree representation principle is explained in the Ordinal Theory Manual.
• Percentage symbol: 99.99971949060254% - Represents the position of the satoshi in the Bitcoin supply as a percentage.
• Name: satoshi - Encodes the ordinal using the characters a to z.

Inscription

Ordinal Theory is more about tracing the smallest unit of Bitcoin, the satoshi. Its designed rules make it possible for each satoshi to have a unique number. Based on Ordinal Theory, some unique data on the chain can be associated with these satoshis, known as "inscription." Inscription is stored in the taproot script, which has minimal content restrictions and can receive additional witness discounts, making the storage of inscriptions more economical. The taproot script format for inscription is similar to:

It is stored in the witness script of the Reveal transaction's input and is identified and revealed by the off-chain indexing node (ord) when traversing the blocks.

However, due to the limitations of indexing and the inability to operate on the chain, when inscription needs to implement additional functionality, it can only be achieved through the openness of ord, such as the recent parent-child inscriptions and the curse inscription index a few months ago. The basic idea of inscription is very similar to Colored Coins; they both store data in transactions to be indexed by off-chain programs. The difference is that inscription stores data in the input's taproot script, while Colored Coins store encoded data in an output.

With this, the Bitcoin ecosystem has developed, allowing people to mint NFTs on the chain, and with the benefit of partial transaction signature technology, a trading market has emerged. The technology of inscription itself is very similar to Colored Coins, as they both store data on the chain to be indexed by off-chain tools. However, due to different times and different functionalities, Colored Coins were limited by the functional limitations of Bitcoin at the time and did not see further development. The development and explosion of Ordinals should be attributed to its lower inscription fees (compared to the earlier competitor bitcoin stamp[8]) and the emergence of a market due to the benefits of partial signature transaction technology, making it convenient for people to trade inscriptions.

BRC-20

Subsequently, the inscription-based BRC-20 protocol also emerged in March 2023. As mentioned in the previous article, this implementation of homogeneous tokens has a certain aesthetic appeal, with the token minting and transfer process written on paper, leaving the rest to the BRC-20 indexer, which is essentially an additional layer of indexing on top of Bitcoin's inscription. In practice, the BRC-20 indexer can directly ignore other NFT minting and only focus on the minting and transfer of BRC-20.

With BRC-20, there is now a bit of a Bitcoin Layer 2 network: the Layer 2 network processes a series of transactions, communicates with the main chain regularly, submits transactions to achieve bundling, and ensures decentralization. In BRC-20, this is reflected in the indexer indexing users' account balances to ensure the validity of certain BRC-20 inscriptions (processing transactions), while the transfer and minting processes are implemented by users themselves (submitting transactions to the main chain).

Interestingly, in a recent photo released from the Ordinals Summit, the founder of BRC-20, domo, presented a PPT on brc20-swap, mentioning two concepts: Inscription-Based Virtual Machines and Rollup. This seems to indicate that BRC-20 will also move into the Layer 2 network in the future.

Taro Implementation and Progress

In the previous article, we introduced the principles of how Taro assets are minted and transferred on the chain. But how is it actually implemented? In comparison to the previous article's theoretical introduction, here we will introduce the current implementation and the latest progress of Taro.

Specific Implementation of Taro

Due to well-known reasons, it is not possible to join the test network with a locally built Lightning Network node. Here, the testing process will be explained using the Understanding Taproot Assets Protocol #2.

Asset Minting

As mentioned in the previous article, 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, the information about 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
    }
  ]
}

The output contains three important fields: asset_genesis, script_key, and chain_anchor.

• asset_genesis: Describes the creation information of the asset, such as metadata hash, input UTxO number, and asset ID.
• script_key: Similar to the ScriptPubKey in P2TR transactions, it requires a witness script that meets the conditions to spend this representing asset UTxO (as mentioned in the previous article about UTxO*).
• chain_anchor: Describes the current chain transaction information to which the asset is anchored, storing transaction, transaction hash, block hash of the transaction, and the output UTxO for the transfer of this asset.

Similarly, in the genesis transaction ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356, a corresponding output is also generated, which requires a script to unlock this UTxO and use it for the next transaction (either by private key or path). Furthermore, the next transaction for Taro asset transfer also needs to meet the internal script_key requirement.

One issue here is: how to ensure that this UTxO can be spent for Taro asset expenditure? Perhaps the forced removal of the private key path unlocking method (under P2TR, private key or input script can unlock UTxO) can be considered, allowing users to only spend Taro assets through the script path. Due to limited available information, the solution to this issue is not apparent, and this may be a problem that the Lightning Labs team is currently addressing, as they mentioned on their Github page: the current code does not yet support running on the mainnet, which may lead to users losing Taro assets and UTxOs containing BTC.

Additionally, detailed information about the implementation of witness scripts cannot be found. If a deeper understanding is required, it would be necessary to review the source code, which would take more time. Therefore, a detailed explanation will not be provided here.

Asset Transfer

In Taro Asset, the transfer of assets requires both parties to synchronize their universes. As mentioned in the previous article, the Taro Universe stores the metadata of Taro assets and can be considered 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 actions have indeed occurred (which seems to also serve as a limiting mechanism, as discussed in the previous section about ensuring that UTxOs are necessarily spent as Taro assets). Therefore, before the transaction, both parties need to synchronize information to ensure the validity of the transaction. Subsequently, sending Taro assets to another address will generate transfer information similar to a transaction:

{
  "transfer": {
    "transfer_timestamp": "1684836471",
    "anchor_tx_hash": "e4efa1c3272009193e961f383b29c1bc84cf6ed8eb0806bf94056a41387835b3",
    "anchor_tx_height_hint": 2434958,
    // Other transfer information
  }
}

"anchortxchainfees": "12725", "inputs": [ { "anchorpoint": "ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356:0", "assetid": "20cecdb6626705bf26ad036084f7423082db6114f0de84046ebf2e84f6852874", "scriptkey": "02b4c71447e74672f8cd5b50a6b430fc73b3caff7866dc905a502fe8adefad3b31", "amount": "100" } ], "outputs": [ { "anchor": { "outpoint": "b3357838416a0594bf0608ebd86ecf84bcc1293b381f963e19092027c3a1efe4:0", "value": "1000", "internalkey": "024a3cb06616bb1545d3a25417a3fa5ccc70c5fbe9ceed8666410ed83745bbe968", "taprootassetroot": "42ac8c2338032a0b0ea9b96916da31a8798eef30cbef2a80b8c6d60249e4698d", "merkleroot": "42ac8c2338032a0b0ea9b96916da31a8798eef30cbef2a80b8c6d60249e4698d", "tapscriptsibling": null, "numpassiveassets": 0 }, "scriptkey": "02258420ed4cf219965908102c6f8498da274c251a3463880763ba118c2d946c62", "scriptkeyislocal": true, "amount": "79", "newproofblob": "00245663d6bf6a1…", "splitcommitroothash": "fdee0a27d560e5223b5e06b7a61d3df5b405942d21cf887fc96b16088874546a", "outputtype": "OUTPUTTYPESPLITROOT" }, { "anchor": { "outpoint": "b3357838416a0594bf0608ebd86ecf84bcc1293b381f963e19092027c3a1efe4:1", "value": "1000", "internalkey": "033e42d7bdc3c5161c2dc440667b0f4fca4c4a7d32d13efac12a71994651b048ce", "taprootassetroot": "8aada842f74c2b11e9b5a0a716baa0c453855ab6ea316222a8a28e7e79506f41", "merkleroot": "8aada842f74c2b11e9b5a0a716baa0c453855ab6ea316222a8a28e7e79506f41", "tapscriptsibling": null, "numpassiveassets": 0 }, "scriptkey": "0225357fc148c441fbd5c5ea533fd6c33686697967a1cf8c493628788a535f433c", "scriptkeyislocal": true, "amount": "21", "newproofblob": "00245663d6bf6a1de069c4562620f…", "splitcommitroothash": null, "outputtype": "OUTPUTTYPE_SIMPLE" } ] } ```

The user who mints the asset uses the corresponding UTxO anchored to the asset as input and generates two outputs to two addresses. The information in the outputs facilitates the recipient's verification of whether the received UTxO is legitimate. Additionally, the information in the outputs provides the recipient with the necessary information to generate a valid witness script for spending this UTxO in the next transfer. Combining the previous discussion of the asset tree and the Taro asset transfer process, the asset_id can be used to index the leaf node representing the asset in the asset tree, which also stores the total amount of the asset. This information is stored in the Taro Universe, which can be seen as an off-chain indexing mechanism. Through the script_key, the corresponding balance that can be spent for these assets can be queried in the MS-SMT of the corresponding asset. Wallets that meet the spendable conditions can use these outputs as inputs for the next transaction.

The "transfer" mentioned above is a "split" process (100 -> 79, 21), so the output type to itself is OUTPUT_TYPE_SPLIT_ROOT. Similarly, there are merge operations, which combine assets from different script_key that a wallet can spend into one.

The operations involved in Taro assets are only reflected on the blockchain in the form of a Pay-To-Taproot (P2TR) format. The main asset transfer process occurs off-chain, so from this perspective, Taro Asset can be seen as a second-layer network of Bitcoin.

Recent Progress

On the Taproot-Asset page, the currently implemented features include:

• Asset minting
• Synchronization of Taro Universe
• Sending/receiving assets
• Importing/exporting asset proofs
• Creating and managing CLI configuration files

From the latest version v0.2.3, it appears that the Lightning Labs team is still working on fixing legacy issues with the Taro program 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 the 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, which satisfies asset minting, was officially released in May of this year. This version has already implemented asset minting, transfer, and receive functions. The remaining work may involve refining transaction rules (as mentioned earlier) and fixing existing bugs. Therefore, Taro assets still have a long way to go and currently cannot meet the requirements for running on the mainnet. In the next year or two, there may be hope for the formal operation of Taro assets.

Expansion: Atomicals Protocol

Since the completion of the previous part of this series and the writing of this article, another competitor of Ordinals has emerged - the Atomicals Protocol. It is similar to Ordinals Inscription in that it requires a commit transaction as input and writes an "envelope" in the witness script before revealing. The data format is also very similar:

OP_FALSE
OP_IF
 0x0461746F6D // Push "atom" 4 bytes
 Operation>  // Followed by a single push to denote the operation type
 Payload>    // Payload (CBOR encoded) for the operation
OP_ENDIF

ARC-20

ARC-20 is a fungible token based on the Atomicals Protocol, and it has completely different minting and transfer rules compared to BRC-20.

Minting: Minting ARC-20 also requires pre-deployment of tokens, which is done by sending Atomicals-formatted transactions. The deployment specifies the token's name, minting height, associated image, minting quantity, and other information. Once indexed by the indexer, others can obtain token information through the indexer and proceed with minting. ARC-20 also has a minting method similar to mining, where the deployer can specify the collision prefix of the commit tx and reveal tx. If these prefixes are set, minters need to select a nonce during minting to change the hash of the commit tx and reveal tx to satisfy the conditions. After finding a nonce that satisfies the conditions, the minter sends the minted token name and the nonce to the encoded Atomicals Protocol transaction on the Bitcoin chain to complete the minting, while the balance information is indexed by the indexer.

Transfer: The transfer of ARC-20 is similar to colored coins but much simpler. ARC-20 is bound to the transaction outputs, so if the UTXO of these tokens is used as input, the i-th input will flow to the i-th output. If there are not enough outputs, i.e., when the number of inputs is greater than the number of outputs, these tokens will flow to the first output.

The benefit of this transfer method is that it avoids the need for a minting transfer inscription like BRC-20, making the trading of fungible tokens more convenient. With the use of partial signature technology, token and BTC exchanges can be completed by integrating transactions, and even exchanges of multiple different tokens can be achieved within a single transaction. However, the downside is that this implementation makes it very easy for users to lose tokens, especially when receiving multiple similar tokens and combining UTXOs, as these UTXOs representing tokens can easily be spent as gas, or even spent during the minting of other tokens.

In addition, the Atomicals Protocol also includes the design of NFTs and domains (independent of NFTs), and the documentation also includes unfinished contracts and events. Due to the lack of official documentation, further details cannot be provided.

Protocol Comparison

It is necessary to compare Taro assets, Ordinals' BRC-20 tokens, and the Atomicals Protocol. They are similar in that the minting and transfer of tokens are tracked and recorded by off-chain programs, but the rules and on-chain representation differ.

Conclusion

Finally, after introducing these technologies, let's discuss the possibility of Bitcoin implementation. In common second-layer network implementations, a separate blockchain network is usually built to execute transactions, and the executed proofs are then placed on the Layer 1 main chain, which is the basic principle of Rollup. The Lightning Network, as a second-layer payment network for Bitcoin, also implements a similar technology to Rollup. After establishing a channel, the two parties engage in a series of interactions, and when confirmed, the channel is closed, and proof is provided to the chain.

Taro assets are designed to use a UTXO-like method to complete asset minting and transfer, perhaps to be compatible with the Lightning Network, allowing this exchange mode to be effective in the Lightning Network. Both parties only need to use a mode similar to the Lightning Network for asset exchange, and when it needs to return to Bitcoin, proof transactions are submitted to prove that these assets have been implemented in the second-layer network. If the implementation of these assets is all done on Bitcoin, it can be seen as proving each transaction on Bitcoin, ensuring that off-chain asset proofs are valid. However, this implementation heavily relies on the off-chain Taro Universe index. If the metadata is lost, it could lead to the loss of user assets. These indexes are very decentralized, and perhaps these Universes can be formed into a P2P network, creating a distributed storage similar to IPFS? The benefit of this is to facilitate the circulation of fungible token assets for users, but the downside is that non-fungible token assets would then seem meaningless (as some may ask, why not just use ERC721 directly?).

BRC-20 violently records minting and transfer data, and the indexer indexes the ledger information. Its drawbacks are obvious - users need to inscribe a transfer inscription before making a transfer, which is a condition it must meet due to its reliance on Ordinals' implementation. If BRC-20 were designed to implement a system similar to Ordinals without relying on Ordinals' implementation, it might achieve better liquidity. However, this might not leverage the popularity of Ordinals. The benefit of this approach is that the indexing method is very simple and does not require storing excessive additional metadata (in contrast to the metadata stored in Taro assets), but this also limits its scalability. Ordinals, as an NFT, has excellent functionality, with its data stored on-chain and indexable (although miners can discard this witness data), demonstrating a different approach from ERC-721. Ordinals itself cannot be considered a second-layer network, but with the existence of BRC-20, it exhibits the characteristics of a second-layer network. However, data changes are reflected on Bitcoin, not on this second-layer network (indexer). Its purpose is solely to ensure accurate accounting.

It is evident that Taro assets and Ordinals each have their own highlights, especially in the implementation of fungible and non-fungible tokens. Taro has considered many aspects in the implementation of fungible tokens, including the use of Taproot to compress transactions, enabling the exchange of large amounts of assets within a single transaction, and the use of UTxO-like transaction methods to accommodate compatibility with the Lightning Network. However, its implementation of NFTs seems somewhat redundant, especially compared to the on-chain data storage of Ordinals' inscriptions, which distinguishes it and becomes a highlight compared to ERC-721. On the other hand, the BRC-20 implemented by Taro seems cumbersome in user transactions, but the interaction in Taro assets does not make users perceive all of this. This opposition clearly demonstrates the differences between fungible and non-fungible tokens, especially on a blockchain like Bitcoin, which is based on the UTXO model, making the underlying design of the protocol particularly important.

References

1. Colored Coins - wikipedia
2. bitcoin 2.X (aka Colored Bitcoin) – initial specs
3. Colored Coins whitepaper
4. NULL DATA - learn me a bitcoin
5. Coloring Scheme - Github
6. Overview - Ordinals Handbook
7. The Rise of Ordinals, the Explosive Era of BTC Ecology
8. Bitcoin Stamps
9. Atomicals Protocol
10. Taproot Assets Protocol
11. Understanding Taproot Assets Protocol #2

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