Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form
As many NFT creators know, deploying a smart contract to Ethereum mainnet can be insanely expensive.
However, smart contract deployment costs are not the only cost blockchain engineers and NFT teams need to consider. Creating a successful NFT collection or collectible avatar project includes building a community and making it easy for users to mint, trade, and use their NFTs.
Let’s learn about a powerful NFT smart contract optimization that can help your community save gas fees on NFT minting costs:
Implementing batch minting with the ERC721A contract!
On Jan 6th, the Azuki NFT development team publicly announced ERC721A, a new implementation of the ERC721 NFT standard that explores batch minting:
In their blog post explaining the ERC721A smart contract implementation, @locationtba and @2pmflow show estimates of how much gas can be saved when batch minting via the most commonly used NFT smart contract starter code, OpenZeppelin’s ERC721Enumerable contract, vs. batch minting NFTs using the new Azuki ERC721A contract:
This table shows how the gas used for ERC721A for an increasing number of mints scales at a much smaller constant factor.
The gas cost to mint NFTs increases by:
This result is actually AMAZING!
For the price of minting one single token via the ERC721Enumerable contract, a user can instead mint up to 5 tokens (or more, potentially) via the ERC721A contract.
Who wouldn’t want users to save up to 80% on their mints?
Here’s the best part:
Not only do the NFT mint prices become cheaper for individual transactions, but there would also be less network congestion and smaller gas price spikes affecting the Ethereum network during popular collection drops.
Pretty cool stuff.
I wanted to check the work myself, so I implemented two basic NFT contracts that create NFTs:
Next, I called the mint function on each one and logged the gas costs for each transaction.
Here are my results:
You can find the code for these tests in this GitHub repo: demo-erc721a
The gas costs to make multiple NFTS here are slightly different than the ones shown in the Azuki blog post, but they are close, and the increase in gas fees from one mint, two mints, and multiple mints checks out.
We’ve validated the gas savings for batch minting NFTs! ✅
ERC721A makes some assumptions that influence its smart contract design:
With these assumptions in place, ERC721A makes the following contract optimizations:
We’ll take a look at how these optimizations are done, but before that we should understand what kinds of transactions cost the most gas fees.
There are generally two kinds of transactions on the blockchain: writes and reads.
Writes happen when we modify or update blockchain state (e.g. sending money, writing a message, trading an NFT).
Reads happen when we request existing data to look at it.
Users always pay more gas fees for write functions than they pay for read functions.
Therefore, by reducing the number of write transactions, OR by reducing the work required to send write transactions, even if it takes more work to send read transactions later, this will reduce the NFT minting costs that users pay!
And that’s exactly what ERC721A accomplishes.
When it comes to NFT mints: mo’ storage, mo’ problems. Less storage, less problems.
Brilliant, right?
Let’s take a quick tour of the code to really understand how the optimizations work.
Now, in the ERC721Enumerable extension contract, OpenZeppelin adds additional state to track tokenIds and owned tokens:
These functions are necessary for keeping tokenIds organized and for handling other NFT logistics. That’s why so many NFT projects use ERC721Enumerable.
However, maintaining these three additional mappings and one extra array means that for every call to mint a new NFT, all of this state has to be updated.
By studying existing NFT projects, the Azuki team noticed that most NFT projects do not need the excessive set of storage variables, so they re-architected and simplified their design.
The ERC721A contract leverages some new structs to re-implement the base ERC721 state variables for ownership and tracking balances:
The magic lies in how these new structs are used.
In the base ERC721 contract before, this assignment would have had to be done in a loop, one time for each NFT being minted in the batch group. Now it’s done in a single update.
With fewer maps to update, and fewer instances of updates to begin with, each mint transaction costs a lot less, especially as the batch size gets larger and larger!
Cheaper mints sound awesome! Are there any downsides? (Yes)
For example, in the photo below, there are two batch mint calls, one by Alice to mint tokens #100, #101, and #102 all in one call, and another call by Bob to mint tokens #103 and #104.
The ERC721A contract only has to set the ownership metadata twice: once for the Alice’s batch and once for Bob’s batch.
However, this means that transferring a tokenID that does not have an explicit owner address set, the contract has to run a loop across all of the tokenIDs until it reaches the first NFT with an explicit owner address to find the owner that has the right to transfer it, and then set a new owner, thus modifying ownership state more than once to maintain correct groupings.
Here’s a test to simulate transfer scenarios and log gas costs:
They way to read this chart is to go x-axis first, and then y-axis, like:
From these results, we can see that transferring tokenIDs in the middle of a larger mint batch (i.e. t1, t2) costs more than transferring tokenIDs on the ends of the batch (i.e. t0, t4).
Note that this quick experiment only tracks the cost of a single transfer after mint.
Here’s an interesting solution to minimize the total cost of transferring your entire batch of NFTs (original source from William Entriken @fulldecent):
Here is a set of projects that are currently using the ERC721A contract:
And for those who are more adventurous, take some time to check out an even newer optimization of the ERC721 standard called ERC721Psi:
We won’t get into ERC721Psi in this article, but if you’re curious and want to learn more about how that one works, let me know by shooting me a tweet @thatguyintech, and I’ll be sure to do another deep dive on it!
We can even explore deploying some sample projects using Alchemy.
The short answer is yes, ERC721A contracts are definitely NFTs.
Any contract that implements the ERC721 token standard or ERC1155 interfaces are considered non-fungible tokens or semi-fungible tokens.
ERC721A is an extension and optimization of the ERC721 standard.
The same is true for ERC721Enumerable and ERC721Psi.
They’re all part of the ERC721 family!
When you want to get rid of an NFT or a token that you have in your wallet, but you don’t want to give it to another person, and you don’t want to sell it, you can burn it by sending it to a specific wallet address that no one uses.
A lot of people like to use the same burn addresses because they are easy to remember.
For example, the 0 address:
However, when it comes to ERC721A NFTs, you cannot transfer tokens to the 0 address to burn NFTs because most tokens minted in a batch are mapped to the 0 address by default.
Pick another address with which to burn your ERC721A NFTs and you’ll be fine!
The ERC721A contract is a powerful way to save your community gas costs and save the Ethereum network from unnecessary congestion by batch minting NFTs.
Let us know what kind of an NFT project you’re building and how we can help! We have tools to help you deploy, monitor, notify, and market your next NFT collection.
Don’t wait, shoot us a tweet @AlchemyPlatform or send a DM and let’s chat!