ORC-20
Ask or search…
⌃K
Comment on page

About ORC-20

Open token standard for Bitcoin ordinal and wider use cases
Please read this document and make sure you understand everything before testing. Use at your own risk.

Introduction

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 and BRC-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.
brc-20
brc-20 experiment
What is BRC-20?

Concept of ORC-20

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.
​
Features
BRC-20
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.
​

How can ORC-20 save Bitcoin block space during transaction processes?

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)
ORC-20 Cash System
BRC-20 Account System
BRC-20 Account System
​

Quick Start

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.
​

Full Operations

Operations 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.
​

Migration from BRC-20

A 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.
​
​
​

Resources

Creator of ORC-20, Orc DAO
Send 🧡 to Taproot Address 🟠🪄
  • bc1pu87fq5avl45dlzrclejnp4l96rq3rxx75ta0kgq5wqpnuj64lfys460nnf
  • We thank all contributors that help push ORC-20 forward.
​
Community Projects
​
ORC-20 Trackers
​
ORC-20 Indexers
​
Inscription services
​
BRC-20 Indexer Code Example by Shep
BRC-20 tracker
​
​
​
Last modified 4mo ago