Original title: " ORC-20 Token Interpretation: New Token Issuance Rules in the Ordinals Ecosystem "
Original source: @ohxiyu
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.
brc20 has many restrictions, these restrictions include only four characters As a currency name, it cannot be upgraded, double-spending risks, transactions cannot be canceled, etc. The purpose of orc20 is to remove these restrictions, which can be said to be a hard fork of brc20. Is it a bit familiar to see here, the bifurcation model inherited from the btc ecological ancestors.
ORC-20 is an open standard designed to enhance the functionality of ordered tokens on the Bitcoin network, improving on the popular BRC- 20 Ordered Token Standard. orc20 is backward compatible with BRC-20 and improves adaptability, scalability and security, eliminating the possibility of double consumption.
3.1 The initial supply and maximum coinage can be changed. I don't think this is an improvement, fixed initial supply chain volume and total volume is not a disadvantage. orc20 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 There is no fixed limit to the namespace, and names of any size can be used. Naming is a real pain point, especially since the vast majority of brc20 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 10000 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 events to the receiver by recording, send 1000 to the receiving address (nonce is 5), step 2: send events to the sender by recording, send the remaining balance back to the sender (nonce is 6), only when the remaining balance The transaction cannot be completed until the sending is complete.
3.4 It is allowed to cancel the transaction, use "op": "cancel", you can cancel the nonce transaction.
3.5 Allow deployed brc20 coins to transfer to orc20. Only the deployer of brc20 can operate the transfer command.
4.1 id identifier, 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 part 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 deployers to subsequently upgrade 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 deployers 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 info.
These optional fields can be used to customize the needs of special tokens, extending 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.1 Complicated, ordinals based on Bitcoin ecology, simple It can also be regarded as an advantage, but on the basis that brc20 complicates the issue of currency issuance, orc20 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, retrieval will inevitably use centralized services, which is also the current Ordinals ecology, in addition to nft other applications Natural disadvantages.
5.3 Mandatory royalties, probably put the form of royalties collected 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 on the 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, through interpretation, we can see that what orc20 is doing is to send bitcoin e closer to rc20. Then a question arises, why not use erc20?
Summary in one sentence, orc20 has canceled some restrictions of brc2 0, And defines more operations.
In fact, the core competitiveness of Ordinals is the centralized service, 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 brc20 is not too many restrictions, but centralized dependence. orc20 does not solve this problem, orc20 regards brc20 as a competitor, and its goal is to seize the market. orc20 has little impact on the Ordinals ecology, but has limited impact on brc20.
Original source a>
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia