“1” Ordinal Numbers
Many existing articles start with the Ordinals Protocol, but in the Ordinals official documentation, the first one mentions the Ordinal Numbers theory. From this, it can be deduced that Casey also drew some inspiration from it to create the Ordinals Protocol
As we all know, the smallest unit in the Bitcoin world is the satoshi (sat), and the Ordinal Numbers theory can simply be understood as artificially numbering these sat. From the motivations section of the BIP proposal, we can summarize that the theory wants to provide a way for Bitcoin to act as a stable identifier to prevent ownership transfers or key rotation, without requiring any changes to the Bitcoin network.
Of course, there are some objections to this theory, such as reducing user privacy, increasing the size of UTXO sets, dust attacks, etc. For details, see the BIP proposal.
“2” Ordinals Agreement
Proposal of an agreement
The Ordinals Agreement was proposed and published by Casey, in which he proposed the following ideas:
” Can we arrange these “Satoshi” in a certain order, assign them an ordinal number between 0 and 2,100,000,000,000,000, and then connect them to other information: images, text, videos, or even a string of code. As a result, every Satoshi became unique and irreplaceable. This is equivalent to giving Bitcoin its native ability to create NFTs.”
The Ordinals agreement was deployed at the end of 2022, and the first inscription on the mainnet was engraved on 2022.12.14 UTC (https://ordinalswallet.com/inscription/6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0), during which time the agreement was agreed It has always been updated and iterated but has not been officially announced. Currently, it can be updated from The first official announcement found on Casey’s Twitter is as follows, so the Ordinals agreement can be thought of as being proposed either in December or January: (Thanks also for the clue Shep provided)
Characteristics of the agreement
SAT numbers and the division of rarity
Humans are natural collectors. Since Ordinal Numbers artificially numbers the Sats, why don’t they give these SATs higher or lower, so there is a distinction between rarity. Currently, there are 6 types of rarity:
This rarity is similar to what we call “leopard banknotes”, “serial banknotes”, etc. when playing with banknotes in real life. Essentially, they are all banknotes. Their actual value is the face value of the note, but because people give it a special meaning, they have higher collectible value, and there is a premium, that is, what we often call “consensus generates value.”
While assigning a specific rule number to each sat and tracked in the transaction, the Ordinals Agreement also allows anyone to attach additional data such as images (Image), text (Text), video (Video), audio (Audio), etc. through the Ordinals Agreement. In the early days, players were more likely to create NFTs on it. Founder Casey’s initial position on it was also to let people store something immutable on Bitcoin, the oldest and most common chain. So for a while, many people will equate Ordinals with “Bitcoin NFTs.” Today, we can still see them in Unisat Wallet.
Trade first in, first out
In order to ensure that the sequential SAT with serial numbers is not chaotic during the transaction process, a first-in, first-out transaction method is used. Here is an example of Wang Yishi’s article (https://yishi.io/a-beginner-guide-to-the-ordinals-protocol/) to explain the characteristics of first in, first out:
In the image below, there are two inputs on the left. Address 1 and Address 2 have a total of 5 Satoshi. In this transaction, 4 Satoshi was sent to an address beginning with 3 OpZ, and 1 Satoshi was left to be paid to the miner as a miner fee.
Assuming that in the above transaction, we secretly used the Ord protocol to arrange an identity (serial number) for each Satoshi, then after the transaction was completed, the 4 numbered Satoshi Ord A- > D at address 1 and address 2 went to address 3, and the last Satoshi was given to the miner.
The so-called “first in, first out” means that each Satoshi number is ordered according to its index in the transaction output. For example, in the transaction output (Output) in the figure below, address 3 is ranked ahead of the miner address, then Satoshi transferred from address 1 and address 2 is first inherited by address 3, and then the miner address.
Protocol principles
Anyone familiar with Bitcoin knows that Bitcoin was born as a peer-to-peer electronic money system. The programming language it uses is not Turing’s complete scripting language, so it’s almost impossible to implement complex functions, and the two major updates of BTC in ‘17 and ‘21 made it possible to implement some functions involving complex logic on BTC.
Based on the development premise described above, the Ordinals Protocol achieved the effect of viewing and transferring by writing the content of its inscription into the Taproot script and using UTXO. Since Taproot scripting costs can only be made from existing Taproot Outputs, two stages (commit/reveal) are used to achieve engraving. First, in submitting a transaction, we need to create a Taproot Output with a script containing the content of the inscription, and secondly, in revealing the transaction, we need to spend the submitted transaction created earlier to reveal the content of the inscription on the chain. In this process, we also need to serialize the content of the inscription in a series of steps:
Well, to explain this in plain language, it’s equivalent to you initiating a WeChat transfer. During the transfer process, we need to indicate the content of the inscription you created in the comments (Taproot Output), and then send the transfer (spend to submit the transaction), so after the sending is complete, we can let the other party see what you wrote in the comment (reveal the transaction) in the chat box. If there is no comment on this transfer or the transaction is cancelled, the content of this inscription will not be uploaded to the link.
“1” Brc20 agreement
Proposal of an agreement
After the Ordinals protocol came out, early players were playing with NFTs, and anonymous developer domo released an experimental standard in 2023.3.8 — the BRC-20 protocol improved based on the Ordinals protocol and officially deployed the first BRC20 $ordi, which allows anyone to issue tokens on the Bitcoin network, similar to how to play ERC-20 tokens on Ethereum.
Notice:
domo’s earliest tweet about BRC-20 was 2023.3.9, but from Looking at the deployment time of $meme and $ordi, it should have been launched in 2023.3.8
$meme was the first BRC20 deployed, and $ordi was the first officially released BRC20, which can be inferred by looking at their deployment time
However, everyone should have experienced the development of $ordi. There isn’t much mention here. For details, please refer to the tweet below:
Protocol principles
The BRC-20 protocol establishes a series of standards to enable the deployment, minting, and transfer of BRC20 tokens based on the Ordinal theory. The protocol’s format standards are derived from the format of the Sats Name project (the first DID project based on the Ordinals protocol):
Also, to explain in plain language here, like the Ordinals Agreement, it is equivalent to you initiating a WeChat transfer, but the content of the notes is different.
extending
Although this method of the BRC-20 protocol enables the free issuance of homogenized tokens on the Bitcoin chain, because Bitcoin does not have an account model and the content of BRC-20 is placed in Segwit’s Taproot script, we are unable to directly calculate the BRC20 balance of each account on the chain. Therefore, the current method is to build an index server under the chain to achieve BRC20 token information acquisition, balance calculation, transaction transfer, etc., but there is a risk of centralization.
First, let’s first understand the three parts of the BTC layer protocol: the agreement stipulates the rules for writing data to Bitcoin, the indexer provides the ability to query and analyze this data, and the ledger records token balances and processes transfers.
For BRC20, the index server first needs to recognize every BRC20 deployment in order to read the token information, which is called the “index.”
At the same time, since BRC20 balances are all engraved into the script, the BTC network itself cannot recognize it, so the BRC20 index server must build a local ledger to record the BRC20 balance. Every time a transfer occurs, the local ledger needs to be checked and updated to see if the transaction can be carried out (there are enough coins).
Therefore, BRC20 needs to send two transactions during the transaction:
The first transaction reads the latest ledger data in the local ledger and calculates the balance
The second transaction is then transferred.
The Ordinals protocol is essentially designed for NFTs. Based on its improved BRC20, transfer complexity grows recursively. The BRC20 indexer also undertakes the work of a ledger. This ledger exists completely off-chain from Bitcoin. The indexer must accurately record every balance change to ensure the integrity of the ledger.
Therefore, as time is accumulated, indexer ledgers will accumulate, and the pressure on the nodes will increase. If the indexer is not continuously motivated, it will be difficult to sustain. If the indexer ledger is no longer in service, then BRC20 will be completely unusable.
“2” TRAC Systems
$TRAC
$TRAC is an BRC20 token launched by Benny on 2023.5.3 and officially deployed and launched on 2023.5.22.
Trac Core
Trac core is an oracle and decentralized indexer for Bitcoin inscriptions, which solves problems such as indexing, retrieving, and pricing of inscription ecological data.
For example, in terms of indexers, although the inscription data is stored on the Bitcoin chain, this is only information related to the inscription, and the data update and audit process requires a third-party centralized indexer, and security is always criticized (for example, Binance’s ordi index accounting error at the end of November). Therefore, Trac can make the inscription ecosystem inherit Bitcoin’s security to a greater extent, collect, organize, and sort all data on Bitcoin, and plans to introduce hundreds of indexer nodes in the future.
At the same time, as the number of nodes increases, Trac Core also integrates the role of oracles to obtain necessary reliable data from external sources to input the blockchain, which is the foundation for later building higher-level protocols such as inscribed native DeFi, and Trac’s API can be called for free.
As a result, Trac Core’s ecological card slot, which is both a decentralized indexer and a Bitcoin oracle, can be said to be ahead of most inscription projects.
Tap Protocol
Tap Protocol is an improved protocol based on Ordinals released by the $TRAC team on 2023.8.7. We can think of it as an upgraded version of the mirrored BRC20 protocol. It is a protocol that is compatible and upgraded to BRC20. It has the following 4 features:
Uses the previously deployed $TRAC as the governance token for its protocol (not very characteristic, but I’ll explain it here)
Currently, $TAP and $-TAP tokens have been officially released in Tap Protocol, of which $TAP was minted by BennyTheDev in 2023.8.6; $-TAP was opened to the community mint, with a total of 21,000,000 (or 21,000). According to Shep’s research, $-TAP was deployed 30 minutes earlier than $TAP, and is the real first native token in the protocol.
pipe
The Pipe protocol was proposed by $TRAC author Benny, which was an improvement on the Runes protocol. The Pipe agreement can be said to have snatched up the Runes agreement because the Runes agreement was proposed by Casey, the founder of the Ordinals agreement, but its main focus is on the Ordinals agreement, so the development of the Runes agreement has been slow, and Benny launched the Pipe agreement in just about a month after learning the ideas of the Runes agreement
The link between the three
At this point, we can see that Benny launched 3 projects in a row in less than half a year, and these 3 projects are also intertwined, the ultimate doll set. Let’s use the picture below to unravel the relationship between them.
Generally speaking, the governance tokens of a project are used as the native token of the agreement, and Benny can promote and restrict each other through this method of governance tokens, which is extremely rare. Currently, the specific functions of these governance tokens have not been officially announced, so we can see if this will have some exciting collisions in the next development.
“3” Atomicals agreement
Proposal of an agreement
The founder of the Atomicals Protocol tried to develop a DID project on the Ordinals Protocol in February, but during the development process, he discovered that the limitations of the Ordinals Protocol made some of the features he wanted impossible or a bit awkward. He tweeted his first idea about the Atomicals Protocol on 2023.5.29, and finally launched the agreement on 2023.9.17 after several months of development.
The initial launch of the Atomicals protocol didn’t stir up much water in the Bitcoin ecosystem because at the time, due to the introduction of the Ordinals Protocol and the BRC-20 protocol, a large number of improved protocols based on them emerged on different chains, but when we looked at the Atomicals protocol documentation, we found that it was a completely different protocol.
Theoretical Foundations — Digital Matter Theory (DMT)
DMT theory (Digital Matter Theory) refers to digital matter theory, which means that digital information is not just random numbers and letters; in fact, it can also be viewed as its own “matter,” such as wood or metal. DMT can be transactions, bytes, or any other pattern of blockchain data in blockchain data, and these patterns can be turned into valuable digital items or assets.
Here is also a quote of Dr. Jingle’s content for everyone to better understand:
Problems Existing Bitcoin Builders Face
The first three are questions for developers, and the last three are for creators
atomic theory
The Atomicals protocol is a simple and flexible protocol for minting, transferring, and updating digital objects (traditionally known as NFTs) for unspent transaction output (UTXO) blockchains such as Bitcoin.
1 ️ ︎ Digital objects — “atom” NFTs
Atomical (or “atom”) is a new type of NFT that can be minted, transferred, and updated on Bitcoin. The main difference is that there is no need to use a centralized service or a trusted third-party indexer. It doesn’t require any changes to Bitcoin to work, nor does it require sidechains or any L2. It’s time to take back control of our digital lives for good.
2 ️ ︎ BitWork — Micro Proof of Work PoW
The most interesting improvement to the Atomicals protocol is the addition of the CPU computation process to the token minting process, which is called BitWork. Founders need to exhaustively calculate hash values that match specific prefix characters before they can mint.
PoW can make coin minting relatively fair, with both energy and time value injections and random luck components.
Unlike traditional PoW algorithms, which are difficult to calculate, Bitwork can adjust the mining difficulty in a fine-grained manner by changing the prefix matching method. It can add numbers between 1 and 15 after the prefix, such as “7777.1” or “7777.15” Or any number in between, which indicates the range of variation that character is allowed to vary.
Its working principle is “.” The number that follows is called a half-wildcard and is used to match any 5th character starting from that number. With “7777.10” For example, the first 4 txid characters (hex) must be “7777,” and the 5th character can be a number 10 (hex) or more.
So the 5 digits can be a, b, c, d, e, or f. This allows the entire system to choose between 2 and 16 times instead of only 16 times each time the difficulty increases.
At the same time, BitWork also brought some novel use cases:
3 ️ ︎ Container NFTs — The NFT Standard
Container (Container) is a collection standard for representing NFTs and metadata. It can be used to add/modify/delete the content of any agreement such as Atomicals, Ordinals, Bitmaps, etc., and you can also choose permanent “sealing”, that is, locking the content in a container and then destroying the “key” that can open the container, thus achieving the goal of maintaining the state it was in when sealed and cannot be modified.
Container name service:
4 ️ ECT ARC20 — Dyed Coin
The Atomicals protocol uses the smallest unit of Bitcoin, sat as the basic “atom”. The UTXO of each sat is used to represent the token itself, that is, the balance of ARC20 is the number of sat. 1 token = 1 sat.
ARC20 is a dyed coin model, and registration information is recorded in a transaction script. By binding the information to UTXO, the programmability and decentralization of the token can be improved. At the same time, the security of the transaction is guaranteed by the BTC main network. There is no need for any off-chain system to calculate the balance of ARC20 tokens in terms of tracking transactions and calculating balances, because the token balance is consistent with the number of SATs in UTXO. This is the biggest difference from the BRC-20 protocol.
When deploying ARC20, information such as token name, total amount, quantity limit, difficulty settings, starting block, images, etc.
2. When users mint ARC20, they write the name of the token into the UTXO script. The amount is directly determined by the number of sats in UTXO, 1 sat = 1 token.
3. To transfer ARC20, users no longer need to deposit any data into BTC; they only need to use UXTO, which continues to hold tokens, as transaction input and output to other addresses.
For ARC20, we only need an index to help us read token registration information and identify mint transactions to confirm which UTXO is ARC20.
The benefits of this are:
Of course, the design of dyed coins also has some disadvantages, because the balance is not written into the data, but rather the sat is bound, so the minimum split accuracy of the ARC20 balance is 1.
This also makes it impossible for users to make fine-grained transactions under the BTC mainnet itself, which has set a minimum transaction limit of 546 sat to prevent dust attacks. However, the Atomicals protocol has now proposed a specific split plan and is being actively developed.
Here’s a picture to show the most essential difference between BRC20 and ARC20:
5 ️ ︎ Realm Name System (RNS) — Domain Domain Name System
RNS claims to be the real rival of the DNS domain name system and aims to be a global replacement for DNS and other blockchain domain name systems
Realm Names are human-readable identifiers that can be used to correlate network addresses and resource information. Realm names begin with a plus sign + and have at least one alphabetic character, such as +alice and +agent007, which are all valid names (top-level — domain or TLR in the Realm Domain Name System (RNS)).
The domain name is self-owned and self-managed directly on the Bitcoin blockchain using an atomic digital object format, which basically means there are no intermediaries or centralized registrars.
6 ️ ︎ Subrealm Minting — Subdomain Foundry
Manage and tokenize communities by issuing subrealms (Subrealms) under any realm (Realm). The specific rules are as follows:
Here’s a generic example:
In addition to that, Subrealm can also be used for social media organization, identity verification, loyalty rewards, and more.
Characteristics of the agreement
Through the atomic theory above, we can see that the main features of the Atomicals protocol include:
Key differences from other agreements
The best way to understand the differences in the Atomicals protocol is to compare it to other popular NFT protocols:
“4” Bitmap protocol
Proposal of an agreement
Bitmap.land is the first metaverse project in the Bitcoin ecosystem, based on ordinals theory (Ordinals theory) and bitmap theory (Bitmap theory).
Bitmap theory (Bitmap theory) was proposed by Twitter user @blockamoto on 2023.6.5.
This theory maps each transaction input in a Bitcoin block as a parcel (Parcel) to form a block or district (district). Due to differences in the size of the different transaction inputs, the mapped lot size is also different.
Agreement concept
Bitmap.land buyers were influenced by Decentraland and The Sandbox and used the method of dividing land and drawing patterns on a map, similar to the land buying logic on these two platforms. Users write data to Satoshi through inscriptions to obtain ownership of specific Bitcoin blocks, similar to free minting.
On the Bitcoin blockchain, each block is divided into four parts to represent different halving cycles. Users can check the number and color of each block on the Bitmap.land website. Different colors represent different sales states.
Bitmap.land’s sale is closely related to ordinal number theory, similar to Decentraland and The Sandbox’s virtual land sale, which relies on ERC-721 standards. The ordinal number theory is similar to the principles of early dyed coins, but the two are different in the context of Bitcoin’s current narrative, consensus, ecology, and infrastructure. Although ordinal number theory isn’t as innovative as ERC-721, BRC-20’s approach is more primitive.
Bitmap theory adds a new explanation to the Bitcoin block, providing a topical, albeit lacking in utility. It changed the connection between Bitcoin and the metaverse, giving every block of the Bitcoin blockchain a new dimension and making it part of the metaverse by allowing users to own and record individual blocks.
The bitmap theory attracted the attention of the Ordinals community and sparked a boom in inscriptions. Any block on the Bitcoin blockchain can become part of the metaverse through a Bitmap, bringing new opportunities for creation and ownership to the community.
Bitmap.land blurs the boundaries between Bitcoin and the metaverse through bitmap theory, paving the way for ownership, creativity, and community development. As the inscription craze continues, it means huge potential for those seeking a place in the digital world.
“5” BRC-100 protocol
Proposal of an agreement
As we all know, Bitcoin-based protocols such as Ordinals Protocol and BRC-20 have brought a lot of room for imagination to the development of the Bitcoin ecosystem through an “on-chain declaration and off-chain analysis” mechanism. Also, a large number of Bitcoin NFTs and tokens have been issued, but the development of decentralized applications such as DeFi is still lagging behind. As a result, Mikael.BTC released a protocol supporting decentralized computing: BRC-100 on 2023.9.2.
Introduction to the agreement
BRC-100 is an extension protocol based on Ordinals theory, designed to implement various decentralized applications on Bitcoin Layer 1. This agreement not only undertakes the basic functions of BRC-20 on Bitcoin, such as creation, minting, and trading, but also introduces the concept of decentralized computing.
This means that based on the BRC-100 protocol stack, it is possible to develop various decentralized applications such as DeFi, SocialFi, and GameFi, bringing true decentralized, trustless, censorship-resistant and permissionless application scenarios to the first layer of Bitcoin.
One of the major features of the BRC-100 protocol is its interoperability, which not only allows all protocols and applications within its protocol stack to be compatible with each other, but also supports interaction with BTC, BRC-20, or other layer 1 chains such as Ethereum and Stacks. Additionally, the protocol introduced a UTXO model and a state machine model, enhancing its security and computational capabilities.
Characteristics of the agreement
Because the BRC-100 protocol is an extension of the Ordinals theory, the BRC-100 itself has all the features of BRC-20, while also introducing some innovative features:
Saving money: It is based on the BRC-100 protocol for various expansions such as airdrop agreements, governance agreements, relay agreements, etc. We can understand that Mikael wants to introduce various DeFi gameplay into BTC
Protocol succession
The BRC-100 protocol introduces the concept of inheritance. Protocols that directly or indirectly inherit from BRC-100 are called BRC-100 extension protocols. The BRC-100 extension protocol must inherit from only one protocol. An extended agreement inherits the properties, operations, and computation operations of the parent agreement, and can only extend the properties and computational operations.
This is similar to when we make ceramics, at the beginning it was just a clay embryo. Slowly, as we polish and shape it, we gradually have more expanded functions such as decorating, storing things, etc.
BRC-100 protocol stack
The BRC-100 protocol and all of its extensions and improvements are collectively known as the BRC-100 stack. Based on this stack, all tokens/applications are compatible with each other, which means that one token/application can use other applications anywhere.
Agreements and applications
In the BRC-100 protocol stack, a protocol is a standard for describing the properties, operations, and computational operations of an application. An application is an instance created after the protocol was deployed to the Bitcoin network via an inscription.
An app is essentially a token with computational power and status. The computing power of the application is described in detail in the protocol. If you don’t add a sub-application, the application cannot have computing power not described in the agreement. The added sub-application can also only have the computing power of the protocol; otherwise, the public indexer cannot verify the state of the application, causing the state of the user and application to be inconsistent.
Application nesting
Applications deployed based on BRC-100 and its extended protocols can be nested, that is, under one application, another application can be created, called a sub-application.
The child application’s ticker starts with “parent application ticker:”. Multiple applications can be created under one application to complete multiple independent calculation logic. For example, in the classic AMM DEX scenario, multiple LP sub-apps/tokens, such as “amm_dex: LP_BRC100_BTC”, need to be created within a DEX application.
App status and address
In addition to the UTXO model, the BRC-100 protocol also introduces a state machine model to expand the computational capabilities of the protocol.
Applications, sub-applications, and addresses can all have states. For example, apps can hold tokens, and addresses can hold balances within apps. The UTXO and state transitions are done with the burn2/burn3 and mint2/mint3 instructions.
Computational operations (cop) are used to represent specific computational logic, that is, application and address state transformation logic.
For example, address A destroys 10 token1 to the application via the burn3 inscription. At this point, the application has this UTXO and 10 token1. The application can allocate these 10 token1 through its computational logic by altering any address or the internal state of the application. Then the address of token1 in the app or the app can mint it with the mint3 command.
Permissions
The BRC-100 protocol introduces two roles: owner and administrator.
The address with the application deployment inscription is called the owner. Owners can track UTXO transfers with deployment inscriptions. The owner of all child apps is the owner of the parent app.
Administrators are managed by the owner, and administrators cannot manage other administrators. Owners’ and admins’ rights are strictly limited. They can’t vet users; they can only do: manage apps that haven’t launched DAO and complete mint2/burn2 computational operations.
An administrator can be an address, application, or sub-application. By default, the application and the sub-application are each other’s administrators; no additional settings are required, but the sub-apps are not each other’s administrators.
The burn2/burn3 inscription needs to be sent to the app’s deployer for proper processing.
Some of the tokens that the “mint2” instruction needs to be minted can only be logically allocated by the app/sub-application, and the app/sub-application needs to be the token administrator. The “burn2” instruction also has similar logic.
The burn2/burn3 inscription needs to be sent to the application’s deployer for proper processing according to the logic of the computational operation.
Decentralized governance of applications
The BRC-100 protocol stack introduces a governance protocol: BRC-101, which governs applications that implement BRC-100 or its extended protocol standards. Once the app launches the DAO, it needs to complete governance through decentralized voting.
Application governance includes updating application and sub-application properties, deploying sub-applications, and stopping applications. Application governance is on-chain governance. Once the on-chain vote passes, the app should be notified through computational action: egov, then the app will automatically perform governance after the time is locked.
Deploy applications/tokens
In the BRC-100 protocol, there are two ways to deploy applications: one is to deploy directly using deployment instructions, and the other is to deploy through the governance protocol, BRC-101.
The first one is used to deploy parent and child applications that do not require the configuration of governance, and the other is used to deploy child applications that require governance.
Minting tokens
The BRC-100 protocol provides three minting instructions: mint, mint2, and mint3, for minting tokens in different scenarios.
When deploying an application, you need to set the number of tokens users can mint (using the “mint” command). The remaining tokens will also be minted using the “mint” instructions.
“Mint”: User mints, fair mints, anyone can mint tokens for users, but the total number of “mint” operators minting cannot exceed the settings of the application’s “max” and “mma” attributes. After minting, the circulating supply of tokens will increase.
“mint2”: whitelist minting, the app records the number of users or apps that can be minted, and anyone can mint2 tokens for the user or app under the app rules. After mint2, the circulating supply of tokens will also increase.
“mint3”: Mint3 is treasury minting. mint3 is the balance of users or apps in other apps. Anyone can apply mint3 tokens for users or apps under application rules. After mint3, the circulating supply of tokens will not increase.
Destroy tokens
Destroy is a new operation introduced in the BRC-100 protocol. Users can engrave the destroy operation and then transfer the inscription to the application’s deployer, which is similar to the semantics of the transfer operation. The burned tokens will then be destroyed or transferred to the app’s balance.
Similar to the definition of a mint operation, there are 3 burn operators: burn, burn2, and burn3, which logically correspond to mint, mint2, and mint3 respectively. No additional configuration is required, and all apps/tokens support these three burn instructions.
“Burn”: Public burn, where everyone can use instructions to destroy tokens. Once the token is successfully destroyed, circulation will decrease, and the destroyed token cannot be minted again.
“burn2”: The whitelist is destroyed. According to the rules set by the application, after burn2 tokens are transferred to the application, the user’s balance will decrease, the application status will be updated accordingly, and circulation will decrease. In reality, logic such as removing liquidity in AMM DEX can be implemented through burn2.
“Burn3”: The treasury is destroyed. Burn3 will reduce the user’s token balance and increase the balance of the “to” application. In actual applications, it is possible to cooperate with mint3 to complete the logic of exchanging tokens and increasing liquidity in AMM DEX.
Transaction taxes and deflation
The BRC-100 agreement introduced a new mechanism for trading tokens: transaction taxes and deflation. Applications can set transaction tax percentages, tax recipients, and transaction black hole percentages. These settings only take effect when trading on AMM-based decentralized exchanges. Normal transfers, minting, and destruction operations do not incur transaction taxes or deflation.
Computational operations
Computational operations are extended computational behaviors of the BRC-100 protocol. It is represented by the cop attribute and is the smallest unit of computational power of the protocol. When used with the op operator: burn2/burn3/mint2/mint3, it can be understood as a state transition function, which defines how the state of the application and user is updated under the corresponding op operator.
Oracle oracles
Oracle is a common requirement for blockchain to interact with all parties under the chain, and has been well implemented and applied on blockchains such as Ethereum. Without oracles, smart contracts on the blockchain would be entirely limited to on-chain data. However, compared to blockchain, the BRC-100 protocol has very special characteristics.
It not only has the computing power of the blockchain, but also relies on an off-chain indexer to complete the calculation. At the same time, off-chain indexers can directly communicate with other blockchains or meta-protocols, but blockchains cannot do this, which means that the indexer can verify that any data off-chain or on-chain meets the requirements of the Oracle BRC-100 protocol.
Examples: verifying the transfer of BTC or BRC-20 assets, verifying the price of ETH on an Ethereum block, etc.
In other words, in the BRC-100 protocol, oracles have a new paradigm: attestation and verification, where users submit attestation data, and the indexer acts as an Oracle Verifier to verify user-submitted attestation data outside of the agreement, without the need for a separate Oracle service.
In the BRC-100 protocol, the burn2/burn3/mint2/mint3 instructions natively support proof attributes for submitting proof data outside of the protocol. The indexer can verify certification data and ensure the consistency and accuracy of the status. The proof can be transfer proof, Merkel tree proof, zero-knowledge proof, price proof, etc., and can be used to bridge scenarios such as assets, airdrops, etc., and can be used to bridge scenarios such as Bitcoin layer 2, loan settlement, etc.
relay protocol
The meta-protocol on Bitcoin is heterogeneous and cannot communicate with each other. Different protocols are similar to different blockchains; they share the security of the Bitcoin blockchain and have different computational capabilities. Furthermore, meta-protocols cannot directly communicate with other blockchains: Ethereum, for example, cannot use assets on other blockchains.
Therefore, the BRC-100 protocol stack requires a relay protocol to complete communication between Bitcoin, meta-protocol, blockchain and the BRC-100 protocol, bridge assets on other protocols or blockchains to BRC-100, and participate in decentralized applications such as DeFi. Meanwhile, due to the diversity of protocols and blockchains, BRC-100 will have multiple relay protocols.
First, we’ll be releasing: BRC-103, which is responsible for bridging assets between Bitcoin, BRC-20, and BRC-100.
When an asset is bridged from the meta-protocol or blockchain (source) to the BRC-100 protocol (target), in order for the indexer to verify the correctness of the transmission, it is necessary to submit proof of transmission data using the “mint2” command, which is called proof of transmission.
Proof of transfer means that when an anchored asset is minted on the target protocol (BRC-100), transfer data from the source side (such as Bitcoin, BRC-20, or other blockchain) must also be submitted as proof. This can be a transaction hash or inscription ID.
So that all BRC-100 indexers can verify the correctness of the minting of the anchored assets.
Transfer Proof is a very important application of Oracle’s BRC-100 protocol.
Protocol use cases
Since BRC-100 was extended from BRC-20, it essentially has all the application scenarios of BRC-20, but the application scenarios of BRC-100 are far more than that. We can still expand on the basis of the BRC-100 protocol. Here are some of the official extensions listed, some of which are already under development:
BRC-101 (released)
The BRC-100 protocol stack’s decentralized on-chain governance protocol defines how to update the attributes of parent/child applications/tokens, stop applications, and add child applications.
Additionally, BRC-101 can also complete off-chain governance through decentralized voting.
BRC-102 (in development)
An automated liquidity protocol defines how to exchange tokens for the BRC-100 protocol stack through an automated market maker (AMM) algorithm. The calculation logic will be similar to Uniswap on Ethereum.
BRC-103 (in development)
A relay protocol between BTC, BRC-20, and BRC-100. The meta-protocol on Bitcoin is heterogeneous and unable to communicate with each other. Different protocols are similar to different chains. They share the security of the Bitcoin blockchain and have different computing power.
Therefore, the BRC-100 protocol stack will publish multiple relay protocols to complete communication between meta-protocols, different chains, and BRC-100, and bridge other protocols and on-chain assets to BRC-100 to participate in DApps such as DeFi.
BRC-104
Liquidity mining agreements define how to obtain token rewards after staking tokens.
A staking token can be any BRC-100 based token, such as the BRC-103 protocol’s liquidity pool token, or the same token as a reward token. Additionally, BRC-104 will support locking staked tokens during the lockdown period.
BRC-105
An airdrop protocol defines how to efficiently airdrop tokens to multiple addresses.
The protocol will use Merkle Tree to complete the airdrop to save on transaction fees since all of the original airdrop data does not need to be made public on Bitcoin. Users only need to submit Merkle Proof to prove that they own the airdrop during “mint2”, then all indexers can verify the correctness to complete the airdrop.
BRC-106
A decentralized stablecoin pool protocol defines how stablecoins are generated through collateral.
The computational logic will be similar to MakerDAO3’s DAI on Ethereum.
BRC-107
A loan pool agreement defines how assets can be borrowed through collateral.
The computational logic will be similar to Aave on Ethereum.
BRC-108
An automated liquidity protocol for stablecoins.
BRC-109
Decentralized trading protocol for perpetual futures.
BRC-110
A relay protocol between EVM compatible blockchains and BRC-100 defines how assets on EVM compatible blockchains can be bridged to BRC-100.
BRC-111
Bitcoin’s layer 2 verification protocol defines how to verify Bitcoin’s layer 2 proof data like a layer 2 smart contract on Ethereum.
“6” BRC-420 protocol
Proposal of an agreement
After the BRC-20 protocol was proposed, another new experimental protocol called BRC-420, also known as the metaverse protocol, appeared on 2023.9.19.
Agreement concept
BRC-420 is an interesting experiment. It is the first metaverse protocol in the Ordinals Protocol, an asset protocol based on the Bitmap protocol.
By combining multiple inscriptions into one complex asset, such as game items, animations, and effects, or game modules in the metaverse. Everything from small characters and pets to full game scripts and virtual machines has been created.
Due to their on-chain open source nature, these assets can be run or verified by any client, fully reflecting the “Client Agnostic” spirit of full-chain games.
The BRC-420 agreement consists of two parts: the Metaverse Standard (Metaverse Standard), which defines an open format for assets in the metaverse, and the Royalty Standard (royalty standard), which establishes an on-chain agreement for the creator economy.
BRC-420 opens up possibilities for Ordinals’ on-chain gaming and modular blockchains. Different creators can contribute different modules, and new creators can build on the innovation of their predecessors. This has led to a proliferation of innovations within the Ordinals ecosystem, benefiting all participants.
Agreement development
Currently, BRC-420 released the BRC-420 DLC on 2023.11.3, which can integrate thousands of meta inscriptions into 1 DLC. After deployment, users can get thousands of meta-assets in a single minting.
“7” Runes agreement
Proposal of an agreement
After the BRC20 protocol came out, Casey felt that it was not a good idea to create homogenized tokens on Bitcoin. 99% of homogenized tokens are scams and won’t disappear in the short term. Creating a good homogenized token protocol for Bitcoin is likely to bring Bitcoin significant transaction fee revenue, developer attention, and users.
Casey therefore proposed the Runes protocol based on UTXO technology on 2023.9.26.
The design of the Runes protocol may also have been affected by ARC20. The choice was to write token data directly into the UTXO script, which includes the ID, output, and quantity of tokens.
Obviously, Runes’ implementation is very similar to ARC20, and token transfers are handled directly to the BTC mainnet. The difference is that Runes writes the number of tokens in the script data, which makes him more accurate than ARC20.
At the same time, however, the complexity has also increased, making it difficult to directly utilize the combinatorial nature of BTC UTXO like ARC20.
Agreement development
Since the launch of the Runes agreement, since Casey’s development effort was mainly on the Ordinals protocol, the development of the Runes protocol has been slow, which is why Benny quickly overtook corners and developed the Pipe protocol after the release of the Runes agreement.
During Taiwan Blockchain Week in December, Casey also announced at an event in Taipei that the Runes Protocol will launch on the main network. At the block height of 840,000, that is, the next time BTC is halved, it will probably be at the end of April 2014.
After researching the BTC asset issuance plan, I also fully felt their charm, so I also mentioned some of my own subjective opinions:
Finally, thank you for reading this article. The original purpose of this article is to give you a better and more comprehensive understanding of the development of the BTC ecosystem, and you are also welcome to come and talk to me. In the next few days, I will post some opinions from time to time, and I will also write another article on the expansion plan, so stay tuned.
“1” Ordinal Numbers
Many existing articles start with the Ordinals Protocol, but in the Ordinals official documentation, the first one mentions the Ordinal Numbers theory. From this, it can be deduced that Casey also drew some inspiration from it to create the Ordinals Protocol
As we all know, the smallest unit in the Bitcoin world is the satoshi (sat), and the Ordinal Numbers theory can simply be understood as artificially numbering these sat. From the motivations section of the BIP proposal, we can summarize that the theory wants to provide a way for Bitcoin to act as a stable identifier to prevent ownership transfers or key rotation, without requiring any changes to the Bitcoin network.
Of course, there are some objections to this theory, such as reducing user privacy, increasing the size of UTXO sets, dust attacks, etc. For details, see the BIP proposal.
“2” Ordinals Agreement
Proposal of an agreement
The Ordinals Agreement was proposed and published by Casey, in which he proposed the following ideas:
” Can we arrange these “Satoshi” in a certain order, assign them an ordinal number between 0 and 2,100,000,000,000,000, and then connect them to other information: images, text, videos, or even a string of code. As a result, every Satoshi became unique and irreplaceable. This is equivalent to giving Bitcoin its native ability to create NFTs.”
The Ordinals agreement was deployed at the end of 2022, and the first inscription on the mainnet was engraved on 2022.12.14 UTC (https://ordinalswallet.com/inscription/6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0), during which time the agreement was agreed It has always been updated and iterated but has not been officially announced. Currently, it can be updated from The first official announcement found on Casey’s Twitter is as follows, so the Ordinals agreement can be thought of as being proposed either in December or January: (Thanks also for the clue Shep provided)
Characteristics of the agreement
SAT numbers and the division of rarity
Humans are natural collectors. Since Ordinal Numbers artificially numbers the Sats, why don’t they give these SATs higher or lower, so there is a distinction between rarity. Currently, there are 6 types of rarity:
This rarity is similar to what we call “leopard banknotes”, “serial banknotes”, etc. when playing with banknotes in real life. Essentially, they are all banknotes. Their actual value is the face value of the note, but because people give it a special meaning, they have higher collectible value, and there is a premium, that is, what we often call “consensus generates value.”
While assigning a specific rule number to each sat and tracked in the transaction, the Ordinals Agreement also allows anyone to attach additional data such as images (Image), text (Text), video (Video), audio (Audio), etc. through the Ordinals Agreement. In the early days, players were more likely to create NFTs on it. Founder Casey’s initial position on it was also to let people store something immutable on Bitcoin, the oldest and most common chain. So for a while, many people will equate Ordinals with “Bitcoin NFTs.” Today, we can still see them in Unisat Wallet.
Trade first in, first out
In order to ensure that the sequential SAT with serial numbers is not chaotic during the transaction process, a first-in, first-out transaction method is used. Here is an example of Wang Yishi’s article (https://yishi.io/a-beginner-guide-to-the-ordinals-protocol/) to explain the characteristics of first in, first out:
In the image below, there are two inputs on the left. Address 1 and Address 2 have a total of 5 Satoshi. In this transaction, 4 Satoshi was sent to an address beginning with 3 OpZ, and 1 Satoshi was left to be paid to the miner as a miner fee.
Assuming that in the above transaction, we secretly used the Ord protocol to arrange an identity (serial number) for each Satoshi, then after the transaction was completed, the 4 numbered Satoshi Ord A- > D at address 1 and address 2 went to address 3, and the last Satoshi was given to the miner.
The so-called “first in, first out” means that each Satoshi number is ordered according to its index in the transaction output. For example, in the transaction output (Output) in the figure below, address 3 is ranked ahead of the miner address, then Satoshi transferred from address 1 and address 2 is first inherited by address 3, and then the miner address.
Protocol principles
Anyone familiar with Bitcoin knows that Bitcoin was born as a peer-to-peer electronic money system. The programming language it uses is not Turing’s complete scripting language, so it’s almost impossible to implement complex functions, and the two major updates of BTC in ‘17 and ‘21 made it possible to implement some functions involving complex logic on BTC.
Based on the development premise described above, the Ordinals Protocol achieved the effect of viewing and transferring by writing the content of its inscription into the Taproot script and using UTXO. Since Taproot scripting costs can only be made from existing Taproot Outputs, two stages (commit/reveal) are used to achieve engraving. First, in submitting a transaction, we need to create a Taproot Output with a script containing the content of the inscription, and secondly, in revealing the transaction, we need to spend the submitted transaction created earlier to reveal the content of the inscription on the chain. In this process, we also need to serialize the content of the inscription in a series of steps:
Well, to explain this in plain language, it’s equivalent to you initiating a WeChat transfer. During the transfer process, we need to indicate the content of the inscription you created in the comments (Taproot Output), and then send the transfer (spend to submit the transaction), so after the sending is complete, we can let the other party see what you wrote in the comment (reveal the transaction) in the chat box. If there is no comment on this transfer or the transaction is cancelled, the content of this inscription will not be uploaded to the link.
“1” Brc20 agreement
Proposal of an agreement
After the Ordinals protocol came out, early players were playing with NFTs, and anonymous developer domo released an experimental standard in 2023.3.8 — the BRC-20 protocol improved based on the Ordinals protocol and officially deployed the first BRC20 $ordi, which allows anyone to issue tokens on the Bitcoin network, similar to how to play ERC-20 tokens on Ethereum.
Notice:
domo’s earliest tweet about BRC-20 was 2023.3.9, but from Looking at the deployment time of $meme and $ordi, it should have been launched in 2023.3.8
$meme was the first BRC20 deployed, and $ordi was the first officially released BRC20, which can be inferred by looking at their deployment time
However, everyone should have experienced the development of $ordi. There isn’t much mention here. For details, please refer to the tweet below:
Protocol principles
The BRC-20 protocol establishes a series of standards to enable the deployment, minting, and transfer of BRC20 tokens based on the Ordinal theory. The protocol’s format standards are derived from the format of the Sats Name project (the first DID project based on the Ordinals protocol):
Also, to explain in plain language here, like the Ordinals Agreement, it is equivalent to you initiating a WeChat transfer, but the content of the notes is different.
extending
Although this method of the BRC-20 protocol enables the free issuance of homogenized tokens on the Bitcoin chain, because Bitcoin does not have an account model and the content of BRC-20 is placed in Segwit’s Taproot script, we are unable to directly calculate the BRC20 balance of each account on the chain. Therefore, the current method is to build an index server under the chain to achieve BRC20 token information acquisition, balance calculation, transaction transfer, etc., but there is a risk of centralization.
First, let’s first understand the three parts of the BTC layer protocol: the agreement stipulates the rules for writing data to Bitcoin, the indexer provides the ability to query and analyze this data, and the ledger records token balances and processes transfers.
For BRC20, the index server first needs to recognize every BRC20 deployment in order to read the token information, which is called the “index.”
At the same time, since BRC20 balances are all engraved into the script, the BTC network itself cannot recognize it, so the BRC20 index server must build a local ledger to record the BRC20 balance. Every time a transfer occurs, the local ledger needs to be checked and updated to see if the transaction can be carried out (there are enough coins).
Therefore, BRC20 needs to send two transactions during the transaction:
The first transaction reads the latest ledger data in the local ledger and calculates the balance
The second transaction is then transferred.
The Ordinals protocol is essentially designed for NFTs. Based on its improved BRC20, transfer complexity grows recursively. The BRC20 indexer also undertakes the work of a ledger. This ledger exists completely off-chain from Bitcoin. The indexer must accurately record every balance change to ensure the integrity of the ledger.
Therefore, as time is accumulated, indexer ledgers will accumulate, and the pressure on the nodes will increase. If the indexer is not continuously motivated, it will be difficult to sustain. If the indexer ledger is no longer in service, then BRC20 will be completely unusable.
“2” TRAC Systems
$TRAC
$TRAC is an BRC20 token launched by Benny on 2023.5.3 and officially deployed and launched on 2023.5.22.
Trac Core
Trac core is an oracle and decentralized indexer for Bitcoin inscriptions, which solves problems such as indexing, retrieving, and pricing of inscription ecological data.
For example, in terms of indexers, although the inscription data is stored on the Bitcoin chain, this is only information related to the inscription, and the data update and audit process requires a third-party centralized indexer, and security is always criticized (for example, Binance’s ordi index accounting error at the end of November). Therefore, Trac can make the inscription ecosystem inherit Bitcoin’s security to a greater extent, collect, organize, and sort all data on Bitcoin, and plans to introduce hundreds of indexer nodes in the future.
At the same time, as the number of nodes increases, Trac Core also integrates the role of oracles to obtain necessary reliable data from external sources to input the blockchain, which is the foundation for later building higher-level protocols such as inscribed native DeFi, and Trac’s API can be called for free.
As a result, Trac Core’s ecological card slot, which is both a decentralized indexer and a Bitcoin oracle, can be said to be ahead of most inscription projects.
Tap Protocol
Tap Protocol is an improved protocol based on Ordinals released by the $TRAC team on 2023.8.7. We can think of it as an upgraded version of the mirrored BRC20 protocol. It is a protocol that is compatible and upgraded to BRC20. It has the following 4 features:
Uses the previously deployed $TRAC as the governance token for its protocol (not very characteristic, but I’ll explain it here)
Currently, $TAP and $-TAP tokens have been officially released in Tap Protocol, of which $TAP was minted by BennyTheDev in 2023.8.6; $-TAP was opened to the community mint, with a total of 21,000,000 (or 21,000). According to Shep’s research, $-TAP was deployed 30 minutes earlier than $TAP, and is the real first native token in the protocol.
pipe
The Pipe protocol was proposed by $TRAC author Benny, which was an improvement on the Runes protocol. The Pipe agreement can be said to have snatched up the Runes agreement because the Runes agreement was proposed by Casey, the founder of the Ordinals agreement, but its main focus is on the Ordinals agreement, so the development of the Runes agreement has been slow, and Benny launched the Pipe agreement in just about a month after learning the ideas of the Runes agreement
The link between the three
At this point, we can see that Benny launched 3 projects in a row in less than half a year, and these 3 projects are also intertwined, the ultimate doll set. Let’s use the picture below to unravel the relationship between them.
Generally speaking, the governance tokens of a project are used as the native token of the agreement, and Benny can promote and restrict each other through this method of governance tokens, which is extremely rare. Currently, the specific functions of these governance tokens have not been officially announced, so we can see if this will have some exciting collisions in the next development.
“3” Atomicals agreement
Proposal of an agreement
The founder of the Atomicals Protocol tried to develop a DID project on the Ordinals Protocol in February, but during the development process, he discovered that the limitations of the Ordinals Protocol made some of the features he wanted impossible or a bit awkward. He tweeted his first idea about the Atomicals Protocol on 2023.5.29, and finally launched the agreement on 2023.9.17 after several months of development.
The initial launch of the Atomicals protocol didn’t stir up much water in the Bitcoin ecosystem because at the time, due to the introduction of the Ordinals Protocol and the BRC-20 protocol, a large number of improved protocols based on them emerged on different chains, but when we looked at the Atomicals protocol documentation, we found that it was a completely different protocol.
Theoretical Foundations — Digital Matter Theory (DMT)
DMT theory (Digital Matter Theory) refers to digital matter theory, which means that digital information is not just random numbers and letters; in fact, it can also be viewed as its own “matter,” such as wood or metal. DMT can be transactions, bytes, or any other pattern of blockchain data in blockchain data, and these patterns can be turned into valuable digital items or assets.
Here is also a quote of Dr. Jingle’s content for everyone to better understand:
Problems Existing Bitcoin Builders Face
The first three are questions for developers, and the last three are for creators
atomic theory
The Atomicals protocol is a simple and flexible protocol for minting, transferring, and updating digital objects (traditionally known as NFTs) for unspent transaction output (UTXO) blockchains such as Bitcoin.
1 ️ ︎ Digital objects — “atom” NFTs
Atomical (or “atom”) is a new type of NFT that can be minted, transferred, and updated on Bitcoin. The main difference is that there is no need to use a centralized service or a trusted third-party indexer. It doesn’t require any changes to Bitcoin to work, nor does it require sidechains or any L2. It’s time to take back control of our digital lives for good.
2 ️ ︎ BitWork — Micro Proof of Work PoW
The most interesting improvement to the Atomicals protocol is the addition of the CPU computation process to the token minting process, which is called BitWork. Founders need to exhaustively calculate hash values that match specific prefix characters before they can mint.
PoW can make coin minting relatively fair, with both energy and time value injections and random luck components.
Unlike traditional PoW algorithms, which are difficult to calculate, Bitwork can adjust the mining difficulty in a fine-grained manner by changing the prefix matching method. It can add numbers between 1 and 15 after the prefix, such as “7777.1” or “7777.15” Or any number in between, which indicates the range of variation that character is allowed to vary.
Its working principle is “.” The number that follows is called a half-wildcard and is used to match any 5th character starting from that number. With “7777.10” For example, the first 4 txid characters (hex) must be “7777,” and the 5th character can be a number 10 (hex) or more.
So the 5 digits can be a, b, c, d, e, or f. This allows the entire system to choose between 2 and 16 times instead of only 16 times each time the difficulty increases.
At the same time, BitWork also brought some novel use cases:
3 ️ ︎ Container NFTs — The NFT Standard
Container (Container) is a collection standard for representing NFTs and metadata. It can be used to add/modify/delete the content of any agreement such as Atomicals, Ordinals, Bitmaps, etc., and you can also choose permanent “sealing”, that is, locking the content in a container and then destroying the “key” that can open the container, thus achieving the goal of maintaining the state it was in when sealed and cannot be modified.
Container name service:
4 ️ ECT ARC20 — Dyed Coin
The Atomicals protocol uses the smallest unit of Bitcoin, sat as the basic “atom”. The UTXO of each sat is used to represent the token itself, that is, the balance of ARC20 is the number of sat. 1 token = 1 sat.
ARC20 is a dyed coin model, and registration information is recorded in a transaction script. By binding the information to UTXO, the programmability and decentralization of the token can be improved. At the same time, the security of the transaction is guaranteed by the BTC main network. There is no need for any off-chain system to calculate the balance of ARC20 tokens in terms of tracking transactions and calculating balances, because the token balance is consistent with the number of SATs in UTXO. This is the biggest difference from the BRC-20 protocol.
When deploying ARC20, information such as token name, total amount, quantity limit, difficulty settings, starting block, images, etc.
2. When users mint ARC20, they write the name of the token into the UTXO script. The amount is directly determined by the number of sats in UTXO, 1 sat = 1 token.
3. To transfer ARC20, users no longer need to deposit any data into BTC; they only need to use UXTO, which continues to hold tokens, as transaction input and output to other addresses.
For ARC20, we only need an index to help us read token registration information and identify mint transactions to confirm which UTXO is ARC20.
The benefits of this are:
Of course, the design of dyed coins also has some disadvantages, because the balance is not written into the data, but rather the sat is bound, so the minimum split accuracy of the ARC20 balance is 1.
This also makes it impossible for users to make fine-grained transactions under the BTC mainnet itself, which has set a minimum transaction limit of 546 sat to prevent dust attacks. However, the Atomicals protocol has now proposed a specific split plan and is being actively developed.
Here’s a picture to show the most essential difference between BRC20 and ARC20:
5 ️ ︎ Realm Name System (RNS) — Domain Domain Name System
RNS claims to be the real rival of the DNS domain name system and aims to be a global replacement for DNS and other blockchain domain name systems
Realm Names are human-readable identifiers that can be used to correlate network addresses and resource information. Realm names begin with a plus sign + and have at least one alphabetic character, such as +alice and +agent007, which are all valid names (top-level — domain or TLR in the Realm Domain Name System (RNS)).
The domain name is self-owned and self-managed directly on the Bitcoin blockchain using an atomic digital object format, which basically means there are no intermediaries or centralized registrars.
6 ️ ︎ Subrealm Minting — Subdomain Foundry
Manage and tokenize communities by issuing subrealms (Subrealms) under any realm (Realm). The specific rules are as follows:
Here’s a generic example:
In addition to that, Subrealm can also be used for social media organization, identity verification, loyalty rewards, and more.
Characteristics of the agreement
Through the atomic theory above, we can see that the main features of the Atomicals protocol include:
Key differences from other agreements
The best way to understand the differences in the Atomicals protocol is to compare it to other popular NFT protocols:
“4” Bitmap protocol
Proposal of an agreement
Bitmap.land is the first metaverse project in the Bitcoin ecosystem, based on ordinals theory (Ordinals theory) and bitmap theory (Bitmap theory).
Bitmap theory (Bitmap theory) was proposed by Twitter user @blockamoto on 2023.6.5.
This theory maps each transaction input in a Bitcoin block as a parcel (Parcel) to form a block or district (district). Due to differences in the size of the different transaction inputs, the mapped lot size is also different.
Agreement concept
Bitmap.land buyers were influenced by Decentraland and The Sandbox and used the method of dividing land and drawing patterns on a map, similar to the land buying logic on these two platforms. Users write data to Satoshi through inscriptions to obtain ownership of specific Bitcoin blocks, similar to free minting.
On the Bitcoin blockchain, each block is divided into four parts to represent different halving cycles. Users can check the number and color of each block on the Bitmap.land website. Different colors represent different sales states.
Bitmap.land’s sale is closely related to ordinal number theory, similar to Decentraland and The Sandbox’s virtual land sale, which relies on ERC-721 standards. The ordinal number theory is similar to the principles of early dyed coins, but the two are different in the context of Bitcoin’s current narrative, consensus, ecology, and infrastructure. Although ordinal number theory isn’t as innovative as ERC-721, BRC-20’s approach is more primitive.
Bitmap theory adds a new explanation to the Bitcoin block, providing a topical, albeit lacking in utility. It changed the connection between Bitcoin and the metaverse, giving every block of the Bitcoin blockchain a new dimension and making it part of the metaverse by allowing users to own and record individual blocks.
The bitmap theory attracted the attention of the Ordinals community and sparked a boom in inscriptions. Any block on the Bitcoin blockchain can become part of the metaverse through a Bitmap, bringing new opportunities for creation and ownership to the community.
Bitmap.land blurs the boundaries between Bitcoin and the metaverse through bitmap theory, paving the way for ownership, creativity, and community development. As the inscription craze continues, it means huge potential for those seeking a place in the digital world.
“5” BRC-100 protocol
Proposal of an agreement
As we all know, Bitcoin-based protocols such as Ordinals Protocol and BRC-20 have brought a lot of room for imagination to the development of the Bitcoin ecosystem through an “on-chain declaration and off-chain analysis” mechanism. Also, a large number of Bitcoin NFTs and tokens have been issued, but the development of decentralized applications such as DeFi is still lagging behind. As a result, Mikael.BTC released a protocol supporting decentralized computing: BRC-100 on 2023.9.2.
Introduction to the agreement
BRC-100 is an extension protocol based on Ordinals theory, designed to implement various decentralized applications on Bitcoin Layer 1. This agreement not only undertakes the basic functions of BRC-20 on Bitcoin, such as creation, minting, and trading, but also introduces the concept of decentralized computing.
This means that based on the BRC-100 protocol stack, it is possible to develop various decentralized applications such as DeFi, SocialFi, and GameFi, bringing true decentralized, trustless, censorship-resistant and permissionless application scenarios to the first layer of Bitcoin.
One of the major features of the BRC-100 protocol is its interoperability, which not only allows all protocols and applications within its protocol stack to be compatible with each other, but also supports interaction with BTC, BRC-20, or other layer 1 chains such as Ethereum and Stacks. Additionally, the protocol introduced a UTXO model and a state machine model, enhancing its security and computational capabilities.
Characteristics of the agreement
Because the BRC-100 protocol is an extension of the Ordinals theory, the BRC-100 itself has all the features of BRC-20, while also introducing some innovative features:
Saving money: It is based on the BRC-100 protocol for various expansions such as airdrop agreements, governance agreements, relay agreements, etc. We can understand that Mikael wants to introduce various DeFi gameplay into BTC
Protocol succession
The BRC-100 protocol introduces the concept of inheritance. Protocols that directly or indirectly inherit from BRC-100 are called BRC-100 extension protocols. The BRC-100 extension protocol must inherit from only one protocol. An extended agreement inherits the properties, operations, and computation operations of the parent agreement, and can only extend the properties and computational operations.
This is similar to when we make ceramics, at the beginning it was just a clay embryo. Slowly, as we polish and shape it, we gradually have more expanded functions such as decorating, storing things, etc.
BRC-100 protocol stack
The BRC-100 protocol and all of its extensions and improvements are collectively known as the BRC-100 stack. Based on this stack, all tokens/applications are compatible with each other, which means that one token/application can use other applications anywhere.
Agreements and applications
In the BRC-100 protocol stack, a protocol is a standard for describing the properties, operations, and computational operations of an application. An application is an instance created after the protocol was deployed to the Bitcoin network via an inscription.
An app is essentially a token with computational power and status. The computing power of the application is described in detail in the protocol. If you don’t add a sub-application, the application cannot have computing power not described in the agreement. The added sub-application can also only have the computing power of the protocol; otherwise, the public indexer cannot verify the state of the application, causing the state of the user and application to be inconsistent.
Application nesting
Applications deployed based on BRC-100 and its extended protocols can be nested, that is, under one application, another application can be created, called a sub-application.
The child application’s ticker starts with “parent application ticker:”. Multiple applications can be created under one application to complete multiple independent calculation logic. For example, in the classic AMM DEX scenario, multiple LP sub-apps/tokens, such as “amm_dex: LP_BRC100_BTC”, need to be created within a DEX application.
App status and address
In addition to the UTXO model, the BRC-100 protocol also introduces a state machine model to expand the computational capabilities of the protocol.
Applications, sub-applications, and addresses can all have states. For example, apps can hold tokens, and addresses can hold balances within apps. The UTXO and state transitions are done with the burn2/burn3 and mint2/mint3 instructions.
Computational operations (cop) are used to represent specific computational logic, that is, application and address state transformation logic.
For example, address A destroys 10 token1 to the application via the burn3 inscription. At this point, the application has this UTXO and 10 token1. The application can allocate these 10 token1 through its computational logic by altering any address or the internal state of the application. Then the address of token1 in the app or the app can mint it with the mint3 command.
Permissions
The BRC-100 protocol introduces two roles: owner and administrator.
The address with the application deployment inscription is called the owner. Owners can track UTXO transfers with deployment inscriptions. The owner of all child apps is the owner of the parent app.
Administrators are managed by the owner, and administrators cannot manage other administrators. Owners’ and admins’ rights are strictly limited. They can’t vet users; they can only do: manage apps that haven’t launched DAO and complete mint2/burn2 computational operations.
An administrator can be an address, application, or sub-application. By default, the application and the sub-application are each other’s administrators; no additional settings are required, but the sub-apps are not each other’s administrators.
The burn2/burn3 inscription needs to be sent to the app’s deployer for proper processing.
Some of the tokens that the “mint2” instruction needs to be minted can only be logically allocated by the app/sub-application, and the app/sub-application needs to be the token administrator. The “burn2” instruction also has similar logic.
The burn2/burn3 inscription needs to be sent to the application’s deployer for proper processing according to the logic of the computational operation.
Decentralized governance of applications
The BRC-100 protocol stack introduces a governance protocol: BRC-101, which governs applications that implement BRC-100 or its extended protocol standards. Once the app launches the DAO, it needs to complete governance through decentralized voting.
Application governance includes updating application and sub-application properties, deploying sub-applications, and stopping applications. Application governance is on-chain governance. Once the on-chain vote passes, the app should be notified through computational action: egov, then the app will automatically perform governance after the time is locked.
Deploy applications/tokens
In the BRC-100 protocol, there are two ways to deploy applications: one is to deploy directly using deployment instructions, and the other is to deploy through the governance protocol, BRC-101.
The first one is used to deploy parent and child applications that do not require the configuration of governance, and the other is used to deploy child applications that require governance.
Minting tokens
The BRC-100 protocol provides three minting instructions: mint, mint2, and mint3, for minting tokens in different scenarios.
When deploying an application, you need to set the number of tokens users can mint (using the “mint” command). The remaining tokens will also be minted using the “mint” instructions.
“Mint”: User mints, fair mints, anyone can mint tokens for users, but the total number of “mint” operators minting cannot exceed the settings of the application’s “max” and “mma” attributes. After minting, the circulating supply of tokens will increase.
“mint2”: whitelist minting, the app records the number of users or apps that can be minted, and anyone can mint2 tokens for the user or app under the app rules. After mint2, the circulating supply of tokens will also increase.
“mint3”: Mint3 is treasury minting. mint3 is the balance of users or apps in other apps. Anyone can apply mint3 tokens for users or apps under application rules. After mint3, the circulating supply of tokens will not increase.
Destroy tokens
Destroy is a new operation introduced in the BRC-100 protocol. Users can engrave the destroy operation and then transfer the inscription to the application’s deployer, which is similar to the semantics of the transfer operation. The burned tokens will then be destroyed or transferred to the app’s balance.
Similar to the definition of a mint operation, there are 3 burn operators: burn, burn2, and burn3, which logically correspond to mint, mint2, and mint3 respectively. No additional configuration is required, and all apps/tokens support these three burn instructions.
“Burn”: Public burn, where everyone can use instructions to destroy tokens. Once the token is successfully destroyed, circulation will decrease, and the destroyed token cannot be minted again.
“burn2”: The whitelist is destroyed. According to the rules set by the application, after burn2 tokens are transferred to the application, the user’s balance will decrease, the application status will be updated accordingly, and circulation will decrease. In reality, logic such as removing liquidity in AMM DEX can be implemented through burn2.
“Burn3”: The treasury is destroyed. Burn3 will reduce the user’s token balance and increase the balance of the “to” application. In actual applications, it is possible to cooperate with mint3 to complete the logic of exchanging tokens and increasing liquidity in AMM DEX.
Transaction taxes and deflation
The BRC-100 agreement introduced a new mechanism for trading tokens: transaction taxes and deflation. Applications can set transaction tax percentages, tax recipients, and transaction black hole percentages. These settings only take effect when trading on AMM-based decentralized exchanges. Normal transfers, minting, and destruction operations do not incur transaction taxes or deflation.
Computational operations
Computational operations are extended computational behaviors of the BRC-100 protocol. It is represented by the cop attribute and is the smallest unit of computational power of the protocol. When used with the op operator: burn2/burn3/mint2/mint3, it can be understood as a state transition function, which defines how the state of the application and user is updated under the corresponding op operator.
Oracle oracles
Oracle is a common requirement for blockchain to interact with all parties under the chain, and has been well implemented and applied on blockchains such as Ethereum. Without oracles, smart contracts on the blockchain would be entirely limited to on-chain data. However, compared to blockchain, the BRC-100 protocol has very special characteristics.
It not only has the computing power of the blockchain, but also relies on an off-chain indexer to complete the calculation. At the same time, off-chain indexers can directly communicate with other blockchains or meta-protocols, but blockchains cannot do this, which means that the indexer can verify that any data off-chain or on-chain meets the requirements of the Oracle BRC-100 protocol.
Examples: verifying the transfer of BTC or BRC-20 assets, verifying the price of ETH on an Ethereum block, etc.
In other words, in the BRC-100 protocol, oracles have a new paradigm: attestation and verification, where users submit attestation data, and the indexer acts as an Oracle Verifier to verify user-submitted attestation data outside of the agreement, without the need for a separate Oracle service.
In the BRC-100 protocol, the burn2/burn3/mint2/mint3 instructions natively support proof attributes for submitting proof data outside of the protocol. The indexer can verify certification data and ensure the consistency and accuracy of the status. The proof can be transfer proof, Merkel tree proof, zero-knowledge proof, price proof, etc., and can be used to bridge scenarios such as assets, airdrops, etc., and can be used to bridge scenarios such as Bitcoin layer 2, loan settlement, etc.
relay protocol
The meta-protocol on Bitcoin is heterogeneous and cannot communicate with each other. Different protocols are similar to different blockchains; they share the security of the Bitcoin blockchain and have different computational capabilities. Furthermore, meta-protocols cannot directly communicate with other blockchains: Ethereum, for example, cannot use assets on other blockchains.
Therefore, the BRC-100 protocol stack requires a relay protocol to complete communication between Bitcoin, meta-protocol, blockchain and the BRC-100 protocol, bridge assets on other protocols or blockchains to BRC-100, and participate in decentralized applications such as DeFi. Meanwhile, due to the diversity of protocols and blockchains, BRC-100 will have multiple relay protocols.
First, we’ll be releasing: BRC-103, which is responsible for bridging assets between Bitcoin, BRC-20, and BRC-100.
When an asset is bridged from the meta-protocol or blockchain (source) to the BRC-100 protocol (target), in order for the indexer to verify the correctness of the transmission, it is necessary to submit proof of transmission data using the “mint2” command, which is called proof of transmission.
Proof of transfer means that when an anchored asset is minted on the target protocol (BRC-100), transfer data from the source side (such as Bitcoin, BRC-20, or other blockchain) must also be submitted as proof. This can be a transaction hash or inscription ID.
So that all BRC-100 indexers can verify the correctness of the minting of the anchored assets.
Transfer Proof is a very important application of Oracle’s BRC-100 protocol.
Protocol use cases
Since BRC-100 was extended from BRC-20, it essentially has all the application scenarios of BRC-20, but the application scenarios of BRC-100 are far more than that. We can still expand on the basis of the BRC-100 protocol. Here are some of the official extensions listed, some of which are already under development:
BRC-101 (released)
The BRC-100 protocol stack’s decentralized on-chain governance protocol defines how to update the attributes of parent/child applications/tokens, stop applications, and add child applications.
Additionally, BRC-101 can also complete off-chain governance through decentralized voting.
BRC-102 (in development)
An automated liquidity protocol defines how to exchange tokens for the BRC-100 protocol stack through an automated market maker (AMM) algorithm. The calculation logic will be similar to Uniswap on Ethereum.
BRC-103 (in development)
A relay protocol between BTC, BRC-20, and BRC-100. The meta-protocol on Bitcoin is heterogeneous and unable to communicate with each other. Different protocols are similar to different chains. They share the security of the Bitcoin blockchain and have different computing power.
Therefore, the BRC-100 protocol stack will publish multiple relay protocols to complete communication between meta-protocols, different chains, and BRC-100, and bridge other protocols and on-chain assets to BRC-100 to participate in DApps such as DeFi.
BRC-104
Liquidity mining agreements define how to obtain token rewards after staking tokens.
A staking token can be any BRC-100 based token, such as the BRC-103 protocol’s liquidity pool token, or the same token as a reward token. Additionally, BRC-104 will support locking staked tokens during the lockdown period.
BRC-105
An airdrop protocol defines how to efficiently airdrop tokens to multiple addresses.
The protocol will use Merkle Tree to complete the airdrop to save on transaction fees since all of the original airdrop data does not need to be made public on Bitcoin. Users only need to submit Merkle Proof to prove that they own the airdrop during “mint2”, then all indexers can verify the correctness to complete the airdrop.
BRC-106
A decentralized stablecoin pool protocol defines how stablecoins are generated through collateral.
The computational logic will be similar to MakerDAO3’s DAI on Ethereum.
BRC-107
A loan pool agreement defines how assets can be borrowed through collateral.
The computational logic will be similar to Aave on Ethereum.
BRC-108
An automated liquidity protocol for stablecoins.
BRC-109
Decentralized trading protocol for perpetual futures.
BRC-110
A relay protocol between EVM compatible blockchains and BRC-100 defines how assets on EVM compatible blockchains can be bridged to BRC-100.
BRC-111
Bitcoin’s layer 2 verification protocol defines how to verify Bitcoin’s layer 2 proof data like a layer 2 smart contract on Ethereum.
“6” BRC-420 protocol
Proposal of an agreement
After the BRC-20 protocol was proposed, another new experimental protocol called BRC-420, also known as the metaverse protocol, appeared on 2023.9.19.
Agreement concept
BRC-420 is an interesting experiment. It is the first metaverse protocol in the Ordinals Protocol, an asset protocol based on the Bitmap protocol.
By combining multiple inscriptions into one complex asset, such as game items, animations, and effects, or game modules in the metaverse. Everything from small characters and pets to full game scripts and virtual machines has been created.
Due to their on-chain open source nature, these assets can be run or verified by any client, fully reflecting the “Client Agnostic” spirit of full-chain games.
The BRC-420 agreement consists of two parts: the Metaverse Standard (Metaverse Standard), which defines an open format for assets in the metaverse, and the Royalty Standard (royalty standard), which establishes an on-chain agreement for the creator economy.
BRC-420 opens up possibilities for Ordinals’ on-chain gaming and modular blockchains. Different creators can contribute different modules, and new creators can build on the innovation of their predecessors. This has led to a proliferation of innovations within the Ordinals ecosystem, benefiting all participants.
Agreement development
Currently, BRC-420 released the BRC-420 DLC on 2023.11.3, which can integrate thousands of meta inscriptions into 1 DLC. After deployment, users can get thousands of meta-assets in a single minting.
“7” Runes agreement
Proposal of an agreement
After the BRC20 protocol came out, Casey felt that it was not a good idea to create homogenized tokens on Bitcoin. 99% of homogenized tokens are scams and won’t disappear in the short term. Creating a good homogenized token protocol for Bitcoin is likely to bring Bitcoin significant transaction fee revenue, developer attention, and users.
Casey therefore proposed the Runes protocol based on UTXO technology on 2023.9.26.
The design of the Runes protocol may also have been affected by ARC20. The choice was to write token data directly into the UTXO script, which includes the ID, output, and quantity of tokens.
Obviously, Runes’ implementation is very similar to ARC20, and token transfers are handled directly to the BTC mainnet. The difference is that Runes writes the number of tokens in the script data, which makes him more accurate than ARC20.
At the same time, however, the complexity has also increased, making it difficult to directly utilize the combinatorial nature of BTC UTXO like ARC20.
Agreement development
Since the launch of the Runes agreement, since Casey’s development effort was mainly on the Ordinals protocol, the development of the Runes protocol has been slow, which is why Benny quickly overtook corners and developed the Pipe protocol after the release of the Runes agreement.
During Taiwan Blockchain Week in December, Casey also announced at an event in Taipei that the Runes Protocol will launch on the main network. At the block height of 840,000, that is, the next time BTC is halved, it will probably be at the end of April 2014.
After researching the BTC asset issuance plan, I also fully felt their charm, so I also mentioned some of my own subjective opinions:
Finally, thank you for reading this article. The original purpose of this article is to give you a better and more comprehensive understanding of the development of the BTC ecosystem, and you are also welcome to come and talk to me. In the next few days, I will post some opinions from time to time, and I will also write another article on the expansion plan, so stay tuned.