Original author: xiyu (@ohxiyu)
Original source: SevenUp DAO
ORC-20 official document:https://docs.orc 20.org/
In ordinals, anyone who uses json to cast inscriptions and then interprets them is likely to use the inscriptions as straw paper, and there is a risk of over-reliance on centralized services.
1. Background
Brc 20 has many restrictions, these restrictions include only four characters can be used as the currency name, no upgrades, double spend risks, no cancellation of transactions, etc. The purpose of orc 20 is to remove these restrictions, which can be said to be a hard fork of brc 20. Is it a bit familiar to see here, the bifurcation model inherited from the btc ecological ancestors.
2. What is orc 20?
ORC-20 is an open standard designed to enhance the functionality of ordered tokens on the Bitcoin network, improving upon 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 consumption.
3. Changes in orc 20
3.1 The initial supply and maximum minting can be changed.
I don't think this is an improvement, fixed initial supply chain volume and total volume is not a disadvantage. Orc 20 just makes the form of ordinals more flexible. Fixed and flexible are just a choice, and it has nothing to do with good or bad.
3.2 Namespaces have no fixed limit and names of any size may be used.
Naming is a real pain point, especially since most of the brc 20 four-letter words have already been pre-minted.
3.3 Use the UTXO model to ensure that there is no repeated consumption during the transaction.
What is the utxo model? You can search for it yourself. Even when a transaction is sent, the balance will be sent to the change address as a transaction. This can properly solve the double spending problem,
For example, divide 10,000 ORC with ID 1 into two parts and send the transaction to the receiving address. Every transaction must have a unique nonce. Step 1: send event to receiver by recording, send 1000 to receiving address (nonce is 5), step 2: send event to sender by recording, send remaining balance back to sender (nonce is 6), only if remaining balance The transaction cannot be completed until the sending is complete.
3.4 Allow cancellation of transactions
Use "op": "cancel" to cancel the nonce transaction.
3.5 Allow the deployed brc 20 coins to be transferred to orc 20.
Only the deployer of the brc 20 can operate the transfer command.
4. Orc 20 new rules
4.1 id identification, the default is 1. Identifiers must be unique among ORC-20s that share the same identifier, if there are two ORC-20s with the same identifier and the same ID, the "first rule" applies, the second ORC-20 is invalid.
4.2 A nonce is a unique identifier associated with each transaction that allows a sender to track its parts of the transaction. By including the nonce in each transaction, the sender can ensure that each partial transaction is unique and cannot be copied accidentally or maliciously, which would compromise the security of the transaction. With the nonce, the sender can also specify the corresponding nonce to cancel a specific part of the transaction when sending the cancellation transaction. This adds additional security and flexibility to the ORC-20 token standard.
4.3 "op": "cancel", cancel the operation of a certain part of the transaction.
4.4 ug field, whether it can be upgraded: true or false, the default value is true. Allows the deployer to subsequently upgrade the ORC-20.
4.5 wp field, migration: true or false, the default value is false. It is used for the purpose of token migration and is irreversible. Only the deployer of the original BRC-20 can deploy migration events. This wrapper replicates the metadata of the original BRC-20, such as the same maximum supply and distribution limits.
4.6 Version: Version: It is useful information when upgrading ORC-20. Usually, the version number should be updated for each upgrade, which helps to identify contracts of different versions, thus facilitating subsequent development, management and use.
4.7 msg: message: custom text, message or manifesto, can be any size. This field can be used to provide information about the token, such as the token's purpose, vision, usage scenarios, etc. This helps users better understand the value and utility of the token and increases the credibility of the token.
4.8 Custom Key. For custom implementations only, e.g. tax - enforced transaction tax, such as royalties; minter - special minting address; image - token image; tkid - token ID; url - URL 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 a work, etc. Minters can designate special addresses to grant permission to mint tokens, etc.
5. Limitations of orc 20
5.1 Complexity
The simplicity of ordinals based on the Bitcoin ecology can also be regarded as an advantage, but on the basis that BRC 20 complicates the issue of issuing coins, ORC 20 further complicates it. More definitions and cumbersome operations are likely to bring more problems. For example, the migration operation brings two coins.
5.2 Centralization
The purpose of using json is to facilitate retrieval, which will inevitably use centralized services, which is also a natural drawback of other applications in the current ordinals ecosystem except nft.
5.3 Mandatory Royalty
Probably it is to put the form of collecting royalties in the trading market into the rules. I think the author did not understand the royalties on the currency. As an NFT, its own attribute is a work of art. It is understandable to pay royalties to artists. Authors and holders are the care of creation and users. But in terms of currency, the holder of the currency should be more similar to the investor. It seems unreasonable for the investor to invest money in the project and also pay royalties to the project party.
5.4 Path dependence, by interpretation
We can see that what orc 20 is doing is to send bitcoins closer to rc 20. Then a question arises, why not use erc 20?
6. Summary
In a word, orc 20 cancels some restrictions of brc 20, and defines more operations.
In fact, the core competitiveness of issuing coins on ordinals is centralized services, not this standard. Centralization risks can be prevented only if the certifications that form a closed loop are placed on the chain.
The biggest problem with brc 20 is not that there are too many restrictions, but that it depends on centralization. orc 20 does not solve this problem, orc 20 regards brc 20 as a competitor, and its goal is to seize the market. Orc 20 has little impact on the ordinals ecology, but it has limited impact on brc 20.
