introduction
In the first part of the Ordinals vs Taro series, we briefly introduced the theoretical implementation of the minting and transfer operations of Taro assets in the Taro protocol. Here, we will review the implementation theories of Ordinals and Colored Coin for comparison, and further introduce the implementation and current progress of Taro to deeply explore the feasibility of Bitcoin's second-layer network implementation.
The article will be divided into the following four parts: The origin of Bitcoin homogeneous token Colored Coin, ordinal theory and Ordinals, Taro implementation and progress, and further reading: Atomicals Protocol.
Review: The Origin of Everything Colored Coin
Colored coins are a new type of token generated on the Bitcoin network proposed by Yoni Assia, Vitalik Buterin and others in 2012 [1] [2]. Colored coins should be the prototype of the currently common ERC-20 tokens. At that time, they were used to represent assets and conduct voting, which is 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. The picture is taken from the snapshot left by the webpage in 2015: Coinprism Snapshoot - archive.org.
Coinprism Snapshoot
principle
Colored coins distinguish a group of bitcoins from other bitcoins by “coloring” them. There are two ways to implement colored coins: the EPOBC protocol proposed by ChromaWay and Open Assets that uses OP_RETURN to store metadata. Here, we briefly introduce the implementation principle of Open Assets, which is also a method mentioned by Yoni et al. in the Colored Coins white paper [3].
OP_RETURN was introduced in Bitcoin v0.9.0 and can be used to store small amounts of data on Bitcoin[4]. The initial limit was 40 bytes of data, which was later increased to 80 bytes. The Colored Coins white paper (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 relatively complex, and also involves a mini-script language for colored coins, which will not be introduced here. The original idea of colored coins was to use OP_RETURN to store specific encoded information in the output script of a transaction, and then rely on the off-chain index program to identify the legitimacy of these transactions (such as Ordinals that appeared at the end of 2022).
Create assets
In the original colored coin white paper, the data encoding for creating assets is as follows:
The encoding format in the Colored Coin white paper
The encoded data starts with 0x0043438000 ("CCP") to indicate that this is a colored coin creation transaction, followed by two bytes indicating the current protocol version. The next two bytes are the additional issuance instructions. All 0s indicate that the asset cannot be additionally issued, and all 1s indicate that the asset can be additionally issued indefinitely. The last 31 bytes are used to store information about coloring. An asset creation transaction described in the white paper is as follows
The encoded data in the output OP_RETURN indicates that this transaction is the creation transaction of the asset. According to the encoding rules, the assets created by this transaction can be infinitely issued by the wallet with the address 17zt...sSrb (because the first address entered is this address, it can be used as an additional issuance address according to the protocol), and the address before the OP_RETURN output can be identified as the address that receives the creation asset. The first three addresses will receive 9,900,000 of the asset, and the last address will receive 19,900,000 of the asset. It can be seen that each colored satoshi in the colored coin corresponds to a colored asset.
Why is the amount of received assets subtracted by 10,000? This is because the protocol defines a default padding of 10,000, which allows 10,000 satoshis to be uncolored to avoid dust transactions.
Asset transfer
The transfer of assets can be designed to be more complex, such as transferring multiple tokens of different colors in one transaction, but for the convenience of representing the transfer process, it is assumed here that a single colored token is transferred. In addition, the transfer involves the input sequence number (sequence, which is a field in the input of Bitcoin transactions, usually visible in the browser as the nSequence field), which is a binary representation of which output the input will output the token to. For example, 6 (110b) means output to the 1st or 2nd output, not the 0th or other outputs. A token transfer transaction is shown below, where the input and output address information is omitted. The dark color in the figure indicates that the input or output is colored.
Color transfer transactions
Representing it as the transfer state of the colored coin, that is, removing the padding and converting the binary of the serial number into an easy-to-read form, the initial state can be obtained as follows. The output color mark is represented by the final state, which is directly marked here.
Colored coin transfer status
Starting from the 0th input, the sequence number is traversed to transfer the state. The transfer process is shown in the following figure
Transfer status changes
Transfer 5 colored assets from input 0 to output 1. At this time, the space in output 0 and 1 is reduced by 5. Since it is transferred to 1 and input 0 is a colored asset, the colored value of output 1 is increased by 5.
Input 1 transfers 10 dyed assets to output 1. At this time, min(5, 10) = 5 is first subtracted from output 1 and then transferred to 1. Since input 1 is a dyed asset, cvalue is increased by 5.
Input 1 transfers 10 dyed assets to output 2. At this time, min(5, 10) = 5 is first subtracted from output 2 and transferred to 2. Since input 1 is a dyed asset, cvalue is increased by 5.
Input 2 transfers 20 dyed assets to input 1, and min(0, 20) = 0 is subtracted from their spaces. However, input 2 is not dyed, so there is no change in cvalue in output 0.
Through this process, it can be seen that the transfer rules of colored coins are relatively complicated. The off-chain indexing program needs to implement a UTxO calculation for colored coin transfers based on Bitcoin's UTxO according to a series of rules. The 2012 colored coin white paper also mentioned decentralized exchange technology to complete the exchange of colored coins in one transaction. Unfortunately, the partially signed transaction technology (PSBTs - BIP0174) required for this technology was not included in the BIP until 2017. At that time, this required a centralized platform to identify it and implement it through an order book (so, is this still centralized?).
Dex in the Colored Coin Whitepaper
Moreover, the v2 version of the colored coin protocol specification in 2016 further designed the bytecode, transfer address, and verification rules required in colored coins. Unfortunately, this set of rules was not further developed due to the functional limitations of Bitcoin at the time, and the emergence of Ethereum in 2015 further made such a design seem useless, and the development of colored coins ended here. Some people also say that the reason for the failure of colored coins is that they are coupled with the original BTC, and in some cases they will be sent out as BTC and reduced. However, the author believes that the reason for its failure is the inconvenience of circulation and the lack of application scenarios.
Ordinals
Fast forward to December 2022. Thanks to the 2017 Segregated Witness, partially signed transaction technology, and the 2021 Taproot upgrade activation, Casey Rodarmor invented the ordinal theory[7]: the ordinal is a Bitcoin numbering scheme that makes it possible to track and transfer individual sats[6]. It numbers each bitcoin in the order in which it is mined and according to the first-in, first-out rule when trading.
Ordinal numbers are represented as follows:
Integer notation: 2099994106992659 This number is assigned according to the order in which Satoshis are mined.
Decimal notation: 3891094.16797, the first number is the block height where the satoshi was mined, the second number is the offset in satoshis within the block.
Degree symbol: 3°111094′214″16797‴. For the specific degree representation principle, please refer to the Ordinal Theory Manual.
Percent symbol: 99.99971949060254%. The percentage of Satoshi in the Bitcoin supply.
Name: satoshi. The serial number is encoded using characters a to z.
Inscription
The ordinal theory is more about tracing back to the smallest unit of Bitcoin, sat. The rules it designs 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, that is, "engraved" inscriptions. The inscriptions are stored in the taproot script. The taproot script has few restrictions on the content and can obtain additional witness discounts, which makes the storage of inscriptions more economical. The Taproot script format of the inscription is similar to:
It is stored in the input witness script of the Reveal transaction, and is recognized and revealed by the off-chain index node (ord) when traversing the block.
The reason why Inscription cannot be operated on the chain due to the limitation of indexing makes it necessary to open ord when implementing other additional functions, such as the recent father-son inscription and the curse inscription index a few months ago. The basic idea of inscription is very similar to Colored Coin. They store data in transactions and are indexed by off-chain programs. The difference is that inscription stores data in the input Taproot script, while Colored Coin stores the encoded data in an output.
At this point, the Bitcoin ecosystem has developed, people can mint NFTs on the chain, and thanks to the partial transaction signature technology, a trading market has also emerged. The inscription technology 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 the different times and the different functions they are aimed at, colored coins were limited by the functional defects of Bitcoin at the time and did not develop further. What made Ordinals develop and explode was probably its lower engraving fee (compared to its previous competitor, bitcoin stamp[8]), and the market that benefited from the partial signature transaction technology, which made it easy for people to trade inscriptions.
BRC-20
After that, the inscription-based BRC-20 protocol also appeared in March 2023. As mentioned in the previous article, this homogeneous token implementation method has a violent aesthetic beauty. The token casting and transfer process is written on paper, and the rest is handed over to the BRC-20 indexer, which is equivalent to adding another index on top of Bitcoin's index Inscription. Of course, in actual implementation, the BRC-20 indexer can directly ignore other NFT castings and only care about the casting and transfer of BRC-20.
BRC-20 has also taken on a bit of the look of Bitcoin’s second-layer network: the second-layer network processes a series of transactions, regularly 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 that certain BRC-20 inscriptions are valid (processing transactions), and the transfer and minting process is implemented by the user himself (submitting transactions to the main chain).
Interestingly, in the photos released by the Ordinals Summit not long ago, the founder of BRC-20, domo, mentioned two concepts in a PPT of brc20-swap: Inscription-Based Virtual Machines and Rollup, which seems to indicate that BRC-20 will also enter the second-layer network in the future.
Taro Implementation and Progress
In the previous article, we introduced the principle of how Taro assets are minted and transferred on the chain. So how is it implemented in practice? Compared with the introduction of the principle in the previous article, here we will introduce the current implementation method and latest progress of Taro.
Taro Implementation
Due to well-known reasons, the lightning network node used for local testing cannot join the test network normally. Here we will explain it through the testing process of Understanding Taproot Assets Protocol #2.
Asset Minting
As mentioned in the previous article, the minting of assets requires the selection of input UTxOs and the recording of the root node information of a new Merkle Sum - Merkle Tree (MS-SMT) in the asset tree.
After the asset is minted, you can get the asset information:
{
"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 here contains three important fields:
asset_genesis
、 script_key 和 chain_anchor
asset_genesis
: describes the creation information of the asset, such as metadata hash value, input UTxO number, asset id
script_key
: Similar to the ScriptPubKey in the P2TR transaction, a witness script that meets the conditions is required to spend the UTxO representing the asset (as mentioned in the previous article UTxO*)
chain_anchor
: It describes the transaction information of the asset on the current anchored chain. It stores the transaction, transaction hash value, hash value of the block where the transaction is located, and the output UTxO of the asset transfer.
Similarly, in the genesis transaction ebe73fb60dfa99d191ed1e43a0509cc93c5223fa202656c469e01d6abfd66356, a corresponding output is generated, and the script that satisfies the output ScriptPubKey (via private key or path) is required to unlock this UTxO and use it for the next transaction. In addition, the next transaction also needs to meet the internal script_key requirements when used for Taro asset transfer.
The problem here is: how to ensure that this UTxO can be used normally to spend Taro assets? Perhaps the way to unlock the private key path can be removed by force (under P2TR, UTxO can be unlocked by private key or by entering a script), so that users can only spend Taro assets through the script path. Due to the limited information available, the solution to this part of the problem is not reflected. Perhaps this is also a problem that the Lightning Labs team is solving. As they said on the Github page: The current code does not support the operation of the main network, and it is very likely that users will lose Taro assets and UTxO containing BTC.
In addition, there is no relevant information available on the implementation details of the witness script. If you need a deeper understanding, you can only look through the source code, which takes more time, so I will not go into detail here.
Asset transfer
In Taro Asset, the transfer of assets requires the two parties to synchronize their universes. As mentioned in the previous article, Taro Universe stores the metadata of Taro assets and can be seen as a database that stores this series of transaction information. Transactions are only sent to Bitcoin when it is necessary to prove that these transactions and minting behaviors have actually occurred (this also seems to be a restriction mechanism, such as the discussion in the previous section on ensuring that UTxO must be spent as Taro assets). Therefore, before the transaction, both parties need to synchronize information to ensure the validity of the transaction. After that, sending Taro assets to another address will generate a transaction-like
transfer
information:
{
"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_passive_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_passive_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"
}
]
}
}
The user who mints the asset uses the UTxO corresponding to the anchored asset as input and generates two outputs to two addresses. The information in the outputs makes it easier for the recipient to verify whether the UTxO he received is legal. At the same time, the information in the outputs also provides the recipient with the information needed to generate the next transfer, so as to generate a legal witness script to ensure that the UTxO can be consumed normally. Combined with the previous description of the asset tree and the Taro asset transfer process,
asset_id
It can be used to index the leaf nodes representing assets in the asset tree. The leaf nodes also store the total amount of assets. This information is stored in Taro Universe, which can be regarded as an off-chain indexing program. Through script_key, the corresponding balances of these assets that can be spent can be queried in the MS-SMT of the corresponding assets. Wallets that meet the spendable conditions can use these outputs as inputs for the next transaction to conduct transactions.
The above "transfer" is a "division" process (100 -> <79, 21>), so the output type to itself is
OUTPUT_TYPE_SPLIT_ROOT
There is also a similar merge operation, which combines the assets under different script_keys that can be consumed by a wallet into one.
The operations involved in Taro Assets are only reflected in the form of a Pay-To-Taproot (P2TR) on the blockchain, and the main asset transfer process still occurs off-chain, so from this perspective, Taro Asset can be regarded as a second-layer network of Bitcoin.
Recent Progress
On the Taproot-Asset page, you can see that the currently implemented functions are:
Asset Minting
Taro Universe Synchronization
Send/Receive Assets
Import/Export Asset Proof
Creating and managing CLI configuration files
From the latest version v0.2.3, the Lightning Labs team is still fixing the legacy issues of the Taro program and improving the original program logic, such as adding the block height to the asset casting proof. And under the Github page of the program, it is also written that the code is not applicable to the main network, which may lead to the loss of Taro assets and BTC. Under the official discussion Slack, the developer also mentioned that the Lightning Network does not support Taro assets yet.
The v0.2.0 version that meets the requirements for asset casting was officially released in May this year. This version has realized the asset casting/transfer/receiving functions. The remaining part may be to refine the transaction rules (as mentioned above) and fix the bugs in the program. Therefore, Taro assets still have a long way to go. It currently cannot meet the requirements for running on the main network. The author believes that in the next one or two years, there may be hope to witness the official operation of Taro assets.
Extension: Atomicals Protocol
In the two weeks between the time I finished the previous article in this series and the time I wrote this article, another competitor of Ordinals emerged, Atomicals Protocol10. It is very similar to Ordinals Inscription in that it requires a commit transaction as input and writes an “envelope” in the witness script before revealing it. 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 homogeneous token based on the Atomic Protocol, and it has completely different minting and transfer rules from BRC-20.
Minting: ARC-20 minting also requires pre-deployment of tokens. The deployment method is to send transactions in Atomicals format. The deployment needs to specify the name of the token, the minting height, the associated image, the minting quantity and other information. After the indexer indexes it, others can obtain the token information through the indexer and mint it. ARC-20 also designs a mining-like minting method. The deployer can specify the collision prefix of commit tx and the collision prefix of reveal tx. If these prefix information are set, the minter needs to select a nonce to change the hash of commit tx and reveal tx to select a prefix that meets the conditions when minting (so far, there is no requirement for reveal tx collision, but the source code has this function). After the user finds a nonce that meets the conditions, the minting token name and the nonce that meets the conditions will be sent to the encoded atomic protocol transaction to the Bitcoin chain to complete the minting, and the balance information will be indexed by the indexer.
Transfer: The transfer of ARC-20 is very similar to that of colored coins, but much simpler. ARC-20 is bound to Satoshi. If the UTxO of these tokens is used as input, then the i-th input will flow to the i-th output. If there are not enough outputs, that is, the number of inputs is greater than the number of outputs, these tokens will flow to the first output.
Atomic Protocol
The benefit of this transfer method is that it avoids the process of minting transfer inscriptions before trading like BRC-20, making the transaction of homogeneous tokens more convenient. If partial signature technology is used, the exchange of tokens and BTC in a single transaction can be completed by integrating transactions, or even the exchange of multiple different tokens. The disadvantage is that such an implementation is too easy for users to lose tokens, especially when users receive multiple copies of the same token and integrate UTxO. These UTxOs representing tokens are very likely to be spent as gas, or even spent in the process of minting other tokens.
In addition, the Atomic Protocol also includes the design of NFT and domain names (independent of NFT). There are also unfinished contracts and events in the document. Due to the lack of official documents, it is impossible to continue to introduce them in depth.
Protocol Comparison
Here we need to compare Taro assets, Ordinals' BRC-20 tokens, and the Atomic Protocol. Their similarities are that the minting and transfer of tokens are tracked and recorded by off-chain programs, but the recording rules and their manifestation on the chain are not exactly the same.
Comparison of protocols
Conclusion
Finally, after introducing these technologies, let's discuss the possibility of Bitcoin implementation: In the common second-layer network implementation, a blockchain network is usually built to execute transactions, and then these executed proofs are placed in the main chain of Layer 1. This is also the basic principle of Rollup, and proofs are submitted to the main chain regularly. As a second-layer payment network of Bitcoin, the Lightning Network is implemented in a similar way to Rollup technology. After the channel is established, the two parties to the transaction conduct a series of interactions, and the channel is closed at the final confirmation, and then the proof is provided to the chain.
Taro Assets has designed a method similar to UTxO to complete the minting and transfer of assets. Its purpose may be to be compatible with the Lightning Network so that such an exchange mode can also take effect in the Lightning Network. Both parties only need to use a model similar to the Lightning Network to exchange assets, and finally need to submit a proof transaction when returning to Bitcoin to prove that these assets have been realized in the second-layer network. If the realization process of these assets is realized on Bitcoin, then it can be regarded as that each transaction has been submitted on Bitcoin to prove that the proof of assets under the chain is valid. However, this implementation method is extremely dependent on the Taro Universe index under the chain. If the metadata is lost, it is very likely to cause the loss of user assets. These indexes are very scattered. Perhaps these Universes can be formed into a P2P network to form a distributed storage similar to IPFS? The advantage of this is that it is convenient for users to circulate homogeneous token assets. The disadvantage is that non-homogeneous token assets are meaningless (as some people may ask, why not just use ERC721?).
BRC-20 violently records the minting and transfer data, and the indexer indexes the ledger information. Its shortcomings are obvious. Users need to engrave the transfer inscription before they can transfer, which is a condition that it must meet because it relies on Ordinals. If BRC-20 does not rely on Ordinals but designs a set of designs similar to Ordinals, it may be able to meet better liquidity, but it may not be able to take advantage of the popularity of Ordinals and become popular. Of course, the advantage of this is that the indexing method is very simple and there is no need to store too much additional metadata (compared to the metadata information stored by Taro assets), which also limits its scalability. As an NFT, Ordinals can perform very well. Its data is stored on the chain and can be indexed (although miners can discard this part of the witness data), which is different from ERC-721. Ordinals itself cannot be considered a second-layer network, but after the advent of BRC-20, it appears to be a second-layer network. However, changes in data are reflected on Bitcoin rather than in this second-layer network (indexer). It is only for the purpose of ensuring the accuracy of accounting.
It can be seen that Taro assets and Ordinals have their own highlights, especially in the implementation of homogeneous tokens and non-homogeneous tokens. Taro has considered a lot in the implementation of homogeneous tokens, considering Taproot to compress transactions, so that a large amount of assets can be exchanged in one transaction, and UTxO-type transactions to meet the compatibility of the Lightning Network. However, its implementation of NFT is particularly tasteless, compared with the Ordinals inscription, the on-chain data storage is different from ERC-721 and has become a highlight. The BRC-20 implemented by it is cumbersome in the user transaction process, and the interaction in Taro assets will not let users perceive all this. From this opposition, it is obvious that the difference between homogeneous tokens and non-homogeneous tokens can be felt, especially on a blockchain based on UTxO such as Bitcoin, the underlying design method adopted by the protocol is particularly important.
References
Colored Coins - wikipedia
bitcoin 2.X (aka Colored Bitcoin) – initial specs
Colored Coins whitepaper
NULL DATA - learn me a bitcoin
Coloring Scheme - Github
Overview - Handbook of Ordinal Number Theory
The rise of ORDINALS, the Cambrian explosion of BTC ecosystem
Bitcoin Stamps
Atomicals Protocol
Taproot Assets Protocol
Understanding Taproot Assets Protocol #2