The essential NFT protocols in a nutshell-A&T Capital

People usually make sense of NFT projects in terms of trading platforms, games, art, collectibles, virtual worlds, and ‘other’ categories. These categories are actually the ‘NFT application’ seen by top users or the ‘Dapp’ built on top of the protocol layer. But from a more global perspective, in addition to Dapp, there are underlying infrastructure and intermediate network protocols that serve NFTs. For example, the NFT trading platform is an application based on NFT protocols such as ERC721 or ERC1155, building upon the underlying foundation (Ethereum, WAX, Polygon). The underlying infrastructure provides performance and interoperability for trading platforms, while ERC standards limit the use cases of top-level applications.

From the functional attributes, the NFT industry chain can be divided into three layers from top to bottom:

  1. The application layer; this is what users see and use on a daily basis.
  2. The technology in between the protocol layer, the NFT application layer and the computing layer.
  3. The settlement layer, which is responsible for the storage and recording of the value of NFT.

The protocol layer is the key module between the settlement layer and the application layer. The unified on-chain protocol standard can effectively reduce the threshold and difficulty of NFT asset issuance, and solve the issues with asset security, authenticity, liquidity and decentralization in the NFT market. At present, the most widely used are ERC721 protocol and ERC1155 protocol.

This article will examine the existing NFT agreements, including ERC721, ERC1155, ERC998, NFT lease agreements, EIP2981, and liquidity agreements and cross-chain agreements.

NFT Standard Protocols

ERC721 — Metadata structure for NFT tokens on Ethereum. The first standard to represent NFT assets was created by Dapper Labs Dieter Shirley and brought to market by CryptoKitties

ERC1155 — Manage multiple types of NFTs in a single smart contract

ERC998 — Nestable NFTs, i.e. binding relationships for multiple NFTs

EIP2981 — NFT Royalties

ERC1523 — NFT as insurance policy

EIP1948 — NFT with changeable information

ERC875 — Batch Transfer NFT

In addition to the mainstream ERC-721 and ERC-1155, some of the underlying public chains of NFTs have begun to develop NFT on-chain protocols, such as DNFT, a decentralized NFT protocol that supports the development of NFT asset-related creation, trading, analysis, derivatives, data and other products; Vera, an NFT lending and liquidity agreement for the Pocchia ecosystem. These belong to the NFT common protocol layer, which can empower various application scenarios of NFT, such as finance, data, cross-chain, privacy and other tracks. Other NFT common protocol layers can be broadly divided into liquidity protocols and cross-chain protocols.

Different NFT Protocols

ERC721

ERC721 is the fisrt formal and widely adopted NFT standard that defines a set of code rules for recording information related to NFTs on the ethereum blockchain. Although ERC-721 is not mandatory, it is widely accepted as a standard for NFT projects.

The full name of ERC-721 is Ethereum Request for Comment-721. ERC-721 is derived from Ethereum Improvement Proposal (EIP) №721. After the EIP is reviewed and finalized, it becomes ERC.

History of ERC721

EIP-721 was first proposed by Dieter Shirley in September 2017. Shirley later co-developed CryptoKitties in late 2017 based on the original version of EIP-721, which ignited the Ether community at the time. EIP-721 was formally submitted on January 24, 2018 by William Entriken, Dieter Shirley, Jacob Evans, and Nastassia Sachs was formally submitted. EIP-721 was accepted as the final version, becoming ERC-721 on June 21, 2018, .

Content of ERC721

ERC-721 assigns two identifiers to any NFT, the contract address and the token ID. their combination makes the NFT truly unique. For example, there is only one Bored Ape Yacht Club (contract) #3749 (token ID).

ERC 721 is a single token standard which means each asset has individual smart contract even for same gamefi ingame asset. This standard defines the functions “name , symbol , totalSupply, balanceOf , ownerOf , approve , takeOwnership, transfer , tokenOfOwnerByIndex , and tokenMetadata" and also covers two events used in marketplace: Transfer and Approval

An overview of each arttributes within ERC721 standard can refers to this article: https://medium.com/crypto-currently/the-anatomy-of-erc721-e9db77abfc24

Cons of ERC721

  • Imcompatible with ERC20
  • Only apply to ethereum

ERC1155

ERC1155 is the multi-token standard extends from ERC721 that supports issuing many tokens from the same smart contract, which allows for efficient creation and transfer.

History of ERC1155

ERC1155 is created by Enjin CTO Witek Radomski which allows the one or multiple ERC1155 items in a single transaction.

Pros of ERC1155

  1. Efficiency in transfer and swap:
  2. Compatible with cross-chain
  3. Gas saving in minting new tokens

Cons of ERC1155

Hard to track on ownership

ERC 998 — — Composability Tokens

In terms of composable tokens, it is capable of representing a set of ERC20 tokens or ERC721 tokens or a combination of both that can be traded in one transaction. To implement ERC998, you first need to add the sub-token ERC721 or ERC20 to ERC998. Child tokens can only be transferred from the contract if the sender also has a parent token ID. ERC998 enables the transfer of all levels and affiliations at once.

Use case: Assets in the game, such as metaverse real estate, REVV racing.

The value of one ERC998 token is equivalent to the accumulation of these items in an entity.

Rental protocol (EIP4907/2615/5006)

EIP2615 and EIP4907: Decouple NFT ownership & utility for Owner & Renter through smart contract

EIP2615- NFT Mortagage and rental

EIP2615 usually used in NFT renting proocol that seperate the ownership and usage rights for NFTs and allow users to rent our their own NFTs or and take out mortage by collateralising their NFTs.

To achieve trustless rental of NFTs with ERC721, it has been necessary to deposit funds as security. This is required to prevent malicious activity from tenants, as it is impossible to take back ownership once it is transferred.

With this standard, security deposits are no longer needed since the standard natively supports rental and tenantship functions.No ownership escrow when taking out a mortgage

In order to take out a mortgage on NFTs, it has been necessary to transfer the NFTs to a contract as collateral. This is required to prevent the potential default risk of the mortgage.

However, secured collateral with ERC721 hurts the utility of the NFT. Since most NFT applications provide services to the canonical owner of a NFT, the NFT essentially cannot be utilized under escrow.With ERC2615, it is possible to collateralize NFTs and use them at the same time, which makes NFT more efficient.

The details of the implementation for mortage and rental can refers to this article: https://eips.ethereum.org/EIPS/eip-2615

NFT renting category:

  1. Separation by account service

a. Off-chain account service — CEX model

i. Projects: Axie scholar program

ii. Cons: complicated due to different functionalities of NFTs, rights assignment problem, integration and scalability problem to developers, separate frontend needed, trust on account service, not open & interopable

b. On-chain account service — multi-sig wallet

i. Projects: Pine, 99 starz

ii. Pros: solves the problem of trust

iii. Cons: frontend integration needed from dapps, no provide key & unable to provide signature, integration with other dapps (e.g. opensea), gas cost & security for proxy contract upgrades

2. Separation by projects

a. Dual role — EIP4907

i. Projects: ENS (controller), Decentraland (operator), double protocol

ii. Pros: permissionless interoperability

iii. Cons: requires contract upgrades / adoptions from projects — heavy BD

b. Metadata extension — develop custom contracts

i. Projects: reNFT, Rentable

ii. Cons: project trust user information, difficulty in development, difficult to find info you want (E.g.: https://github.com/re-nft/registry)

c. Wrapped dual role

i. Projects: Cyan, Double, BendDAO

ii. Cons: partnership with projects & scalability

EIP2981 — Royalty

EIP2981 is the standard that handle royalty payments for ERC721. It allows standardize royalty payments across playforms since each marketplace has it’s own royalties and none of them works on secondary marketplace. EIP2981 unifies the royalties so they are set and provides a function that returns the amount to creators address.

Types of royalty supported by EIP2981

  1. Atypical, namely fixed % royalties. e.g. 10% returns to creators
  2. Decaying royalties, which could be time based ownership based or any attributes.
  3. Dynamic royalties, which , which can be change over time or sale amount.

About A&T Capital:

A&T Capital is an early-to-growth stage venture fund for emerging disruptive technologies. Led by three founding partners based out of Berlin, Singapore and Shanghai, we are supported by a global dynamic team of researchers and analysts. Our varied backgrounds in high tech, TradFi and venture capital help us understand what is essential for a startup to succeed. In 2021, we raised 100M pool of funds. Our portfolios include Amber Group, Cobo, Gnosis Safe, Nestcoin, Infstones, Consensys, and Commonwealth.

Follow us, THIS IS THE WAY:

Official website: https://capitalant.com/

Twitter:https://twitter.com/ANT_Capital

Telegram Global Community: https://t.me/+2fGBC6O71IYzNWFl

Wechat Chinese Community:https://mp.weixin.qq.com/mp/profile_ext?action=home&__biz=Mzk0MDI2ODg0Mw==&scene=124#wechat_redirect

For partnership or enquires: email contact@capitalant.com

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
A&T Capital

A&T Capital

A&T Capital is an early to growth stage venture fund for emerging disruptive technologies mainly in web3.