# BRC-1155 Standard

Author: Ivan Tsang (@ivantkf) Co-developers: aowu (@aowu2048), c00k1e (@lonelyhorseme), PD Latest: 2023-06-08 (v1.1.7) {Block Height 793,277} Created: 2023-03-13 (v1.0) \[Inscription 454318] {Block Height 780,684} Require: Ordinals {% embed url="" %} ## Vision > Be Your Own Bank. Inscription (NFT) is one of the ways to achieve Bitcoin-M instead of USD-M. When Ethereum NFTs have been shown up at the beginning, there was a moment when people were more focused on Ether ($ETH) than USD to reach Ether-M instead of USD-M, and that's what I am trying to achieve and promote to the general public. ## Mission > Track the direct path to success and avoid to walk along a wrong way. We have run for Ordinals to catch up with Ethereum by tracing its right path in just a few months. I am studying more standard protocols on Ethereum and seeing if they are possible to deploy on Bitcoin Core Network to expand the ecosystem of inscriptions. Then, we have our own way to go. The Ordinals Inscription here will be defined as similar to the ERC-721 protocol standard. ## Background > BRC-1155 Foundation (@BRC1155) The BRC-1155 Foundation has been established by the author and co-developers of the protocol on 22 May 2023 (Bitcoin Pizza Day). The organization will mainly support and help the project teams who are going to use the BRC-1155 protocol for Profile Picture (PFP), airdrop and so on. ## Purpose > Your next ownership of image inscriptions is not an image. What makes Ordinals inscriptions special is that the whole thing is inscribed on-chain. We have paid a lot of gas to inscribe some project items with the **SAME** images, but in order to achieve ownership of that image inscriptions, it is unnecessary to pay at least 5x (5 times), and even more than 10x (10 times) of extra gas for inscribing an image. After all, the image is just the appearance, the actual core value of Inscription is OWNERSHIP. ## Idea The concept is inspired by the brc-20 and ERC-1155 standards. The inscriptions with BRC-1155 standard are just another kind of Ordinals image inscriptions but replaced by code, they can be traded, collected, and transferred as usual. Meanwhile, we are currently building an official front-end website with the indexer of BRC-1155 standard for users to see their image inscriptions directly. To conclude the idea, you only need to inscribe the image on-chain once.

## Trading The inscription will be shown as the on-chain data on the wallet side, which means it is exactly what is inscribed. Yet, the concept of the BRC-1155 protocol is going to achieve the ownership of the image inscription, so that the actual appearance of the code inscription with the BRC-1155 protocol is an image, after all the root requirement of trading is supported by the ownership. Therefore, the trading experience should be as similar as usual instead of showing the code.

The above marketplace frontend is supported by Magic Eden On Bitcoin (@MEonBTC)

## Language {% hint style="info" %} {text/plain} and {application/json} are both supported {% endhint %} For traceability json {} is required, as well as the minimum required information to satisfy one of the functions. However, sometimes we will make some careless typo mistakes which inscribe an inscription with invalid JSON that causes unable to be searched by the indexer. The invalid one could be not considered as one of the valid BRC-1155 pieces of the original image inscription by the project. Hence, please ensure your JSON code is correct before creating an inscription by using the following online JSON tools for double-checking. {% embed url="" %} JSON tool with English {% endembed %} {% embed url="" %} JSON tool with Chinese {% endembed %} ## Introduction | Project Owner | Inscription Holders | All Users | | :-----------: | :------------------: | :-------: | | Deploy | Fractionalize (Soon) | Mint | | Burn | Burn | | | Mint | Mint | | | | Recovery (Soon) | | This is demonstrating what operations we can do above {deploy, burn, fractionalize, recovery, mint} by using the BRC-1155 standard, and the function structure below,

## Operations {% embed url="" %} A secret code should be set by using SHA-256 algorithm for safety and transperancy during the verification {% endembed %} ### 1.　Deploy The project owners could create a BRC-1155 collection of their inscriptions with a single image to inscribe the rules and save the cost. Here is a basic example below (replace the x), ``` { "p": "brc-1155", "op": "deploy", "abbrev": "xxxxxxxxxx", "inscription": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" } ``` {% hint style="danger" %} **An inscription with a picture MUST be inscribed before deploying the BRC-1155 standard** {% endhint %}

Key	Must?	Description
p	✅	Protocol: To identify and process BRC-1155 events
op	✅	Operation: Type of events {deploy, fractionalize, mint...}
abbrev	✅	Abbreviation: Set a max. 10 letters identifier with Case Sensitive
inscription	✅	Identifier inscription ID of the original image location
author	❌	Identifier of the project creator/ team with {.sats} domain
msg	❌	Extra message from the project creator/ team
max	❌	Set the total quantity in pieces of the operation, default to "∞"
lim	❌	Limit: Set the fixed amount in every inscription, default to "1"
vfy	❌	Verify: Encrypted by SHA-256 Algorithm for a further action

### 2.　Inscribe (Mint) All users are allowed to inscribe different quantities of the inscriptions with BRC-1155 standard to collect a valid piece of the expensive inscriptions at an affordable price until it reaches the maximum quantity. The reminding available quantity is only valid according to a first-come-first-served basis. Here is a basic example below (replace the x), ``` { "p": "brc-1155", "op": "mint", "abbrev": "xxxxxxxxxx", "inscription": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" } ``` {% hint style="danger" %} **Stay alert for scammers and focus on the maximum inscription number.** {% endhint %}

Key	Must?	Description
p	✅	Protocol: To identify and process BRC-1155 events
op	✅	Operation: Type of event {deploy, fractionalize, mint...}
abbrev	✅	Abbreviation: Set a max. 10 letters identifier with Case Sensitive
inscription	✅	Identifier inscription ID of the original image location
author	❌	Identifier of the project creator/ team with {.sats} domain
msg	❌	Extra message from the minter
atm	❌	Amount to mint in an inscription, default to {deploy} setting
txt	❌	Write a short message on the inscription

### 3.　Burn The project owners / Fractionalized creators could burn inscriptions / fractionalized pieces within the BRC-1155 collections by connecting {deploy} with the verify code if it contains too many uninscribed inscriptions to decrease the total supply or achieve deflation or even further situations in various activities. Here is a basic example below (replace the x), ``` { "p": "brc-1155", "op": "burn", "abbrev": "xxxxxxxxxx", "inscription": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "vfy": "xxxxx" } ``` {% hint style="danger" %} **An {deploy} MUST be inscribed before deploying the {burn} action to connect the {vfy}** {% endhint %}

Key	Must?	Description
p	✅	Protocol: To identify and process BRC-1155 events
op	✅	Operation: Type of events {deploy, fractionalize, mint...}
abbrev	✅	Abbreviation: Set a max. 10 letters identifier with Case Sensitive
inscription	✅	Identifier inscription ID of the original image location
author	❌	Identifier of the project creator/ team with {.sats} domain
msg	❌	Extra message from the project creator/ team
vfy	✅	Verify: Encrypted and show the last 5 digits by SHA-256 Algorithm

### 4.　Fractionalize (Not Yet Support) The holder of each BRC-721 inscription could fractionalize to separate a BRC-721 Inscription into many pieces to save the inscribing cost by inscribing **WITHOUT** the duplicated images. Here is a basic example below (replace the x), ``` { "p": "brc-1155", "op": "fractionalize", "abbrev": "xxxxxxxxxx", "inscription": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" } ``` {% hint style="danger" %} **This operation is ONLY available for the inscriptions with the BRC-721 standard.** {% endhint %}

Key	Must?	Description
p	✅	Protocol: To identify and process BRC-1155 events
op	✅	Operation: Type of events {deploy, fractionalize, mint...}
abbrev	✅	Abbreviation: Set a max. 10 letters identifier with Case Sensitive
inscription	✅	Identifier inscription ID of the original image location
author	❌	Identifier of the project creator/ team with {.sats} domain
msg	❌	Extra message from the project creator/ team
max	❌	Set the total quantity in pieces of the operation, default to "∞"
lim	❌	Limit: Set the fixed amount in every inscription, default to "1"
vfy	❌	Verify: Encrypted and show the last 5 digits by SHA-256 Algorithm

### 5.　Recovery (Not Yet Support) The inscription holder could recover or even get the inscription back by fractionalizing the original inscription for 1 more piece and using the verification code to prove the ownership of the inscription to re-inscribe for taking back control. Here is a basic example below (replace the x), ``` { "p": "brc-1155", "op": "recovery", "abbrev": "xxxxxxxxxx", "inscription": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "vfy": "xxxxx" } ``` {% hint style="danger" %} **The recovery function for taking back control is depending on the view of project teams.** {% endhint %}

Key	Must?	Description
p	✅	Protocol: To identify and process BRC-1155 events
op	✅	Operation: Type of events {deploy, fractionalize, mint...}
abbrev	✅	Abbreviation: Set a max. 10 letters identifier with Case Sensitive
inscription	✅	Identifier inscription ID of the original image location
author	❌	Identifier of the project creator/ team with {.sats} domain
vfy	✅	Verify: Encrypted and show the last 5 digits by SHA-256 Algorithm

## Suggestions It is welcomed to provide recommendations for better improvement upon the structure, designs, rules, or compression issues it poses. The following list has recorded the accepted advice from the community, please also respect and appreciate their contribution to the BRC-1155 protocol.

Twitter ID	Advice [Accepted Version] {Starting Block}
@0xjingle	Using inscription ID instead of number [v1.1.6] {792,528}

## Ending The standard protocol is still updating, we will officially publish the whitepaper once it is finished. Thank you for taking the time to read the whole passage. You are going to be one of the historical witnesses in Bitcoin development. Please bear in mind that these might be worthless, but the journey should be priceless. ## Extention of Supporting Standard {% embed url="" %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ivantkf.gitbook.io/brc-1155/brc-1155-standard.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.