Disclaimer: This is a proposal for a new Convention Of Usage.
Convention Proposition. Read every word if you decide to test. This will be worthless. Play at your own risk :-)
Cy[bord] CBRC-20 is the proposal of an efficient Metaprotocol standard for fungible tokens on Bitcoin through Ordinals. By utilizing the newmetadata
andmetaprotocol
fields introduced in ord 0.10+, which allow for arbitrary properties to be stored directly within the Inscription envelope, CBRC-20 keeps the same functional logic of the BRC-20 Metaprotocol while reducing the cost of each inscription and simplifying the indexing process.
Before we cover the CBRC-20 Metaprotocol Convention, let’s first take a moment to understand what ametaprotocol
is.
"Metaprotocol" is a term used by the Ordinals Community to describe an interactable "protocol" formalized through off-chain indexing of on-chain information, like BRC-20, SNS, Bitmap, etc. Until recently, an "Ordinal metaprotocol" was a conceptual term not officially recognized in the Ordinal client. This changed with ordv0.10, when the Ord Team introduced fields for writingmetaprotocol
andmetadata
information directly in the inscription envelopes. This update allows for the official flagging of Metaprotocols on Ordinals.
For Ordinal Metaprotocol token standards, the journey has been complex. To address issues arising post-ord v0.9, all BRC-20 indexers have decided to "freeze" on ord v0.9 for BRC-20 indexing. This means that BRC-20cannotleverage the "metaprotocol" or "metadata" fields introduced in the latest versions of ord 0.10+, hindering the BRC-20 Metaprotocol's ability to upgrade and become more efficient. As a result, the future of BRC-20 Indexing is stuck in a state of uncertainty, despite market perceptions.
CBRC-20, on the other hand, fully utilizes both the "metaprotocol" and "metadata" field features for token data, leading to significant savings in inscription fees and blockspace. This efficiency is achieved as there are no JSON files inscribed on Bitcoin for CBRC-20, positioning it as the first "real" Ordinals Metaprotocol token standard (according to the latest rules and version of the ord client).
Now let’s get into what CBRC-20 looks like!
The Ordinal Envelope is a fundamental component of the Ordinals protocol, enabling the unique capability to embed data on individual satoshis within the Bitcoin blockchain. It plays a vital role in creating distinctive digital assets directly on Bitcoin.
Let's take an example of an Ordinal Envelope containing the message "Hello, world!" to understand its structure and function:
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 1
OP_PUSH "text/plain;charset=utf-8"
OP_PUSH 0
OP_PUSH "Hello, world!"
OP_ENDIF
Header (OP_FALSE OP_IF … OP_ENDIF
): Acts as a foundational structure for the envelope. It sets up the conditional execution framework, although it primarily serves as a non-operational or 'no-op' component.
Identifier (OP_PUSH "ord"
): What we call the "magic code," this identifier is crucial for distinguishing Ordinal inscriptions (or other protocols) from other data on the blockchain.
Content Specification (OP_PUSH "text/plain;charset=utf-8"
andOP_PUSH "Hello, world!"
): These lines define the MIME type of the content (in this case, plain text with UTF-8 charset) and the actual content to be inscribed.
To push the Ordinal community in a good direction, the developers of the Ordinals protocol, in version 0.10+, have integrated CBOR as a key component. This integration permitsmetadata
to be inscribed in Ordinal Envelopes using the CBOR format, which is very efficient as CBOR data is 60%-70% smaller in byte size than equivalent data in JSON format.
This inclusion of themetaprotocol
field and the usage of CBOR for storingmetadata
in the Ordinal envelope also significantly enhances data handling efficiency for Indexers. These choices allow for more compact and rapid processing of token-related data. As a result, the Ordinal envelope becomes not just a container, but a robust tool for sophisticated data interactions within the Bitcoin blockchain.
These advancements in the Ordinal envelope pave the way for more dynamic and versatile usecases. Developers can now leverage these improvements to create more nuanced and efficient token-based solutions, further expanding the capabilities of the Bitcoin network. You can read more about CBOR and metadatahere.
In the world of CBRC-20,metaprotocol
is a property defined in the ordinal framework (specifically in ord v0.10+), and serves as a field that can carry a "metaprotocol" or "community convention", as well as its metaprotocol operational codes. CBRC-20 is the first proposed standard to utilize this field and definition ofmetaprotocol
properly.
We use themetaprotocol
field in line with theUniform Resource Name standard, adhering to this syntax:
<metaprotocol>:[op]:[tick]=[amt]
For example, a CBRC-20 mint inscriptionmetaprotocol
field would look like this:
cbrc-20:mint:BORD=1000
And a CBRC-20 transfer inscriptionmetaprotocol
field would look like this:
cbrc-20:transfer:BORD=500
The CBRC-20metaprotocol
rules follow directly with BRC-20, meaningCBRC-20 tokens adhere to the exact same rules as the BRC-20 token standard(such as the First is First principle, 4-character names, default decimal of 18, etc, you can read the existing BRC-20 ruleset outlinedhere)
However, for CBRC-20mint
andtransfer
inscriptions, there's no need to include the "p", "op", "tick" or "amt" characters whatsoever, as they are specifieddirectlyin the Ordinal Evelope. There is nometadata
required formint
ortransfer
inscriptions as we are simply signaling operational actions of an existing token,thus lowering the cost of CBRC-20 mint/transfer inscriptions compared to BRC-20/TAP. Metadata is onlyrequiredfordeploy
inscriptions.
Newly defined in the official ord client (ord >0.10),metadata
is a field designated for carrying arbitrary informationdirectlywithin an Ordinal Inscription envelope in the form of a CBOR file. You can read aboutmetadata
in ordinal envelopeshere.
In CBRC-20 the only timemetadata
isrequiredis when deploying a new CBRC-20 token. We will now go over some examples of what deploying, minting, and transferring CBRC-20 tokens looks like!
Read from here if you just want to play!
If you want to play with CBRC-20right nowbut don't have access to an ord 0.10+ client, we've got you covered :D
You can use theCBRC-20 EZ Crafterwe made soeveryonecan instantly PLAY!
TheCBRC-20 EZ Crafterallows for the inscribing of CBRC-20 deploy, mint, and transfer inscriptiondirectly in your browser with 0% fees(feel free to donate if you enjoy playing <3)
If you DO have an ord 0.10+ client running locally and want to inscribe in local, here's how CBRC-20 works!
Deploying a CBRC-20 token is a straightforward process:
{
"tick": "BORD",
"max": "21000000",
"lim": "1000",
"dec": "8"
}
After saving your JSON file, use the Cy[bord] JSON to CBOR converter to create your .cbor file.
You can inscribe the BORD token using this command:
ord wallet inscribe --fee-rate FEE_RATE --metaprotocol=cbrc-20:deploy --cbor-metadata ./deployBORD.cbor --file <literallyanyfile>
Minting a CBRC-20 token is very easy.
Choose any file you want to inscribe (cheapest option is a txt file containing only the number0
).
Execute the minting process with the following command:
ord wallet inscribe --fee-rate FEE_RATE --metaprotocol=cbrc-20:mint:BORD=1000 --file <yourchosenfile>
This command will mint the specified amount of "BORD" tokens.
Choose any file you want to inscribe (cheapest option is a txt file containing only the number0
).
Use the following command to inscribe the transfer of your "BORD" tokens:
ord wallet inscribe --fee-rate FEE_RATE --metaprotocol=cbrc-20:transfer:BORD=500 --file <yourchosenfile>
This command will create a CBRC-20 transfer inscription which can then be sent to a Bitcoin address as a one-time use "ticket" to signify an ownership change of CBRC-20 tokens,exactly the same as the BRC-20 transfer inscription logic.
Summarized from this document, here are some of the key of advantages of CBRC-20 over BRC-20
Reduced Inscription Costs:
A Simplified Indexing Process:
Support for All MIME Types:
No Limitations of Ordinal Client:
metadata
andmetaprotocol
fields, allowing for more advanced and efficient token standard development.Innovative Token Interaction Possibilities:
Here you have it folks, the Cy[bord] CBRC-20 convention. A proposed alternative to BRC-20 standard that follows the exact same logic but in a more efficient/cheaper way thanks to ord 0.10+. The realization of “what could have been” for BRC-20 if Indexers did not decide to freeze to ord v0.9.
This is purely an experiment and should not be treated as an investment.
Let’s keep on finding new ways to play together :-)
BRC-20:A token standard for creating and managing fungible tokens on the Bitcoin blockchain, utilizing the Ordinals protocol for data inscription.
CBOR (Concise Binary Object Representation):A binary data serialization format that offers compact size and efficient data processing, used in the context of blockchain for efficient data storage and transmission. Similar to JSON, but more efficient.
Cy[bord] / CBRC-20:A proposed metaprotocol standard for creating and managing fungible tokens on Bitcoin, leveraging the Ordinals protocol. It aims to be more efficient and cost-effective than the traditional BRC-20 standard by using the newmetadata
andmetaprotocol
fields.
Metaprotocol (Term):A concept used to describe a protocol within a protocol, often referring to a set of standards or rules established on top of an existing blockchain protocol, like Ordinals.
Metaprotocol (Field):A specific field within the Ordinal envelope used to identify and distinguish different protocols or conventions within the blockchain, utilized in the CBRC-20 standard.
Metadata (Field):A field within the Ordinal envelope that carries arbitrary information, such as a token's deploy-related details, in a CBOR file format. This field plays a significant role in the CBRC-20 standard for storing token data efficiently.
MIME Type:A standard that indicates the nature and format of a document, file, or an assortment of bytes. It stands for Multipurpose Internet Mail Extensions and is used in CBRC-20 for flexibility in token operations.
Ordinal Envelope:A data structure within the Ordinals protocol, featuring extendable properties for storing and managing data related to Ordinal Inscriptions.
Ordinal Inscription:A feature of the Ordinals protocol allowing for the embedding of arbitrary data directly into Bitcoin transactions.
Uniform Resource Name Standard (URN):A protocol for assigning a unique and persistent name to resources. In the context of CBRC-20, it's used in themetaprotocol
field to adhere to specific naming conventions for protocol instructions.
Ordinals v0.10 Release: Detailed release notes of Ordinals version 0.10, which introduced themetaprotocol
andmetadata
fields, are availablehere.
Uniform Resource Name (URN) Standards: Learn more about the URN standards, crucial for themetaprotocol
field syntax in CBRC-20, atRFC 2141.
BRC-20 Token Standard Documentation: For insights into the BRC-20 token standard and its operational rules, visit theLayer 1 documentation.
Ordinals Inscriptions Metadata: A guide to understanding themetadata
field in ordinal envelopes can be foundhere.