Interpretation of ORC-20 Tokens: New Token Issuance Rules in the Ordinals Ecosystem

Author: xiyu

In ordinals, anything minted and interpreted using JSON is likely treated as scrap paper, posing a risk of over-reliance on centralized services.

1. Background

BRC-20 has many limitations, including the requirement to use four characters as the coin name, inability to upgrade, double-spending risks, and inability to cancel transactions. The purpose of ORC-20 is to eliminate these restrictions, which can be seen as a hard fork of BRC-20. Does this sound familiar? It's the inherited fork model of the BTC ecosystem.

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 increases adaptability, scalability, and security, eliminating the possibility of double spending.

3. Changes in ORC-20

3.1 The initial supply and maximum minting amount can be changed. I don't consider this an advancement; fixing the initial supply and total amount is not a drawback. ORC-20 simply makes the issuance of ordinals more flexible; fixed and flexible are just options, unrelated to good or bad.
3.2 There are no fixed restrictions on naming; names of any size can be used. Naming is indeed a pain point, especially since most four-letter words in BRC-20 have already been minted.
3.3 The UTXO model ensures that there is no double spending during transactions. What is the UTXO model? You can search for it yourself; it means that when sending a transaction, the balance is also treated as a transaction sent to the change address. This can appropriately address the double spending issue.

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

3.4 Transactions can be canceled using "op": "cancel" to cancel the transaction with the specified nonce.

3.5 BRC-20 coins that have already been deployed are allowed to transfer to ORC-20. Only the deployer of BRC-20 can operate the transfer command.

4. New Rules in ORC-20

4.1 ID identifier, default is 1. The identifier must be unique among ORC-20s sharing the same identifier; if there are two ORC-20s with the same identifier and ID, the "first principle" applies, making the second ORC-20 invalid.

4.2 Nonce is a unique identifier associated with each transaction, allowing the sender to track its 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 duplicated, otherwise jeopardizing the security of the transaction. With the nonce, the sender can also specify the corresponding nonce when sending a cancel transaction to cancel a specific partial transaction. This adds extra security and flexibility to the ORC-20 token standard.

4.3 "op": "cancel" to cancel a specific partial transaction.

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

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

4.6 Version: When upgrading ORC-20, this is useful information. Typically, the version number should be updated with each upgrade, helping to identify different versions of the contract for easier subsequent development, management, and use.

4.7 msg: Custom text, message, or declaration of arbitrary size. This field can be used to provide information about the token, such as its purpose, vision, use cases, etc. This helps users better understand the value and use of the token, increasing its credibility.

4.8 Custom Key. Used only for custom implementations, such as tax - mandatory transaction tax, royalties; minter - special minting address; image - token image; tkid - token ID; url - URL for token information.
These optional fields can be used to customize special token needs, extending special features not provided in the standard ORC-20 protocol. For example, taxes can be used to charge a fee for each transaction, and royalties can be used to charge original creators for their works. The minter can specify a special address to grant minting permissions for tokens.

5. Limitations of ORC-20

5.1 Complexity, based on the Bitcoin ecosystem of ordinals, simplicity can also be seen as an advantage, but on the basis that BRC-20 complicates the issuance of coins, ORC-20 further complicates it. More definitions and cumbersome operations can easily lead to more problems. For example, migration operations result in two coins.

5.2 Centralization, the purpose of using JSON is to facilitate retrieval, which inevitably involves centralized services. This is also a natural drawback of the current ordinals ecosystem, aside from NFTs.

5.3 Mandatory royalties essentially embed the form of collecting royalties in the trading market into the rules. I believe that imposing royalties on coins is something the authors have not fully considered. As NFTs, their inherent attribute is art; paying royalties to artists is understandable, as the authors and holders are concerned with creation and usage. However, for coins, holders should be more like investors; it seems unreasonable for investors to pay royalties to the project while also investing money in it.

5.4 Path dependence, through interpretation, we can see that ORC-20 is moving closer to ERC-20 in terms of issuing coins on Bitcoin. This raises the question of why not use ERC-20?

6. Conclusion

In summary, ORC-20 removes some of the restrictions of BRC-20 and defines more operations.

In fact, the core competitiveness of issuing coins on ordinals lies in centralized services, not this standard. Only by forming a closed-loop certification on-chain can the risk of centralization be prevented.

The biggest problem with BRC-20 is not that there are too many restrictions, but rather the reliance on centralization. ORC-20 does not solve this problem; it treats BRC-20 as a competitor, aiming to capture the market. ORC-20 has little impact on the ordinals ecosystem, but its influence on BRC-20 is also limited.