ERC721 is the standard for Non-Fungible Tokens, NFTs, and it’s the commonly accepted one. Most NFTs you encounter adhere to this standard. It’s tried and tested. However, there’s always room for improvement, which brings us to the new realization of this standard with the name ERC721a. The project’s GitHub repository already has 1.4k stars, so today we are looking into this version.
What’s the difference?
The ERC721а implementation of the standard looks like the next step for NFTs. Like most software, it’s released under the MIT License, there are several NFT projects that have already implemented the standard.
ERC721a is said to be an improvement over the current most popular implementation of ERC721 ERC721Enumerable from OpenZeppelin and allows minting multiple tokens for nearly the price of minting one.
So the main feature and difference between ERC721a and ERC721 is the former’s optimized gas spending. The project owners emphasized gas efficiency, noting that constantly growing fees affect the market.
A recently held BAYC land sale illustrates the importance of gas usage optimization. Within a few hours, approximately $100 million was spent on gas. Meanwhile, the analysis presented on Twitter, states that $80m could’ve been saved had ERC721a been used instead of OpenZeppelin’s ERC721Enumerable as an NFT and a couple of other simple optimizations.
If you look at the website of the standard, it actively invites users to try ERC721a specifically if they are looking to save gas. There’s, however, an issue within the code that has to be considered. HashEx auditors took the time to study the standard and present the findings.
The Findings
The main feature of the current implementation of the standard is optimized gas usage. However, despite the initially stated advantage, most gas-related optimizations actually affect the functions that are called by the project owners — for instance, batch minting of the tokens.
For the user any interaction with the contracts be it transfer, marketplace transactions with the check of the token owner, or any other actions, may actually consume more gas than a typical OpenZeppelin implementation (Enumerable version) during the creation of large batches of tokens (over 100 tokens per batch).
Saving on gas is achieved mostly through restricting the maximum number of tokens from 2256 to 264. It’s because of this, that the developers using this implementation have to consider possible issues with integer overflow and underflow.
HashEx has performed an audit of this implementation, which is available here: https://github.com/HashEx/public_audits/blob/master/ERC721A/ERC721A.pdf
Several issues, of different severity, have been found during the audit.
HashEx has discovered 1 medium severity and 3 informational severity issues.
Source NFT Culture
