core ideas

Inscription tokens represented by BRC-20 were not recognized by the mainstream Web3 community when they were first launched. Most opinions compare it to early Bitcoin derivative asset protocols such as Omni-USDT in technical analysis, and attribute its rise in market analysis to the logic of ordinary MEME coins (the concept of Fair Mint is anti-VC, banker pull, retail FOMO, etc.) . But in essence, what BRC-20 represents is a new crypto asset liquidity paradigm.
In the early days, the asset logic of BRC-20 was very similar to NFT. All participants can only make transactions on the Bitcoin chain, and transactions are often made in units of "tickets" rather than the number of tokens. Higher casting costs make the natural initial cost for all participants higher. Coupled with higher transaction fees and longer waiting times, early participants will often think twice about exiting. This low liquidity also gives it a relatively inflated floor price, further enhancing the confidence of holders.
Just as NFTs on new public chains such as Solana often do not develop as well as Ethereum NFTs, for a new early-stage asset, if the liquidity is too good and participants can easily exit at a low price, it may not be a good thing for the project. BRC-20, which grew on the Bitcoin chain, naturally enjoyed low liquidity in the early stages.
In the middle and late stages, the asset logic of BRC-20 will be more like ordinary tokens. Because of its divisibility as a "token", each "piece" of BRC-20 tokens can be split into smaller units or aggregated into larger units for trading; and it can also be listed on Binance In large centralized exchanges, once the currency is actually listed, there will be almost no difference between it and other tokens from the perspective of exchange users.
This kind of divisibility and liquidity that adapts to the project development stage is something that NFT does not have, and it is also the real killer feature of BRC-20. During the NFT bull market, many people suffered from the fact that the unit price of the leading NFT was too high to participate, and the various "NFT liquidity solutions" have not been truly universally mature so far. If viewed from this perspective, BRC-20 can be regarded as an NFT with its own "fragmentation" solution.
Description and reading guide for this article
The main text is divided into three parts:
Bitcoin trading and scripting technology principles
Segwit and Taproot upgrade
Inscription: Ordinals protocol and derivative protocols such as BRC-20
The full text is relatively long, and the first two parts are mainly technical explanations, hoping to help readers understand the inscriptions from a principle perspective.
If the reader prefers to understand the viewpoints related to inscriptions and is not interested in the basic technology of Bitcoin, it is recommended to start reading directly from the third part.
1. Principles of Bitcoin Transactions and Scripting Technology
The structure of the trading script
When a person starts sending a transaction to the Bitcoin network, he is actually entrusting a Bitcoin node in the network to broadcast a script recording the transaction information to the Bitcoin transaction pool.
The transaction script consists of the following four parts: version number, input part (input quantity, input script), output part (output quantity, output script), and lock time.
[nVersion] [nInputCount] [txInputs] [nOutputCount] [txOutputs] [nLockTime]The most classic Bitcoin transaction example is broken down as follows:
01000000 // 4 bytes version /* input */ 01 // number of inputs e34ac1e2baac09c366fce1c2245536bda8f7db0f6685862aecf53ebd69f9a89c // tx id 00000000 // input index 00 // unlocking script length ffffffff // unlocking script /* input end */ /* output */ 02 // number of outputs a025260000000000 // amount 19 // locking script length 76a914d90d36e98f62968d2bc9bbd68107564a156a9bcf88ac // locking script 5062250000000000 // amount 19 // locking script length 76a91407bdb518fa2e6089fd810235cf1100c9c13d1fd288ac // locking script /* output end */ 00000000 // 4 bytes locktimeoutput
Basically, the transaction output is an indivisible collection of Bitcoins that can be spent by all users, that is, UTXO (unspent transaction output) :
amount, this output means how many Bitcoins there are, but the unit is satoshi, the smallest unit of Bitcoin value.
Locking script, commonly known as "locking script", determines the sufficient conditions required for this output to be spent, which is a lock to protect this output from being spent by others.
Going back to the above Bitcoin example transaction disassembly, the output will initially have 1 byte data to tell us how many outputs there are in total. The example here is 2. The next amount part shows the number of each output. Finally, there is the locking script.
enter
Generally, there will be a 1-byte size that tells us how many inputs there are in this transaction. It may not be just one input, because sometimes many small UTXOs are needed to put together to buy an expensive thing.
The next step is to tell us which output the transaction id is to find this UTXO .
scripting language
Stack-based language Script:
2 3 OP_ADD 5 OP_EQUAL

The Bitcoin language is Turing incomplete, mainly because it does not support "loops".
In a Turing-complete language, such as Python, Java, or C++, programmers can write loops so that a piece of code can be executed repeatedly until a certain condition is met. However, the Bitcoin scripting language does not have this feature.
The reasons for this are security and predictability. In a public, trustless network such as Bitcoin, allowing arbitrarily complex programs (especially those that can run infinitely) can pose security risks. A malicious attacker might try to slow down or jam the network by submitting a transaction designed to loop endlessly. And because the Bitcoin scripting language is Turing incomplete, this attack is impossible.
Additionally, due to the simplicity of the Bitcoin scripting language, it allows for easier formal verification. This means that you can accurately predict how a script will behave by examining it without actually executing it. This is very important when designing safe and reliable financial systems.
Transaction Types and Scripting Languages
Payment Public Key Hash (P2PKH)
Most Bitcoin transactions use this script, such as transactions where Alice's address sends money to Bob's address. P2PKH's locking script will look like this
OP_DUP OP_HASH160 <公钥散列> OP_EQUAL OP_CHECKSIGThe above Public Key Hash is actually equivalent to the owner's address, but there is also a version without Base58Check encoding. This is why it is called P2PKH, because it pays the Public Key Hash. To put it bluntly, it pays the general address. . And if you need to spend this UTXO, the entered unlocking script only needs to look like
<签名> <公钥>So when we connect the unlocking script and locking script of P2PKH, it will look like this.

The entire verification process looks like this:

At the beginning, the signature and public key are pushed up the stack in order.
Let’s look at DUP again
- Make the thing on top of the stack, that is, the public key, multiple times.
Next is HASH_160HASH160
- Pop the top public pointer of the stack, do it once, and then push it back to the top of the stack.
Next, when you encounter Public Key Hash, of course you push it directly to the stack.
P2PKH is doing two things
You need to give the public key to prove that the address to which this UTXO belongs is yours, because the public key can generate a unique address (this is actually a Public Key Hash, but the meaning is the same as an address).
In addition to giving the public key, which is not secure enough, you also need to give a signature to prove that you hold the secret key, because the signed product requires the secret key, but the test proved that only the public key is needed.
Payment Public Key (P2PK)
It is actually a simplified version of P2PKH. Its locking script looks like the following
<公钥A> OP_CHECKSIGAnd his corresponding unlocking script looks like this
<私钥A签名>It directly puts the public key in the locking script, so your unlocking script no longer needs to provide the public key, just give it to Signature for verification.
Data output (OP_RETURN)
The third standard type of transaction is called data output. It is the output that we mentioned above and cannot be spent. Its purpose is to record, because the blockchain is open and transparent and cannot be tampered with, so this The output of this state is generated, and the pure data record is not used for transferring money. And his script (strictly speaking, a locking script) looks like this
OP_RETURN <数据>It cannot be unlocked, so there will be no unlocking script, and because this output cannot be spent, it will not calculate UTXO, and the database in the memory will not have this output.
However, the length of data after OP_RETURN is limited to 80 bytes , because Satoshi Nakamoto does not want everyone to use BTC’s precious block space simply to store data.
The earliest Omni-USDT was implemented using this 80-byte OP_RETURN space, and its technical principles are very similar to the later BRC-20. Specifically, each Omni-USDT transaction is represented by 16 bytes within OP_RETURN, as follows:
Transaction version: transaction version. 2 bytes, value 0.
Transaction type: Transaction type. 2 bytes, 'simple send' value is 1.
Currency identifier: Currency identifier. 4 bytes, USDT value is 0x1F (31).
Amount to transfer: transfer amount. 8 bytes.
Analysis based on specific examples:
6f6d6e69000000000000001f000000174876e800
The analysis is as follows:
6f6d6e69: ASCII code corresponding to 'omni', because the transaction remarks are related to the omni protocol
0000: transaction version
0000: transaction type, represents 'simple send'
0000001f: 31, represents USDT
000000174876e800: USDT transfer amount, 1000 00000000 Minimum unit = 1000 USDT
However, due to the efficiency and handling fees of the Bitcoin chain, as well as the rise of "new public chains" such as Ethereum, the main position of new coins such as USDT has gradually shifted to other chains.
multi-signature
Multi-signature: There is now a script that is composed of N public keys, and if you want to unlock the UTXO it protects, you only need to provide signatures from M of them. M’s current maximum limit in Bitcoin is 15 public keys, and his locking script looks like this
M <公钥1> <公钥2> ... <公钥N> N OP_CHECKMULTISIGFor example, 2-3 multi-signature is as follows
2 <公钥A> <公钥B> <公钥C> 3 OP_CHECKMULTISIGThen the unlocking script to unlock him will be
OP_0 <签名B> <签名C>Pay to Script Hash (P2SH)
Extending from the above multi-signature, if the current architecture is 2-5, how long will the locking script be? What if it is 3-7? What burden will it cause if the locking script is too long? We know that locking script is used to protect UTXO from being stolen. The growth of locking script will lead to the growth of UTXO. We just said that UTXO will be stored in expensive memory for convenience. Therefore, if UTXO becomes larger and larger Bitcoin nodes will consume more and more memory, so P2SH comes on the scene.
The function of P2SH is actually to hash a long locking script and then replace it to shrink the locking script and move this part to the Unlocking Script. Simply put, the difference is as follows:

Another very important feature of P2SH is that the locking script now clamps a product that has been HASH160 . This is the same process as generating an address. If you perform Base58 check encoding on it, you can also get an address, which is The multisig address that everyone often talks about always starts with 3. It can do the same thing as a normal address. Others can send money to this address, and this address can also transfer money out. The only difference is that this address Signing transactions that send money require a redeem script and may involve more than one signature.
To sum up, P2SH has the following advantages:
Although both input and output will be on the blockchain, because the redeem script is placed on the input, the size of the blockchain will only be increased until it is spent, instead of increasing the size immediately.
He can change the target of sending money to an address starting with 3 instead of a displayed multi-signature address, which can protect the privacy of those who are not involved in taking money.
He can shift the pressure of handling fees to the person receiving the money.
2. Segwit and Taproot upgrade
Segwit-BIP141
Simple understanding: Segwit is to try every means to move scriptSig out, thereby achieving block expansion of 1MB → 4MB
Further understanding:
Satoshi Nakamoto wrote in his previous code that when reviewing and counting block sizes, the size of each block should not exceed 1M .
Segregated Witness takes the script signature (scriptSig) information out of the basic structure (base block) and puts it in a new data structure. The nodes and miners doing the verification work will also verify the script signature in this new data structure to ensure that the transaction is valid.
When the audit statistics block size cannot exceed 1M. Script tag size is not taken into account . So this is a soft upgrade

Technical principle:
BIP141 chooses to use some tricks on the locking script output in the previous stroke. As long as you see that scriptPubKey starts with 0x00, it will be given a new meaning.
P2WPKH
witness: <signature> <pubkey> scriptSig: (empty) scriptPubKey: 0 <20-byte-key-hash> (0x0014{20-byte-key-hash})The full name is public key and is put into the witness program, so the input scriptSig can be empty. To put it simply, the beginning of scriptPubKey is 0 to let the script engine know that this is a segwit transaction, and the next 20 bytes let the script engine know more clearly that this is a P2WPKH output, so the script engine will witness the program to get the signature and public transaction. key, the final verification is the same as ordinary P2PKH.
Why are older versions compatible:
If you don't upgrade, all you see is an empty output signature, which superficially means "this is an output that anyone can spend." But when you really want to spend it, most upgraded nodes will check the signature script you provide, which is something that older versions of the client cannot provide.
Segwit adoption rate has reached 96%

Taproot BIP340-342
Taproot is a 2021 Bitcoin upgrade that is based on Segwit.
This upgrade actually includes three major changes, and because it needs to support Schnorr signatures, the Bitcoin scripting system must make some changes (BIP-342), including discarding some inefficient opcodes and adding some new ones. At the same time as the operation code, Bitcoin Core also canceled the Bitcoin script size limit .

(from BIP-342 wiki)
From a script perspective, Taproot inherits the Segwit script and gives a new script version. If you see the new version number, then this is the Taproot script.
The Taproot script removes the script size limit and greatly increases what Bitcoin can do. This change gives a good solution for putting pictures on Bitcoin. The following is a script example of the Ordinals protocol:
<signature> OP_FALSE OP_IF OP_PUSH "ord" OP_1 OP_PUSH "text/plain;charset=utf-8" OP_0 OP_PUSH "Hello, world!" OP_ENDIF <公钥>If the above script removes all the operation codes and data in the middle, it will be a standard signature. What is the middle script doing?
OP_FALSE will push an empty array to the stack. Note that there is something pushed here, but it is empty.
OP_IF checks the top of the stack. If it is true, it will do the next thing. Because of the previous OP_FALSE action, this if will not stand.
Next is OP_PUSH... and a series of operations will be ignored because the previous if condition was not met.
OP_ENDIF ends the if block.
It can be seen that these operations in the middle will not be established because OP_IF, so in fact, no status has changed , so the complete information of the picture can be placed in OP_IF instead of affecting the verification of this Bitcoin script. Therefore, after the taproot upgrade, scripts now have no restrictions. So you only need the size of the transaction relative to the block size (4 MB), and you can have as many scripts as you want, which means we can achieve an effect similar to OP_RETURN and put irrelevant data on Bitcoin without the 80-byte size limit. .
3. Inscription: Ordinals protocol and series of derivative protocols (BRC-20, etc.)
Ordinals Agreement
Ordinals is a protocol that allows the minting of NFTs on the Bitcoin blockchain. The core idea is: each satoshi on the Bitcoin blockchain is generated in the chronological order of mining, and content (text, pictures, videos, etc.) can be written on each satoshi. This writing process is called As "inscribed", the Ordinals protocol and protocols with similar technical principles are also collectively referred to as the "inscribed track" . It can be seen that as long as each satoshi can be numbered and allowed to be tracked and transferred, the content written on each satoshi will have a unique number. This is what everyone usually calls NFT.
Under this idea, Ordinals implements the following two key functions:
1. Create a numbering system for satoshi (ordinal number theory);
2. Write data to satoshi.
This agreement has the following characteristics:
NFTs are completely stored on the Bitcoin blockchain and do not require side chains or generation of other Tokens;
NFTs are as secure, decentralized, and stable as the Bitcoin blockchain.
The specific details of Bitcoin NFT can be found by looking at the content on the corresponding satoshi. For example, taking inscription 129490 as an example, it contains the transaction ID, NFT owner's address, output value, satoshi number, generation time, etc. information.

By entering the string of characters of genesis transaction in the Bitcoin browser , you can find the transaction block where the satoshi is located. Imagine that the Bitcoin blockchain is a digital museum composed of blocks one after another, and each Bitcoin NFT is a digital artifact on display.

BRC-20
BRC-20 technical principle
Two months after the Ordinals protocol was released, Twitter user @domodata proposed another Bitcoin Token standard on the Ordinals protocol - the BRC-20 standard . The author also bluntly said that the "BRC" in BRC-20 is not the abbreviation of something, but a complete imitation of the naming method of ERC-20. But this naming method works surprisingly well - it not only tells everyone straightforwardly that this is a set of token issuance standards on Bitcoin, but also gives everyone room for imagination "similar to ERC-20".
BRC-20 essentially uses the text burning function of Ordinals and agrees on a format for accounting tokens using json text. Specifically, 3 functions are defined:
- Deploy deployment
{
"p": "brc-20",
"op": "deploy",
"tick": "ordi",
"max": "21000000",
"lim": "1000"
}
To deploy the inscription, the tick field is used to represent the token name, max represents the supply, and lim represents the maximum amount of each mint. It is worth noting that the BRC-20 protocol stipulates that the token name "tick" cannot exceed 4 characters, which makes the name space relatively small, and the token name follows the "first come, first served" principle.
- Mint
{
"p": "brc-20",
"op": "mint",
"tick": "ordi",
"amt": "1000"
}
For minting inscriptions, fill in the tick field to represent the token name, and amt to represent the amount of the mint.
3. Transfer
{
"p": "brc-20",
"op": "transfer",
"tick": "ordi",
"amt": "100",
"to": "1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa"
}
To transfer the inscription, you need to fill in the token, code number, quantity and destination address.
It can be seen that BRC-20 does not express many parts on the chain. To understand the specific number of positions of each address of a coin, it relies heavily on external centralized analysis. Therefore, the construction of relevant infrastructure is a Chance. Unisat and OKX wallets have seized this opportunity very well, and promptly made wallet and exchange functions for BRC-20 tokens, which not only gave new entrants a lower-cost way to get started, but also provided It brought a lot of traffic on its own.
Why is BRC-20 so popular?
From a technical perspective, BRC-20 may not be considered a particularly innovative technology. As mentioned earlier, the Omni protocol was able to issue tokens in 2013, and the earliest USDT was first issued on BTC. Therefore, when BRC-20 first came out, many people thought that it was just a new air currency, thinking that it was no different from the early Omni-USDT and other protocols, and that its popularity was at best a new MEME logic.
However, it is not. People who make analogies between BRC-20 tokens and early Bitcoin tokens such as ordinary MEME coins and Omni-USDT often ignore that BRC-20 actually created a new liquidity paradigm .
First of all, all tokens created through the BRC-20 protocol are "Fair Mint". In the past, whether it was various public chain coins or various ERC-20 and other standard project coins, a large number of low-stakes tokens were reserved for project internal personnel, VC investment institutions, etc. before they were released to the public. As a result, retail investors often have to face the sale of these low-cost chips when they can buy chips. For BRC-20 tokens, even those who deploy tokens need to pay Bitcoin network fees equally when minting tokens, so that no one can save low chip costs in the early stage. This is very attractive to retail investors who have been "harvested" by project parties and institutions for more than a year in the bear market. From a practical point of view, this also makes the chip distribution of many inscription tokens relatively dispersed and healthy.
But just relying on the feature of Fair Mint is not enough, because Fair Mint can also be realized through smart contracts on other chains.
The special thing about BRC-20 is that in the early days, it was like NFT logic. All participants could only conduct transactions on the Bitcoin chain. The higher Mint cost made the natural initial cost of all participants relatively high. Coupled with higher transaction fees and longer waiting times, early participants often think twice when exiting; and this low liquidity also gives it a relatively inflated floor price, further enhancing the holders' confidence. confidence. Just as NFTs on new public chains such as Solana often do not develop as well as Ethereum NFTs, for a new early-stage asset, liquidity is too good and participants can easily exit at a low price, which may not be a good thing for the project.
In the middle and late stages, its divisibility as a "token" also allows it to be split into smaller units for trading; and it can also be listed on Binance's large centralized exchange. When it is actually listed on If you own the currency, there will be almost no difference between it and other tokens from the perspective of exchange users. This kind of divisibility and liquidity that adapts to the project development stage is something that NFT does not have, and it is also the real killer feature of BRC-20. During the NFT bull market, many people suffered from the fact that the unit price of the leading NFT was too high to participate, and the various "NFT liquidity solutions" have not been truly universally mature so far. If viewed from this perspective, BRC-20 can be regarded as an NFT with its own "fragmentation" solution.
Other asset protocols derived from Ordinals
After the BRC-20 ecological explosion, many people believed that BRC-20 did not release Odinals itself and could be improved to support more functions. Therefore, many asset protocols named with similar structures and based on the Ordinals protocol appeared, for example as follows:
ORC-20: This protocol can be regarded as an improved version of BRC-20, mainly optimizing the existing problems of BRC-20, such as its limited name space, the problem of unchanged maximum supply, and the potential risk of "double spending" wait.
BRC-420: This protocol is also based on Ordinals, but it mainly supports more types of assets, and can be engraved on the chain with 2D pictures or even 3D asset models. In addition, BRC-420 also introduces a royalty function, allowing creators to share the subsequent profits from their works. The BRC-420 protocol is still in a stage of continuous improvement, and the relevant infrastructure is not yet mature, but it can carry more things and has a higher upper limit.
BRC-20 consensus split within Web3 community
In 2021-2022, Mass Adoption (adopted by the public) will be one of the largest mainstream narrative frameworks of Web3. Under this narrative framework, various new public chains, cross-chain solutions, Ethereum expansion solutions, and modular blockchain solutions They emerged one after another and received the most attention. At that time, due to its efficiency issues and application load issues, Bitcoin seemed to have faded out of the mainstream Web3 community's vision, and was regarded as an old thing that only the OGs of the previous era paid attention to.
The popularity of BRC-20 in 2023 and the rise of the Bitcoin ecosystem are actually a torture of "what is the essence of Web3". After all, the asset issuance method of BRC-20 mainly serves Web3 retail investors. It is "reversing the track" in terms of technology and efficiency. It has nothing to do with the narrative of Mass Adoption. It seems to further confirm the idea that "Web3 is essentially a casino." A cynical perspective. Some community members have begun to question the concepts of Web3 and Mass Adoption themselves, believing that it would be better to return to the Crypto narrative industry.
For investors who are particularly interested in the fundamentals of the project, its value to the industry, and the potential of Mass Adoption, it is often difficult to convince themselves to truly participate in BRC-20 and derivative protocols, and they are more willing to pay attention to other relatively "fundamental and more fundamental" issues at the moment. "Solid" hotspots, such as DePIN and Solana Ecosystem. To this day, relevant discussions continue.




