About ORC-20
Open token standard for Bitcoin ordinal and wider use cases
Last updated
Open token standard for Bitcoin ordinal and wider use cases
Last updated
Please read this document and make sure you understand everything before testing. Use at your own risk.
ORC-20 is an open token standard for Bitcoin ordinals, created by OrcDAO, to enhance some of the key features of BRC-20. It is aimed to be backward compatible with BRC-20, to improve adaptability, scalability, and security, and to eliminate the possibility of double spending. However, ORC-20 is an experimental project and there is no guarantee that the tokens created with this standard will have any value or utility. Therefore, users should exercise caution and do their own research before using ORC-20.
Ordinals are digital artifacts introduced by Rodarmor. It can carry various types of data on Bitcoin network.
BRC-20 is token standard by Domo. Tokens can be deployed, minted, and transferred using Ordinal inscriptions.
Designed for wider adoption of ORC-20 ordinal:
Deploy new ORC-20 or migrate existing BRC-20 with deploy event
Mint ORC-20 tokens with mint event
Send ORC-20 tokens with send event
Cancel ORC-20 partial transaction with cancel event
Upgrade existing ORC-20 (eg. supply and max mint) by upgrade event
Important: Deploy ORC-20 by explicit declaration (recommended), or by default. Any ordinal fungible tokens which implement ORC-20 standard can be considered as ORC-20.
Built-in anti-double-spending
❌ Difficult to index
✅ UTXO-like
Allow passing initial mint (proxy mint)
❌ Limit to minter
✅ Track initial balance
Flexible naming space
❌ 4 Letter
✅ Any Size
Custom keys, eg. tax, msg, url
❌ Fixed keys
✅ Flexible keys
Allow upgrade: max, lim
❌ Non-upgradable
✅ Upgradable
Allow partial tx and cancellation
❌ Immutable
✅ Partial tx
Allow migration: BRC-20 ➡️ ORC-20
✅ Migrate to ORC-20
✅ Migration Wrapper
Limitation of current of BRC-20:
Supply and max per mint is immutable after the first deployment
Naming space is limited to 4 digits with "First is first" approach
"Inscribe Transfer" and "bookkeeping" heavily rely on external centralized indexers result in potential "double-spending"
Secure transactions with proposed improvements:
Allow token identifier in the deploy event, differentiating ORC-20 with the same ticker. Tickers have no constraints in size.
ORC-20 are by default in JSON format and can potentially support a wider range of formats consists of key-value pairs. All ORC-20 data are case-insensitive.
The initial minted amount must be kept in the minter's address until the first send transaction is made. However, you can mint and pass it (send the ordinal) to different addresses as long as the sent event is not inscribed. The new address will inherit the full amount upon receiving the mint ordinal. It allows marketplaces to implement ORC-20 without code break.
Transaction model is based on the UTXO model. In each transfer, the sender specifies the amount to be received by the receiver and the remaining balance to be sent to the sender.
Any send transaction without sending all remaining balance is partial transaction.
A send transaction can transfer amount to multiple receivers.
Each send event (except self-transacting) must always explicitly specify the amount to be sent.
Send the remaining balance to the sender in the last step to complete a transaction. By default, it will send all remaining amount back to the sender without specifying amount. (After OIP-10, "Send Remaining Balance" will be deprecated.)
Upon the completion of each transaction the previous inscribed balance will be no longer in a valid state hence adopting UTXO model.
In addition, each send event can include nonce. Sender can cancel a partial transaction by specifying nonce.
Unlike BRC-20 requires a "one time transfer inscription" in each transaction, ORC-20 allows you to re-use the "mint" and "send" ordinal inscriptions in a transaction.
To send funds you have 3 options:
Option A. send "mint inscription” ordinal directly to receivers (instead of inscribing “transfer”) as long as the balance of the original mint inscription is not spent.
Option B. send “send inscription” ordinal directly to receivers as long as the balance of the initial “send” inscription is not spent
Option C. Initiate a new “send” transaction process as following (Before OIP-10):
Step 1: Inscribe “send” amount to sender’s address
Step 2: Inscribe “send” remaining balance to sender’s address (Before OIP-10)
Step 3: Send the “send inscription” ordinal inscribed in Step 1 directly to receiver Note: receiver's balance will instantly add the valid amount, subsequent transactions can re-use the received inscriptions
ORC-20 Cash System (After OIP-10)
BRC-20 Account System
You can quickly get started with ORC-20 by inscribing deploy, mint, send and cancel events. Transactions of ORC-20 are simple, flexible, and robust.
Quick StartOperations of ORC-20 include deploy, mint, send, cancel, upgrade, and custom events. You can add new keys to the standard event to introduce constraints, various behaviours, or new operations.
OperationsA wrapper ordinal is a special type of ordinal that can migrate other ordinal token standards, such as from BRC-20 to ORC-20. To migrate your existing BRC-20 tokens, you need to deploy a wrapper ordinal that can convert them. Only the deployer of the BRC-20 can make the migration.
MigrationCreator of ORC-20, Orc DAO
Send 🧡 to Taproot Address 🟠🪄
bc1pu87fq5avl45dlzrclejnp4l96rq3rxx75ta0kgq5wqpnuj64lfys460nnf
We thank all contributors that help push ORC-20 forward.
Community Projects
OrdSociety - ORC20 DAO Community formed by builders, VCs and early adopters
BitOrcs - Ordinal projects created by top artists from ORC-20
ORC-20 Trackers
Rankings: https://loveords.com/orc20
ORC-20 Indexers
Inscription services
BRC-20 Indexer Code Example by Shep
BRC-20 tracker
