Written by: xiyu

https://docs.orc20.org/

Among ordinarys, anyone who uses JSON to cast inscriptions and then interprets them is likely to use the inscriptions as toilet paper, and there is a risk of over-reliance on centralized services.

1. Background

BRC20 has many restrictions, including only four characters can be used as the currency name, cannot be upgraded, double-spending risk, cannot cancel transactions, etc. The purpose of orc20 is to remove these restrictions, which can be said to be a hard fork of BRC20. Does it look familiar to you? This is the fork model inherited from the BTC ecosystem.

2.What is orc20?

ORC-20 is an open standard designed to enhance the functionality of ordered tokens on the Bitcoin network to improve the popular BRC-20 ordered token standard. ORC-20 is backward compatible with BRC-20 and improves adaptability, scalability, and security, eliminating the possibility of double spending.

3. Changes to orc20

3.1 The initial supply and maximum minting amount can be changed. I don’t think this is an improvement. Fixed initial supply and total amount are not disadvantages. Orc20 just makes ordinarys more flexible in terms of coin issuance. Fixed and flexible are just a choice, not good or bad.

3.2 The namespace has no fixed limit, and you can use any size of name. Naming is indeed a pain point, especially when most of the brc20 four-letter words have been minted in advance.

3.3 Use the UTXO model to ensure that there is no duplicate consumption during the transaction process. You can search for what the UTXO model is. When sending a transaction, the balance will also be sent to the change address as a transaction. This can properly solve the double-spending problem.

For example, 10,000 ORC with ID 1 is divided into two parts and sent to the receiving address. Each transaction must have a unique nonce. Step 1: Send 1000 to the receiving address by recording the send event to the receiver (nonce is 5), Step 2: Send the remaining balance back to the sender by recording the send event to the sender (nonce is 6), and the transaction can only be completed after the remaining balance is sent.

3.4 Allow transaction cancellation. Use "op": "cancel" to cancel the nonce transaction.

3.5 Allow the transfer of deployed brc20 coins to orc20. Only the deployer of brc20 can operate the transfer command.

4. New rules added by orc20

4.1 id identifier, default is 1. The identifier must be unique between ORC-20s that share the same identifier. If there are two ORC-20s with the same identifier and the same ID, the "first come, first served" rule applies and the second ORC-20 is invalid.

4.2 A nonce is a unique identifier associated with each transaction that allows a sender to track their partial transactions. By including a nonce in each transaction, the sender can ensure that each partial transaction is unique and cannot be accidentally or maliciously copied, which would compromise the security of the transaction. With a nonce, the sender can also specify the corresponding nonce when sending a cancel transaction to cancel a specific partial transaction. This adds additional security and flexibility to the ORC-20 token standard.

4.3 "op": "cancel", cancel a part of the transaction.

4.4 ug field, whether it is upgradeable: true or false, the default value is true. Allows the deployer to upgrade ORC-20 later.

4.5 wp field, migration: true or false, default value is false. Used for token migration purposes and is irreversible. Only the deployer of the original BRC-20 can deploy migration events. The wrapper copies the metadata of the original BRC-20, such as the same maximum supply and issuance limit.

4.6 Version: Version: It is useful information when upgrading ORC-20. Generally, the version number should be updated for each upgrade, which helps to identify different versions of the contract, thus facilitating subsequent development, management, and use.

4.7 msg: Message: Custom text, message or manifesto, can be of any size. This field can be used to provide information about the token, such as the purpose, vision, usage scenarios, etc. This helps users better understand the value and purpose of the token and increases the credibility of the token.

4.8 Custom Key. Only used for custom implementations, such as taxes - mandatory transaction taxes, such as royalties; minters - special minting addresses; images - token images; tkid - token IDs; urls - URLs for token information. These optional fields can be used to customize the needs of special tokens and expand on special functions not provided in the standard ORC-20 protocol. For example, taxes can be used to charge a certain fee on each transaction, royalties can be used to charge the original creator for the work, etc. Minters can specify special addresses to grant permission to mint tokens, etc.

5. Limitations of orc20

5.1 Complexity. Based on the ordinarys of the Bitcoin ecosystem, simplicity can be seen as an advantage. However, on the basis of BRC20 complicating the issue of coin issuance, ORC20 has made it even more complicated. More definitions and cumbersome operations can easily lead to more problems. For example, the migration operation results in two copies of the coin.

5.2 Centralization. The purpose of using JSON is to facilitate retrieval. Retrieval will inevitably use centralized services. This is also the natural disadvantage of other applications in the current ordinarys ecosystem except NFT.

5.3 Mandatory royalties are probably putting the form of collecting royalties in the trading market into the rules. I think the author didn’t think clearly about collecting royalties on the coin. As an NFT, its own attribute is a work of art. It is understandable to pay royalties to artists. The author and the holder are the creators and users. But on the coin, the holder should be more like an investor. Investors invest money in the project and have to pay royalties to the project party. This seems unreasonable.

5.4 Path Dependence, through interpretation, we can see that what orc20 is doing is to bring bitcoin issuance e closer to rc20. Then a question arises: why not use erc20?

6. Summary

In short, orc20 removes some of the restrictions of brc20 and defines more operations.

In fact, the core competitiveness of issuing coins on ordinarys is centralized services, not this standard. Only when the closed-loop certification is placed on the chain can the risk of centralization be prevented.

The biggest problem of brc20 is not that it has too many restrictions, but that it relies on centralization. Orc20 has not solved this problem. Orc20 regards brc20 as a competitor, and its goal is to seize the market. Orc20 has no impact on the ordinarys ecosystem, but its impact on brc20 is also limited.