DRC-420 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 Doginals ecosystem. 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 "metaverse preview" the resource might still be applicable in games and apps but may not be displayable or previewable on web platforms on the blockchain and their images will not be displayed correctly
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.
metaverse
To comply with and adhere to the DRC-420 standard, you must include the keyword p="drc-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:
p
Yes
Protocol to comply with, recommended to fill in as "drc-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.
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.
metaverse preview
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 soon.
Last updated
