BRC-420 Metaverse Standard
Idea
Problem Statement
In the world of Web3, all games are fragmented and incompatible with each other. This leads to a situation where, once a user purchases a game asset, the asset becomes worthless when the game's life cycle comes to an end. While the asset still exists on the blockchain, it no longer holds any value. Some might merely become images for viewing pleasure, while others could turn into meaningless strings of code.
Proposed Solution
What the Web3 metaverse urgently needs is a universal protocol that defines and sets a common asset that everyone can use. Achieved through consensus, this protocol would be adhered to by various game developers and application creators. In this way, ownership of such an asset becomes a permanent resource in the Web3 world, much like owning a car allows you to travel anywhere. If you own an avatar, you can appear in any virtual world. Even if a particular game ceases to exist one day, the asset you own will continue to exist in other metaverses indefinitely.
Protocol Basic Definitions
The basic asset inscription primarily consists of three parts:
1 . Basic Resource Attribute Block (baseData)
This block is responsible for storing and setting the basic attributes of the asset. These could include:
· Graphic Resource Inscription Addresses: These are addresses that point to the visual representations of the resource, such as images, 3D models, etc. · Basic Properties: These are inherent properties like size, animation settings, and other attributes that make the resource usable at a basic level.
The attributes stored in this block set the foundational characteristics of the asset. These characteristics can then be extended and referenced in the "Application Extension Attribute Block."
2 . Preview Display Block (previewData)
This block has two main subsections:
Display Attributes: These attributes define how the resource is going to be displayed. They might include things like frame size, aspect ratio, or specific settings tailored for previews.
Display Code for Attributes (On-chain): This is actual code that needs to be uploaded to the blockchain to make the display attributes work.
This block is for previewing the asset in various parts of the Ordinals ecosystem like Ordiscan or other web pages. It is highly customizable and theoretically adheres to the principle of nesting, allowing for a varied range of display options.
3 . App Data (appData): Application Extension Attribute Block
This block is for storing application-specific attributes. It offers:
Custom Attributes: Each application can define its own set of unique attributes for the asset.
External Attribute Referencing: Applications can either reference attributes defined in other applications or build their own unique attribute block for extension.
This enables the asset to be highly versatile and adaptive across various applications, ensuring it retains its value and utility in diverse use-cases.
By defining these three blocks, we create a comprehensive and flexible framework for asset management in the Web3 metaverse, allowing for both standardization and customization.
As shown in the diagram above, once resources are uploaded onto the blockchain, all games and applications that adhere to this protocol can directly refer to the basic attributes in the "metaverse" section to display and retrieve the resource's initial attributes and status keywords. You can also use the custom attributes in "AppData" to make the resources conform to the requirements of a specific app. Of course, you can also use attributes already defined by other apps. This system is highly open, giving game and app developers a lot of creative freedom.
You are also free to use all the attributes and resources in the inscription within your game or app, including attributes in the "metaversepreview" section, which are usually recommended for display purposes only.
A complete resource inscription should contain at least the "metaverse" and "metaversepreview" sections. Without the "metaverse" the protocol would be meaningless; without the "metaversepreview" the resource might still be applicable in games and apps but may not be displayable or previewable on web platforms on the blockchain (such as "ordiscan") and their images will not be displayed correctly
Recursive Metaverse Inscriptions (Experimental Development In Progress)
See Chapter 1.3
How-to:
The inscriptions are designed for web display and data storage, taking into account both readability and mutability. Due to XML's unique features that support custom data and the advantages of extendable nesting, XML format was ultimately chosen for engraving on the blockchain.
The most basic related format example is as follows:
This metaverse example code is not complete; it only contains some defined global attributes. Of course, you can also customize related attributes, but at the moment, it needs a world carrier, such as an application or a game. If the application or game is 2D, please read the relevant instructions for 2D Inscriptions to define a complete resource specification that includes 2D attributes. If it contains 3D resources (currently under experimental development) or other related world attributes, they must be filled in to make it complete. Of course, if you only fill in the most basic attributes, it won't affect its being added to the blockchain, but its range of support will be reduced.
We strongly recommend that you read our 2D Inscriptions carefully, as it contains very mature and standardized requirements for 2D resource attributes.
The code in metaversepreview serves as an example display template code. The attributes filled in should be according to the specifications required by the referenced script. Developers can refer to the display template script that has already been put on the blockchain in the example to directly edit the display image. For specific rules, see chapter 1.1.1, or you can refer to the way the example scripts are written to customize an even cooler display template script.
metaverse
To comply with and adhere to the BRC-420 standard, you must include the keyword p="brc-420" in the metaverse attribute block. Otherwise, it may not be indexed by the relevant protocol
In this code, individual attributes are written between "<metaverse" and ">", separated by spaces. Of course, you can also set each attribute on a new line following the standard format.
What is a single attribute, and what is a multi-item attribute?
Single Attribute: An attribute that contains only one attribute key category, such as name, ID, etc. This type of attribute cannot have multiple values, and we refer to it as a single attribute. Multi-item Attribute: An attribute that may contain multiple values, such as animation attributes where a resource can have multiple animations.
Recommended basic single attributes for the metaverse standard:
key | required? | text |
---|---|---|
p | Yes | Protocol to comply with, recommended to fill in as "brc-420". |
name | Yes | Resource name, which serves as the identifier for the resource. |
src | Yes | The source file of the resource that has already been uploaded to the chain, such as an image for 2D resources or a model for 3D resources. |
srctype | Yes | The file format of the original resource, such as PNG, JPEG for image resources, or OBJ, FBX, GLB for model resources. |
collection | No | Collection name. |
serialnumber | No | Serial number within the collection. |
description | No | Description related to the resource. |
some key you want | No | You can, of course, add any custom attributes you like. The recommended key format is "custom_yourtypename." Attributes without the "custom" keyword are either genesis attributes of the protocol or attributes related to subsequent community voting. |
Multiple attributes in the code are written between "<metaverse...>" and "</metaverse>". They are made up of multiple blocks of elements with the same attribute name.
The 2D Inscriptions section provides a detailed definition of the standards related to 2D resources. Although it is experimental, it is a well-considered resource specification. We strongly recommend that you read it carefully and make use of it. We believe that it will reduce the complexity and threshold for community consensus, as well as accelerate the adoption speed of universal 2D resources in metaverse games or applications.
appdata
This attribute block area is the place for setting custom attributes for the related application or game. The format can refer to the way attributes are set in the metaverse block, also divided into single attribute blocks and multi-attribute blocks.
We will introduce this attribute block in detail with practical examples in the Bitmap Explorer's custom attribute block within the rcsv ecosystem.
metaversepreview
This pertains to display-related attributes, including how the resource is presented on web platforms or other carriers. It can be related to the basic attributes of the resource or can be completely independent, depending on the resource display template code you set.
The attribute structure can refer to the above-mentioned metaverse attribute structure and is also divided into single attribute blocks and multi-attribute blocks.
We will introduce this module in detail with examples in the 2D Inscriptions section.
Last updated