Using a Timeline to Clarify the BTC Ecological Context - Asset Issuance

AdvancedJan 01, 2024
This article introduces and compares the development history of asset issuance agreements.
Using a Timeline to Clarify the BTC Ecological Context - Asset Issuance

TL; DR

  1. Recently, with the popularity of the BTC ecosystem, we can see various tokens being issued on the Bitcoin mainnet, so what are these tokens and how do the protocols behind them work.
  2. The purpose of this article is to clarify the circumstances of the BTC asset issuance plan in the form of a timeline. What actually sparked the popularity of Bitcoin inscriptions, let’s dive in and find out.
  3. At the same time, this article has referred to many articles. During my reference and research, I found that individual articles may have errors in the timing of some agreements/projects, so I have attached relevant materials to all timelines in this article. If there are any errors, please point them out to me, thank you.
  4. Disclaimer: The tokens mentioned in the article are for learning and exchange use only, and there are no investment suggestions. DYOR

Chapter I — The Gears of Fate Begin to Spin

“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.

Chapter II — BTC Ecosystem Asset Issuance in Full Blossom

“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:

  1. 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

  2. $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:

  1. The first transaction reads the latest ledger data in the local ledger and calculates the balance

  2. 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:

  1. OrdFi protocol with unique token standards
  2. Compatible with BRC20 tokens, easy market integration, and breaking the BRC20 name length limit. The length of the BRC-20 token is fixed to 4 digits, while Tap’s token length is 3 or 5-32 bits (not 4 digits)
  3. It supports functions such as batch transfers, pledged assets, and token swaps. Improve transaction efficiency without relying on the L2 chain
  4. First agreement to support curse inscriptions

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:

  1. Some physicists claim that information is a new form of matter that could eventually conquer everything on Earth (which is also very controversial). According to current growth trends, the amount of digital information on Earth may be used more than physical atoms in about 350 years, which also highlights the exponential growth and importance of digital information.
  2. The physicist’s idea encouraged many to turn him into an enforceable protocol, parsing valuable information from the Bitcoin blockchain to create “not an arbitrary token “. Using digital matter theory may completely change the creation of digital value, making it more non-arbitrary and meaningful. By using data in the context of digital matter theory, new mechanisms can be created to identify and derive new value sequences in data, opening up possibilities for new forms of tokens.
  3. For example, some people even compare Bitcoin to an application of DMT. Bitcoin is also not an arbitrary token. It has its own specifications such as 21 million coins, one block in 10 minutes, etc. Through digital information exchange on the Bitcoin network, value can be transferred and stored. Although Bitcoin only exists in the digital world, its value and influence can have a significant impact in the real world, just like traditional physical money.
  4. However, DMT is not without controversy. Some critics argue that digital information cannot be compared to basic physical entities such as matter and energy, because digital information itself cannot directly change the real world. However, DMT advocates believe that although digital information cannot directly change the real world. However, through human actions and decisions, digital information can indirectly change the world, such as the application of cryptocurrencies.

Problems Existing Bitcoin Builders Face

  1. Various issues caused by proprietary APIs:
  2. Service locking, high interaction costs, the same on-chain data will have different forms of expression, competition among developers
  3. Unreliable indexers:
  4. Asset safety issues, frequent changes, positive and negative numbers of Ordinals
  5. Lack of top-level design:
  6. Difficult to combine agreements and develop proprietary facilities
  7. Limitations of on-chain metadata:
  8. Example: Collections must be manually uploaded to Github repositories, and they must be manually updated on dozens of marketplaces, there is no consensus on on-chain responses
  9. Bugs can’t be fixed or are expensive to fix
  10. The data structure of the Ordinals protocol relies heavily on the use of a single file, which means that different markets have off-chain agreements and proprietary indexes
  11. Lack of control:
  12. If there is no access to a powerful high-performance decentralized indexer and more service/indexer locks, then data portability will become an issue
  13. Lack of earnings:
  14. Relying on these specific services and marketplaces and proprietary services such as indexers and APIs can result in lower profits

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:

  1. Add a random element of luck to the casting process
  2. Organize communities around vanity TXIDs and ReFS
  3. When you have a really cool reference or prefix, you can organize a relevant community by consensus
  4. Content ranking based on expensive signal theory
  5. In this way, we can rank content based on energy consumption such as electricity
  6. Throttling and limiting token minting — spam filter

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:

  1. Container names begin with the hashtag # symbol, and each name is unique and unrepeatable, and is cast on a first-come, first-served basis
  2. The name is in the range of 3-64 characters, and Bitwork is used to slow the registration of container names
  3. Examples of container names: #bitcoin -funks, #gemini -warriors,…

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:

  1. The cost of the index server has been greatly reduced. Almost anyone can make their own index server, and the system is highly decentralized
  2. Transfers are completely dependent on the BTC network and will not repeatedly create spam transactions. The security of ARC20 transfers themselves is guaranteed by BTC
  3. The atomicity of ARC20 is consistent with that of BTC, making it suitable for many native applications

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:

  1. Any field or subfield can publish subfields
  2. All subdomains can inherit the same characteristics and publish their subfields based on the subdomain
  3. Everyone is a registrant in the field they own, and there is no centralized agency

Here’s a generic example:

  1. First we registered a field +ATOM
  2. When we want to form a community about Punk NFTs in this field, we can create a sub-field based on the +ATOM field +ATOM.PUNK
  3. After that we want to set up a DAO in the Punk community, then we can create another sub-field +ATOM.PUNK.DAO
  4. Everyone in the DAO is assigned a DID, then you can create a subdomain +ATOM.PUNK.DAO.JINGLE

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:

  1. Use Satoshi as the basic unit to represent the token
  2. Allows digital objects to be created, transferred, and updated on Bitcoin
  3. Providing a decentralized, Bitcoin culturally compatible tokenization approach
  4. Using Proof of Work (POW) to increase fairness and decentralization of the casting process
  5. Designed to expand Bitcoin’s functionality and support a wider range of applications

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.

Interested students can also go to the official browser to view various bitmaps: https://bitmap.game/

“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.

summed

After researching the BTC asset issuance plan, I also fully felt their charm, so I also mentioned some of my own subjective opinions:

  1. The issuance of BTC assets has sparked the explosive development of the BTC ecosystem this year, although there are mixed reviews about them. But when we look at the development of the BTC ecosystem in abstraction, they are all inseparable from one important thing — the “story.”
  2. As I mentioned in my previous thoughts, a product needs to be supported by a good narrative; otherwise, it is easy to face an awkward situation where there is only a product and no users. And various asset issuance plans also prove this, such as first is first, the various imaginations brought to the ecosystem by the agreement, official endorsements, etc., all of which are concrete expressions of the narrative.
  3. Similarly, we cannot deny the contribution this wave of asset issuance has brought to the BTC ecosystem. Although most asset issuance solutions may not substantially break through Bitcoin’s limitations from a technical point of view, they not only provide a rare stress test for major public chains, but also bring some possible routes for Bitcoin’s future development.
  4. Through these waves of inscriptions this year, the long-tail effect of inscriptions has gradually expanded from the original Bitcoin to inscriptions on other public chains. Meanwhile, under the popularity of inscriptions, we also feel some of the shortcomings of the current Bitcoin main network, such as high gas fees, slow transaction speed, etc., which also shows the need for a BTC expansion plan.
  5. Even though the expansion plan was already being laid out by project parties a long time ago, it has been tepid. Now more and more users are paying attention to the BTC ecosystem under the popularity of inscriptions, and this has accelerated the development of the BTC expansion plan in disguise.
  6. Currently, existing expansion plans are mainly divided into the three categories of sidechain/lightning network/native L2, but no one direction has determined their leading edge, and they are still in the competitive stage. As to whether the future will blossom a little more or be amazing in a certain direction, we can look forward to it. At the same time, this is the direction we can focus on in the future.
  7. In the investigation of asset issuance plans, there is a very clear trend. From the launch of the initial Ordinals protocol, to the subsequent BRC-20 improved protocol based on Ordianls, to decentralized computing protocols such as the BRC-100 decentralized computing protocol (which wants to continuously expand and introduce gameplay in the DeFi ecosystem into Bitcoin), the BRC-420 metaverse protocol (which brings the possibility of introducing games, music, etc. into Bitcoin), ARC-20 (with BRC-20 parallel new asset issuance plan), etc.
  8. The asset issuance scheme has evolved from making some basic improvements to existing asset issuance agreements to making some large-scale ecological layout and even issuing rules for the needs of the BTC ecosystem (such as oracles, DeFi, games, etc.) on the basis of an asset issuance agreement.
  9. The development of the BTC ecosystem is still very early. Whether in Web2 or Web3, there is a phenomenon where anyone can have users as long as they have the power to set the rules first. Therefore, there are still many wealth opportunities at present. We must take a comprehensive look at the development of the BTC ecosystem. After all, the craze of inscriptions will cool down. We must not only keep an eye on asset issuance, but also look at how to accelerate the development of the entire BTC ecosystem in other areas through asset issuance.
  10. Of course, there are also some different opinions on this aspect, such as Teacher NingNing’s opinion on BTC L2 https://twitter.com/0xNing0x/status/1737010523374563744,理性探讨.
  11. Although it’s still in the research stage, everyone’s butt determines their head. However, I still want to remind everyone to pay attention to risk when investing, and to clearly write your own investment logic. Whether to fight the short term or the long term, the logic is different, and the strategy is different. When it comes to investing, it is still necessary to combine knowledge and action as much as possible. I really believe in the saying “You will never make money other than you know, and even if you earn it now, you will throw it out”.

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.

Disclaimer:

  1. This article is reprinted from [marsbit]. All copyrights belong to the original author [Howe]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
  2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
  3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.
Start Now
Sign up and get a
$100
Voucher!
Create Account