OPRR Flash Depth Data

Search Extension

ERC721 NFTs: Methods and Examples

Bankless

2022-07-14 11:35

Read this article in 12 Minutes

Understand the key concepts behind ERC721 implementation, the key concepts behind NFT smart contracts.

Original title: "Study Methods of NFT Smart Contracts"

Original source: BanklessCN

If you want to make an NFT project, you must first create an NFT smart contract.

In order to maintain composability on networks such as Ethereum, such NFT contracts are built according to specific Token standards. The most popular one at the moment is the ERC721 standard, which is conducive to the creation of unique digital assets.

However, there are different ways to implement the ERC721 standard, and there are many other implementation methods outside of these basic deployments.

However, you don't have to be a developer to understand the key concepts behind the ERC721 implementation or the key concepts behind the worst and most innovative NFT smart contract to date. Doing your homework here will help you better understand NFT design, so let's talk about the ERC721 of the metaverse today!

ERC721 NFT: Methods and Examples

Main Implementations of ERC721

One of the more inspiring articles I saw recently was Jack Benhayon's "Modern ERC721 Implementation Guide". In it, Benhayon did a good job of explaining some of the main ERC721 implementations we use in the current NFT ecosystem.

These implementations include:

- ERC721 OZ — Developed by dapp security project OpenZeppelin, ERC721 OZ has become the preferred template for many NFT projects, plug-and-play.

- ERC721A — ERC721A, created by the Azuki team, effectively optimizes gas efficiency when minting multiple NFTs.

- ERC721 solmate — Built by Rari Capital devs and t11s, solmate’s design is described as a “modern, minimalistic and energy-efficient ERC721 implementation.”

These implementations save gas to varying degrees for users in basic activities of NFT projects, such as minting NFTs, minting multiple NFTs, transferring, destroying, etc.

According to the tests conducted by Benhayon, solmate NFTs are more energy-efficient than ERC721 OZ NFTs in every activity category. ERC721A NFTs are also easily beaten by solmate NFTs in all activity categories except minting multiple NFTs, and ERC721A proves its greatly improved efficiency in optimizing gas.

Numbers represent sum of gwei - Image and test from Jack Benhayon

So what is the core concept here? Benhayon explains:

“If you expect most minting to be more than 1 NFT, use ERC721A, especially if your project is expected to have high demand and you are concerned about whether you will encounter network congestion during minting.

If you expect most minting to be 1 or 2 NFTs each, most projects are in early access list settings, or if your project is burning NFTs or constantly transferring them to staking contracts, etc., use standard ERC721. Minting will be roughly the same or slightly more expensive, but all future interactions will be much cheaper.

[...] Solmate provides many minimalistic Token implementations, including ERC721 and ERC1155. As shown in the table above, the gas savings on minting are very small, but the savings on transfers are about 10%, and as the operations on NFTs become more complex, the savings can actually be larger. There is absolutely no reason not to use solmate’s I'm not using an experimental ERC721 implementation like OpenZeppelin. It does the same thing, just more efficiently."

Alternative Implementations

Some other experimental ERC721 implementations I've seen that might be of concern include:

- ERC721S — A “super gas-friendly” NFT design

- ERC721:Shadow — Designed specifically for large mint activity

- ERC721FTR — A thought experiment design that disallows NFT transactions worth more than 1 ETH

- **ERC721R — **A more innovative approach that allows unhappy minters to return their NFTs for a refund

Good and Bad Cases for ERC721 Smart Contracts

Choosing an NFT implementation is one thing, but then projects must go about building their compliant smart contracts and be able to implement their vision on-chain.

That said, over the past few years, multiple teams have developed incredibly cool and innovative ERC721 contracts, while other teams have done some of the worst designs in the NFT ecosystem and shown what this practice actually looks like.

So what exactly makes a great ERC721 smart contract? Well, successful smart contracts are usually made up of several aspects, such as strong security guarantees, secure metadata, creativity, ease of use, etc. The worst examples and practices usually use metadata completely off-chain (such as private servers) and modify it in a crude, centralized manner.

RTFKT's CTO Samuel Cardillo is quite knowledgeable about NFT design. In 2021, Cardillo launched the "Smart Contract Database", an open resource where the CTO made a rating table of popular NFT smart contracts based on his judgment of the overall design quality of popular NFT smart contracts.

*Image courtesy of* Samuel Cardillo

Notably, some of the projects that Cardillo gave an A+ rating include:

Avastars: “The Rolls Royce of smart contracts in terms of decentralization and longevity. Everything is on-chain.”

Nouns DAO: “This is out-of-this-galaxy smart contracts. Just pure perfection. Everything is decentralized, on-chain, generated in a super smart way… Can’t praise it enough - only good things actually. Well done!”

Monster Blocks: “Assets stored on-chain, smart use of Chainlink for RNG, clean code: this is A+!”

CryptoPunks: “Assets are completely on-chain, very good use of watchdogs (accepts contractSealed variables). This is a very smart way to do things instead of forcing a migration, kudos to Larva Labs.”

CryptoZunks: “Another Rolls-Royce of smart contracts: awesome way to save on gas, everything on-chain, super smart code.” (*My note: we now know that the Zunks design was a precursor to the Azuki team’s ERC721A approach*)

Nouns *DAO illustration - art by*MSSHUP**

On the other hand, some of the projects that Cardillo gave the lowest C rating for their bad practices include:

Hedgies: “A centralized contract with ‘setTokenURIPrefix’ can be called at any time by a collection creator: stay away from such contracts!”

Ready Player Cat NFT: “The asset is centralized and the contract is ‘upgradeable’, meaning it can be changed at any time. Stay away from such contracts!”

Gauntlets: “The asset is centralized, and both ‘setProvenanceHash’ and ‘setBaseURI’ can be called at any time, which makes the whole thing extremely uncertain and volatile.”

In other words, Cardillo rated these latter projects so low because they are insecure and easily modifiable. In contrast, the better designed NFT series (such as Avastars) are exemplary in their design in providing permanent on-chain security and immutability to their holders.

Of course, not every NFT project must or should be completely on-chain, or even completely immutable. But, it can be said that projects that carefully and skillfully handle these issues will always have a certain positive impact on them.