Interpreting ORC-20 Tokens: A New Token Issuance Standard in the Ordinals Ecosystem
TechFlow Selected TechFlow Selected
Interpreting ORC-20 Tokens: A New Token Issuance Standard in the Ordinals Ecosystem
ORC20 removes some restrictions of BRC20 and defines additional operations.
Navigating Web3 tides with focused insights*TechFlow is authorized by xiyu to republish this article
In ordinals, any inscription minted and interpreted using JSON most likely treats inscriptions as disposable paper, carrying inherent risks of over-reliance on centralized services.
1. Background
BRC20 has many limitations, including being restricted to four-character ticker symbols, lack of upgradability, double-spending risks, and inability to cancel transactions. ORC20 aims to remove these restrictions—it’s essentially a hard fork of BRC20. This pattern might sound familiar; it's the classic BTC ecosystem approach of forking.
2. What is ORC20?
ORC-20 is an open standard designed to enhance the functionality of ordinal-based tokens on the Bitcoin network, improving upon the popular BRC-20 token standard. ORC20 maintains backward compatibility with BRC-20 while increasing adaptability, scalability, and security, eliminating the possibility of double spending.
3. Changes in ORC20
3.1 Initial supply and maximum minting amount can now be changed. I wouldn’t call this progress—fixed initial and total supply were never flaws. ORC20 simply makes token issuance on ordinals more flexible. Fixed versus flexible is merely a design choice, not inherently good or bad.
3.2 No fixed restriction on namespace—arbitrary-length names are allowed. Naming was indeed a pain point, especially given that most four-letter BRC20 tickers have already been claimed.
3.3 Uses the UTXO model to prevent double spending during transactions. You can look up “UTXO model” yourself—it refers to how, when sending a transaction, the remaining balance is sent back as change to a change address. This mechanism helps mitigate double-spending issues.
For example, splitting 10,000 ORC tokens with ID 1 into two separate transfers to a recipient address. Each transaction must have a unique nonce. Step 1: Send 1,000 tokens to the recipient (with nonce 5). Step 2: Record a send event back to the sender to return the remaining balance (with nonce 6). The transaction is only considered complete after the change is successfully returned.
3.4 Allows cancellation of transactions using "op": "cancel", which cancels a transaction associated with a specific nonce.
3.5 Allows existing BRC20 tokens to migrate to ORC20. Only the original deployer of the BRC20 token can initiate such a migration.
4. New Rules in ORC20
4.1 ID identifier, default value is 1. The identifier must be unique among ORC-20 tokens sharing the same identifier. If two ORC-20 tokens have the same identifier and ID, the “first principle” applies—the second one is invalid.
4.2 Nonce is a unique identifier associated with each transaction, allowing senders to track partial transactions. By including a nonce in every transaction, senders ensure each partial transfer is unique and cannot be accidentally or maliciously duplicated, which would compromise security. With nonce, senders can also specify which particular partial transaction to cancel via a cancellation command. This adds extra security and flexibility to the ORC-20 standard.
4.3 "op": "cancel"—an operation to cancel a specific partial transaction.
4.4 ug field: Upgradable?: true or false, default is true. Allows the deployer to upgrade the ORC-20 contract later.
4.5 wp field: Migratable?: true or false, default is false. Used solely for token migration and is irreversible. Only the original BRC-20 deployer can trigger a migration event. The wrapper copies the original BRC-20 metadata, such as maximum supply and minting limits.
4.6 Version: Version number: Useful when upgrading ORC-20. Typically, the version number should be incremented with each upgrade, helping identify different contract versions and facilitating future development, management, and usage.
4.7 msg: Message: Custom text, message, or declaration, of arbitrary size. This field can convey information about the token—its purpose, vision, use cases, etc.—helping users better understand the token’s value and utility, thereby enhancing credibility.
4.8 Custom Key. For custom implementations only, e.g., tax—mandatory transaction fee, royalties; minter—special minting address; image—token image; tkid—token ID; url—URL for token information.
These optional fields allow customization for special token needs, extending functionality beyond the standard ORC-20 protocol. For instance, tax could impose a fee on every transaction, royalties could pay creators, and minter could designate privileged addresses for minting rights.
5. Limitations of ORC20
5.1 Complexity: Simplicity can be a virtue within Bitcoin’s ordinals ecosystem. However, building upon BRC20’s already complex token issuance model, ORC20 adds further complexity. More definitions and cumbersome operations introduce new risks—for example, migration may result in two versions of the same token circulating simultaneously.
5.2 Centralization: The purpose of using JSON is to enable easy indexing and retrieval, which inevitably relies on centralized services. This is a fundamental weakness shared by all non-NFT applications in the current ordinals ecosystem.
5.3 Mandatory Royalties: Essentially enforces royalty payments within trading rules. Imposing royalties on tokens seems misguided. For NFTs—as art pieces—it makes sense for buyers to pay royalties to creators, reflecting a creator-user relationship. But for tokens, holders are more like investors who fund projects; requiring them to pay ongoing royalties back to project teams seems unreasonable.
5.4 Path Dependency: From its design, we see ORC20 moving Bitcoin token standards closer to ERC20. But then comes the question: why not just use ERC20?
6. Conclusion
In short, ORC20 removes some restrictions of BRC20 and defines additional operations.
The real competitive edge for issuing tokens on ordinals lies not in the standard itself, but in centralized services. Only when full verification loops are secured entirely on-chain can centralized risks be avoided.
The core issue with BRC20 isn't excessive limitations—it's reliance on centralized infrastructure. ORC20 fails to solve this. Instead, ORC20 treats BRC20 as a competitor aiming to capture market share. While ORC20 doesn't significantly impact the broader ordinals ecosystem, its effect on BRC20 remains limited as well.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
xiyu
