TL;DR

Zilliqa is introducing a new-and-improved NFT standard that will drive us into the forefront of the creator economy. The ZRC-6 is a major upgrade from the ZRC-1 and includes several novel features that will be key for creators and builders. This standard also includes some enhanced functionalities for NFTs powered by Zilliqa. In addition to being energy-friendly, ZRC-6 will pave the way for Zilliqa as a leading NFT issuance platform.

We are opening things up for community feedback as we finalise the standard. Here are some of the key features of ZRC-6:

1. Royalties — Marketplaces can now integrate royalty features with ZRC-6 tokens, as the token allows for an optional interface that captures royalty details, enabling creators to be paid royalties on sales.
2. Batch operations for minting, burning, and token transfers.

The aforementioned features will unlock more possibilities for builders and creators alike as it gives them the opportunity to implement functions like conditional royalty, dynamic royalty, or even using royalties as a revenue stream for DAOs!

The delivery of all these innovative features is at the core of Zilliqa’s ambitions to become the blockchain-of-choice for the creator economy.

Introduction

Over the past year, Zilliqa has had a front-row seat to the evolution of non-fungible tokens and the advent of the creator economy. Covid-19 disrupted most industries and crypto was no exception. When the market went parabolic, we saw the emergence of new value-driven models, revitalised fan engagement, and new monetisation opportunities for talent powered by blockchain.

Let’s recap for a moment. Early on, we identified the value proposition of NFT marketplace and have onboarded Mintable to our first ZilHive accelerator program in 2019. Mintable has since grown into a vibrant multi-chain NFT marketplace, attracting investors such as Mark Cuban. Later, we supported numerous NFT marketplaces and play-to-earn NFT domains like The Bear Market, DeMons, Non-fungible Duck and Unicutes, who are also finding tremendous success. Having also built up our proprietary platform ZilStars, we led bespoke NFT projects with athletes/sports personalities and artists.

Gearing up for the next step

Now, we want to take this to the next level — by creating something truly experiential and rewarding for all.

Today, we’re doing just that with a multi-million dollar NFT project in the works — stay tuned! We’re also implementing a Creator Fund, which will commission physical and digital works from artists. Curated by a panel of carefully chosen experts, the fund will collect and invest in amazing NFTs to deploy on Zilliqa. The potential — financially and creatively — is tremendous.

By developing such platforms that are aimed in large part at enhancing accountability, provenance, intellectual property, royalties, and traditional business models, we wanted to be technically ready to deliver for our platforms, projects, and partners. To serve this goal, Zilliqa plans to move from our ZRC-1 (the specification for our current NFT standard used since Nov 2019) to the newly designed standard ZRC-6.

This standard will serve our ambitions of becoming the top layer-1 protocol to power NFTs, the Metaverse and all things ‘creator economy.’

Key Innovations

We believe ZRC-6 to be better than what’s offered on the Ethereum platform because

1. NFT standards in Ethereum are fragmented. This leads to low adoption of innovative features proposed on newer standards.
2. Individual standards on their own, lack specific useful functionality eg. batch operations such as minting, burning, and token transfers.
3. Certain contract states cannot be read by other contracts. For instance, under the official ERC-721 standard, it is not possible to retrieve a list of token IDs owned by a given holder. Such capabilities need to be added on top of the specification (eg. Open Zeppelin implementation)

In ZRC-6, we consolidate innovative features and best practices. This includes

1. Consolidate multiple innovative features such as royalty and batch operation into a single easy-to-use standard.
2. Promotes the use of newer Scilla language feature to optimise contract calls

Community Review

Attention for all Marketplace builders, NFT project teams, and community members, we are now opening this specification for public review starting from today till 13 December 2021. You can discuss or provide any valuable feedback at our Github discussion page at https://github.com/Zilliqa/ZRC/discussions/117. We aimed to finalize this specification shortly after the public review phase is completed.

Revisiting ZRC-1

First, we want to highlight that ZRC-1 will still remain as the NFT standard. For existing projects that are using ZRC-1 specification, there is no need for migration to ZRC-6. It is perfectly fine to continue using ZRC-1. We do encourage new projects to adopt ZRC-6 once it is finalised.

Let’s now take a look at some of the existing limitations which inspired us to create the new ZRC-6 standard.

1. No interfaces to support royalty payments, batch operations, admin ownership transfer and emergency pause.
2. Standard was developed before the existence of “Scilla remote state read” feature, as such, there was usage of many callbacks patterns, which are not user-friendly.
3. Callback interface is the same as ZRC-2, thereby making it hard to compose ZRC-1 and ZRC-2 tokens.
4. Token URI interface and transfer operation are not optimised.

ZRC-6 — An improved NFT standard turning limitations into features

We are opening up ZRC-6 for public review and consultation. We expect the finalisation of the standards to happen in the later part of Q4 2021.

Specification:

https://github.com/Zilliqa/ZRC/blob/master/zrcs/zrc-6.md

Reference contract with the implementation of all optional interfaces:

https://github.com/Zilliqa/ZRC/blob/master/reference/zrc6.scilla

What’s New in ZRC-6?

1. Royalty Information Retrieval

Many of the largest NFT marketplaces have implemented incompatible royalty payment solutions as ZRC-1 does not specify any interfaces to capture royalty details.

In ZRC-6, you will be able to implement an optional interface that captures the following information:

1. Royalty recipient address
2. Royalty fees (basis point) eg. 1000 = 10%

A marketplace that wishes to integrate with ZRC-6 royalty features can then use remote state read to read this value and compute the royalty amount and send it over to the royalty recipient address. The computation will be simply this

Royalty Amount = Sale Price ÷ ( 10000 ÷ Royalty Fee BPS )

What’s more?

By making the marketplace aware of the royalty fees and recipient address, the marketplace or royalty owner can choose to go a step further to implement more innovative features around the royalty scheme such as:

1. Conditional royalty — For instance, royalty payment will only be made after a certain condition is fulfilled eg. transaction price is above a certain price, or exceeds a certain volume
2. Dynamic royalty — Over time, the received royalty is a function of the original fees’ value, thereby reducing or increasing the royalty amount received over time
3. Royalty DAO — A DAO that receives all the royalty fees and is governed by token holders

2. Token URI

A token URI is an HTTP or IPFS URL that hosts the metadata of the NFT. The metadata is simply a JSON blob of data, which can be easily parsed by any frontend. All metadata about an NFT must be in a JSON file.

The token URI is split into two parts, base URL and token ID. ZRC-6 standardizes token URI with the concatenation of base token URI and token ID.

Token URI is <base_uri><token_id>.

If the base URI is https://creatures-api.zilliqa.com/api/creature/ and the token ID is 1, token URI is https://creatures-api.zilliqa.com/api/creature/1.

Similarly, you can do it via IPFS. eg. https://gateway.pinata.cloud/ipfs/QmcP9hxrnC1T5ATPmq2saFeAM1ypFX9BnAswCdHB9JCjLA/1

3. Remote State Read

Starting from Zilliqa v8.0.0, we have added a new feature “remote state read”. This allows for easy reading of another contract’s mutable variables. As such, we will be reducing the number of callbacks as opposed to what we have in ZRC-1 and promote the use of remote state read instead.

To understand how the whole process is optimised in ZRC-6, let’s look at the previous callback-centric model in ZRC-1. In order to retrieve another contract state variable

1. The initiating contract Initiate a call to a target contract’s transition
2. The target contract will retrieve the variable and return it by calling another transition on the initiating contract that will accept the return value (eg. token balance of user)
3. The initiator contract will then need to process the return data in transition that receive the data

As you can see, the main disadvantage of this approach is that you will require two contract calls and three transitions. This is a very cumbersome process.

With remote state read, this whole process is now optimised to

1. The originating contract use remote state read to read another contract mutable variables
2. The originating contract process the return value in the same transitions

In this model, it only requires 1 remote state read and 1 transition. This approach reduces the complexity of the smart contract logic and gas consumption cost in ZRC-6.

4. Pausable

One of the recommended best practices by ConsenSys is to prepare for failure such as smart contract bugs. A recommendation was to provide a “circuit breaker” such as pausing the smart contract and provide an upgrade path for resolution of such situations.

In ZRC-6, we provide optional transition interfaces for pausing and unpausing the contract. When the contract is paused, minting, burning, and token transfers will not be permitted. This will allow the contract owner to pause critical operations and identify and implement a resolution for the issue in concern.

5. Batch Operations

In ERC-721 and ZRC-1, one major limitation is the lack of batch operations interface. Such interfaces can provide a better user experience. For instance, imagine a metaverse or blockchain game in which you wish to buy a mana potion. You will want to buy and mint such potions in bulk to save time and gas. Similarly, peer to peer trading of NFTs can also be made more efficient. One such implementation can be found in ERC-1155, which is proposed by the Enjin team.

In ZRC-6, we have added optional batch operations transition interfaces for minting, burning, and token transfers. Such operations will definitely go a long way in improving the user experience in the Zilliqa ecosystem and help provide gas savings for the users.

6. A Single Transition for Token Transfers with Destination Validation

ZRC-1 includes `Transfer` and `TransferFrom` for the token transfer. The two transitions have the same type signature and the only difference is the access control. This has added unnecessary complexity. Further, ZRC-1 does not validate the destination for token transfer.

ZRC-6 features a single transition for token transfer with destination validation. The transition can be called by a token owner, a spender, or an operator. ZRC-6 prevents transferring tokens to the zero address or the address of a ZRC-6 contract.

7. ZRC-X Compatible

Currently, ZRC-1 and ZRC-2 specifications share the same callback names. This creates a composability issue when a contract wishes to interact with both ZRC-1 and ZRC-2 tokens. In ZRC-6, we resolve this composability issue by prefixing “ZRC6_” for all callback transitions.

What’s Next?

We believe that ZRC-6 will be highly welcomed to bring together the future we are building. In working on the Creator fund and various Metaverse-related efforts, we noticed that different projects use different structures for metadata. While we standardised token URI, there is no standard for metadata structure; we are currently working on ZRC-7 to formalise the structure of metadata. This will be a vital step for us to expand the NFT offerings and composability on Zilliqa as we embrace the creator economy and get closer to the Metaverse.