HomeCoinsZilliqa (ZIL)Introducing ZRC-6: The new-and-improved NFT standard to fuel the creator economy |...

Introducing ZRC-6: The new-and-improved NFT standard to fuel the creator economy | by Tan Hong Wei Kenneth | Nov, 2021

- Advertisement -

Tan Hong Wei Kenneth
Introducing ZRC-6: The new-and-improved NFT standard to fuel the creator economy | by Tan Hong Wei Kenneth | Nov, 2021

Zilliqa is introducing a new-and-improved NFT token 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.

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.

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.

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.’

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.

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.

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.

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.

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

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

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 )

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

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

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

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

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.

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.

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.

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.

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.

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.

Source link

- Advertisement -
Mr Bitcointehttps://www.bitcointe.com/
“Fact You Need To Know About Cryptocurrency - The first Bitcoin purchase was for pizza.” ― Mohsin Jameel
462FansLike
76FollowersFollow
4,567FollowersFollow
5,261FollowersFollow
1,560FollowersFollow
2,230SubscribersSubscribe

Most Popular

bitcoin
Bitcoin (BTC) $ 43,244.00
ethereum
Ethereum (ETH) $ 3,333.75
tether
Tether (USDT) $ 1.00
bitcoin-cash
Bitcoin Cash (BCH) $ 388.04
litecoin
Litecoin (LTC) $ 146.27
eos
EOS (EOS) $ 2.92
okb
OKB (OKB) $ 26.09
tezos
Tezos (XTZ) $ 4.31
leo-token
LEO Token (LEO) $ 3.76
cardano
Cardano (ADA) $ 1.38
monero
Monero (XMR) $ 215.08
stellar
Stellar (XLM) $ 0.262728
chainlink
Chainlink (LINK) $ 25.99
huobi-token
Huobi Token (HT) $ 10.03
tron
TRON (TRX) $ 0.07026
usd-coin
USD Coin (USDC) $ 1.00
dash
Dash (DASH) $ 140.15
neo
NEO (NEO) $ 25.41
iota
IOTA (MIOTA) $ 1.15
nem
NEM (XEM) $ 0.119163
zcash
Zcash (ZEC) $ 143.70
maker
Maker (MKR) $ 2,215.67
paxos-standard
Pax Dollar (USDP) $ 1.00
ethereum-classic
Ethereum Classic (ETC) $ 32.60
vechain
VeChain (VET) $ 0.079114
true-usd
TrueUSD (TUSD) $ 1.00
ftx-token
FTX Token (FTT) $ 46.28
kucoin-shares
KuCoin Token (KCS) $ 20.71
waves
Waves (WAVES) $ 14.62