📌 Contribution guidelines

[Vectorized]

On Golfing

While we love gas efficient code, we need to strike a balance between performance, readability, extendability.

As such, we will need to be more selective on gas optimizations going forward.

While it is possible to rewrite 80%+ of the library in assembly, substituting a 1 liner in Solidity with 30 lines of assembly to save 3 gas is not exactly conducive for maintaining the overall balance.

We have purposefully included some examples for demonstration purposes where appropriate, for example the included _toString method, which would likely be substituted with an external assembly based library otherwise; but for the general scope, it is best to stick to Solidity if possible.

More gas savings can be done by proper choice of overall approach outside of ERC721A,
and combining + utilizing various libraries (e.g. Solmate, OpenZeppelin, ERC721A) to their fullest potential.

Nevertheless, if you have an interesting idea, do feel free to open a issue or PR. Even if the gas saved may not be much, it can open new insights into the subtleties of the language and inspire new ideas. Your PR may not be accepted (balance is a very subjective issue), but it will still be greatly appreciated.

Extensions to be Excluded

The OpenZeppelin project has several ERC721 extensions.

• ERC721URIStorage.sol
• ERC721Pausable.sol
• ERC721Royalty.sol

In my opinion, the functionality of these extensions should NOT be included in ERC721A for the following reasons:

• They are orthogonal to ERC721A's logic.

  • Can be implemented easily by devs with just a few lines of code via overriding the beforeTokensTransfer hook.
  • Self implementations can be easily made more efficient (e.g. use a bool packed with the sale state for Pausable).

• Manual overriding of the beforeTokensTransfer hook gives more flexibility and neater inheritance, especially when combining two or more features.

• For repo maintainability.

  • Some extensions (Royalty, Pausable) are mainly just importing OpenZeppelin's libraries + a few lines of code.
  • Heavy duplication of documentation and test cases must be maintained on our side to match any updates on OpenZeppelin's side.
  • Alternatively, in-sourcing the code will lead to a loss of focus.

Our main purpose is to provide efficient batch minting for the ERC721 standard.
When applicable, we may include additional features (e.g. holding startTimestamp, _numberMinted)
when the additional gas overhead is neligible ("storage hitchhiking").

The remaining extensions (Burnable, Queryable) are heavily interwoven with ERC721A's core logic.
These should be kept.

I would like to take this chance to refer readers to the comment of the t11s:

https://twitter.com/transmissions11/status/1510015319334535170

As much as we like to offer features for convenience, we must also know when to exclude features.

If you need code examples on how to self-implement these excluded functionality, please feel free to request.