NRC721 — NFTs on Nervos Blockchain

Nervos network works in a unique way to maximize decentralization while remaining minimal, flexible, and secure, but this uniqueness makes its operation substantially different from existing blockchains, thus making it necessary to define its own standards.

The Nervos Ecosystem offers a multilayer architecture to achieve scalability, security, and decentralization. The Nervos Blockchain is Layer 1 of this ecosystem and was thought to store the Common Knowledge Base generated in it. L1 Nervos network has a unique architecture, making it difficult to extrapolate existing standards from other blockchains.

This article proposes a standard for NFTs creation and handling, an example of an implementation of it with a modular programming perspective can be found in this article. This standard is aimed to provide a standardized structure so developers, users, and stakeholders have a common understanding of how things are done, making it easier to have integration between different Dapps and projects.

NRC-721 proposal is inspired by Openzeppelin’s implementation of ERC-721 from the Ethereum Blockchain as we consider this to be a mature, tested implementation proposal that actively makes it easier for Ethereum developers to deploy and integrate NFTs into their applications.

We aim to provide similar simplicity and lower the onboarding bar to the Nervos ecosystem.

NRC-721

Factory Cell

In order to store the common data without repeating and paying for unnecessary storage space in the blockchain a factory Cell is defined to store common data:

Type:
- code\_hash: TYPE\_ID or Custom Script
 - type: "type"
 - args: TYPE\_ID [32 bytes]

Data:
 - name: length<uint8> + text<utf-8> (max 255 char)
 - symbol: length<uint8> + text<utf-8> (max 255 char)
 - base\_token\_uri: length<uint8> + text<utf-8> (max 255 char)

Lock: <user defined>

Since we need some mechanism to ensure that this cell is unique, we recommend using the Type ID proposed here. For that purpose, the nervos blockchain offers a built-in type_id script that can be used without the need of developing and deploying a custom script, but, when looking for custom features on the factory, a specific script should be developed implementing the type_id functionality, plus the custom features. The data on this cell should be verified on the NFT script to ensure compatibility with the standard, so the script should require using the factory as a dependency.

The purpose of base_token_uri is to provide a detailed information source for the token. The path to fetch this info would use the base_token_uri as the base path along with the token id:base_token_uri/token_id, and it should return a JSON object with the extra info. For this JSON object, we adopt Ethereum’s ERC721 Metadata JSON Schema :

{
  "title": "Asset Metadata",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "description": "Identifies the asset to which this NFT represents"
    },
    "description": {
       "type": "string",
       "description": "Describes the asset to which this NFT represents"
    },
    "image": {
       "type": "string",
       "description": "A URI pointing to a resource with mime type image/\* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
    }
  }
}

Referencing the Ethereum standard will allow straightforward cross-chain integration with blockchains that have already adopted it.

Token Cells

The tokens cells contain the information of each unique token created from the factory and will be governed by the NFT script.

Type:
- code\_hash: NFT\_Script
 - type: "type"
 - args: Factory\_code\_hash<32 bytes> + Factory\_type<uint8> + Factory\_args<32 bytes> + TOKEN\_ID

Data:
 - Token specific data (can be empty)

Lock: <user defined>

Using the factory cell type fields in the args of the token allows getting the information of the factory from the token Cell. This script should provide verification to ensure that each token has a unique TOKEN_ID, we propose using the Type_id logic here to achieve that.

Using NRC-721 in your application

Following we provide a summarized flow of how your Dapp would take advantage of this standard:

Stay tuned for more articles regarding efficient scripting in Nervos Network. Rather Labs, Inc. | Github | LinkedIn