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.


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.

What is Bitcoin Ordinal?

BRC-20 is token standard by Domo. Tokens can be deployed, minted, and transferred using Ordinal inscriptions.

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.


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)

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.

pageQuick Start

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.



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 updated