Study these NFT smart contract approaches 🙇
Discover more from Metaversal
Study these NFT smart contract approaches 🙇
Inside the basics of ERC721 design!
Metaversal is a Bankless newsletter for weekly level-ups on NFTs, virtual worlds, & collectibles
Dear Bankless Nation,
To make an NFT project, you have to create an NFT smart contract.
And to maintain composability across a network like Ethereum, such NFT contracts are built per a certain token standard. The most popular one today is the ERC721 standard, which is good for creating unique digital assets.
However, there are different ways to implement the ERC721 standard, and then essentially endless more ways to create on top of and around these base implementations.
Yet you don’t have to be a developer to learn the key concepts behind the reigning ERC721 implementations or behind some of the worst and most innovative NFT smart contracts to date. Doing your homework here will help you better understand NFT design in general, so let’s talk ERC721s for today’s Metaversal!
-WMP
🙏 Sponsor: Brave Wallet - the secure crypto wallet. No extension required.✨
ERC721 NFTs: approaches and examples
Main ERC721 implementation styles
A write-up I recently found instructive was “A Modern ERC721 Implementation Guide” by Jack Benhayon. In it, Benhayon does a great job comparing some of the main ERC721 implementations we see in use around the contemporary NFT ecosystem. These implementations include:
ERC721 OZ — Developed by dapp security project OpenZeppelin, ERC721 OZ has become a leading plug-and-go template for many NFT projects
ERC721A — Created by the Azuki team, ERC721A optimizes for gas efficiency when minting multiple NFTs
ERC721 solmate — Built by Rari Capital devs and t11s, solmate is designed as a “modern, minimalist, and gas-efficient ERC721 implementation”
These implementations differ in the gas savings they afford users for basic activities like minting an NFT, minting multiple NFTs, making transfers, burns, etc.
Per tests conducted by Benhayon, solmate NFTs are more gas-efficient than ERC721 OZ NFTs across every activity category. ERC721A NFTs were also handily bested by solmate NFTs across every activity category except for the minting of multiple NFTs, where ERC721A proved vastly more gas-efficient.
The big ideas here, then? Benhayon explained:
“Use ERC721A if you are expecting the majority of your project’s mints to be more than 1 NFT, especially if your project is facing certain high demand and you are scared of congesting the network during the mint.
If you are expecting the majority of the mints to be 1 or 2 NFTs each, the case for most projects using an early access list setup, or if your project is burning NFTs or continuously transferring them to a staking contract etc., use a standard ERC721. The mints will be about the same or slightly more expensive, but all the future interactions will be much cheaper.
[...] Solmate provides a number of minimalist token implementations, including ERC721 and ERC1155. As shown in the table above, the gas savings for minting are quite small, but save around 10% on transfers and lead to more savings as operations on the NFTs become more complex. There is absolutely no reason not to use solmate’s ERC721 implementation over OpenZeppelin’s. It does the same things, it is just more efficient.”
Alternative implementation styles
Some other experimental ERC721 implementation approaches I’ve seen that you may want to note include:
ERC721S — a “super gas-friendly” NFT design
ERC721:Shadow — specialized for very large mint events
ERC721FTR — a thought-experiment design that disallows NFT trades worth more than 1 ETH
ERC721R — a newer approach that allows dissatisfied minters to return their NFTs for a refund
Examples of great and bad ERC721 smart contracts
Selecting an NFT implementation is one thing, but then a project has to go and actually build out its compliant smart contract and actualize its vision on-chain.
That said, multiple teams have developed incredibly innovative ERC721 contracts over the past couple of years, while others have shown us what some of the NFT ecosystem’s worst design practices look like in the wild.
So what actually makes for a great ERC721 smart contract? Well, the best ones often have many things going for them, like strong security guarantees, secured metadata, creativity, elegance, and so forth. The worst ones often use totally off-chain metadata (e.g. private servers) and are modifiable in sketchy, centralized ways.
Someone who knows a thing or two about NFT design is Samuel Cardillo, the chief technology officer of RTFKT. In 2021, Cardillo started the “Smart Contract Database,” an open resource where the CTO has supplied his ratings of popular NFT smart contracts based on his judgments of their overall design quality.
Notably, some of the projects that Cardillo gave A+ ratings to included:
Avastars: “The Rolls Royce of smart contracts in terms of decentralization and longevity. Everything is on-chain.”
Nouns DAO: “The kind of smart contract that is out of this galaxy. Just pure perfection. Everything decentralized, on-chain, generated in a SUPER clever way ... there is too many good things to say — actually ONLY good things. Good job!”
Monster Blocks: “Assets are stored on-chain, smart usage of Chainlink for RNG, clean code: that is an A+!”
CryptoPunks: “Assets are fully on-chain, super good usage of watchdogs (contractSealed variable). It is a pretty smart way of doing things instead of forcing migration, kudos to Larva Labs.”
CryptoZunks: “Another Rolls Royce of smart contracts: amazing way to save gas fees, everything is on-chain, super smart code.” (My note: we now know the Zunks design was a precursor to the Azuki team’s ERC721A approach)
On the flip side, a few of the projects that Cardillo gave his lowest C ratings to for their bad practices included:
Hedgies: “Centralized contract with ‘setTokenURIPrefix’ callable any time by the collection creator: STAY AWAY FROM SUCH CONTRACTS!”
Ready Player Cat NFT: “Assets are centralized and the contract is ‘upgradeable’ meaning that it can be changed AT ANY TIME. STAY AWAY FROM SUCH CONTRACTS!”
Gauntlets: “Assets are centralized and both ‘setProvenanceHash’ and ‘setBaseURI’ can be called any time making the entire thing super mutable.”
In other words, Cardillo scored these latter projects so poorly because they’re insecure and readily modifiable. Better designed collections, like Avastars, are exemplary in contrast for offering their holders permanent on-chain security and immutability.
Of course, it’s not that every NFT project has to or should be totally on-chain or even totally immutable. But projects that do approach these matters seriously and with cleverness have a certain shine to them, so to speak.
Action steps
🙇 Review the top ERC721 implementation styles
🔍 Study the designs of top NFT projects like Avastars, CryptoPunks, and Nouns DAO
😎 Read my previous write-up 5 cool new NFT projects if you missed it!
Author Bio
William M. Peaster is a professional writer and creator of Metaversal—a Bankless newsletter focused on the emergence of NFTs in the cryptoeconomy. He’s also recently been contributing content to Bankless, JPG, and beyond!
Subscribe to Bankless. $22 per mo. Includes archive access, Inner Circle & Badge.
🙏Thanks to our sponsor
BRAVE WALLET
Brave Wallet: the secure crypto wallet, built directly into the browser.
Buy, store, send & swap assets. Manage NFTs. Connect other wallets & DApps. All from the security of the best privacy browser on the market.
Ditch those risky extensions. It’s time to switch to Brave Wallet.
Not financial or tax advice. This newsletter is strictly educational and is not investment advice or a solicitation to buy or sell any assets or to make any financial decisions. This newsletter is not tax advice. Talk to your accountant. Do your own research.
Disclosure. From time-to-time I may add links in this newsletter to products I use. I may receive commission if you make a purchase through one of these links. Additionally, the Bankless writers hold crypto assets. See our investment disclosures here.
Study these NFT smart contract approaches 🙇
Is there a guide for how to assess the code for the things outlined in the bad practices?