NFT Gas Optimization for NFTs 2

Question 1

What is the main gas advantage of using `calldata` instead of `memory` for external function parameters?

Accepted Answer

calldata avoids copying data into memory, reducing gas

Answer

Parameters declared as `calldata` are read directly from the transaction input without being copied to memory, saving gas on reads.

Question 2

How does a Merkle tree allowlist reduce gas costs for NFT mints?

Accepted Answer

It stores only the Merkle root on-chain; users provide a proof at mint time

Answer

Storing just the 32-byte Merkle root on-chain instead of thousands of addresses avoids expensive storage writes during setup.

Question 3

Which deployment pattern minimizes gas when launching many identical NFT contracts (e.g., per-creator collections)?

Accepted Answer

Using the EIP-1167 minimal proxy (clone) pattern

Answer

EIP-1167 minimal proxies deploy a tiny forwarding contract pointing to a shared implementation, reducing deployment gas by ~10x.

Question 4

What does marking a Solidity variable as `immutable` rather than `constant` allow, and how does it affect gas?

Accepted Answer

Immutable variables are set at construction time and inlined in bytecode, saving SLOAD gas at runtime

Answer

Immutable values are embedded directly in contract bytecode after construction, so reading them costs only 3 gas (like a constant) rather than a 2100-gas SLOAD.

Question 5

Why should NFT contracts avoid using `_safeMint` when minting to known EOA addresses in bulk?

Accepted Answer

_safeMint makes an external call to check ERC-721 receiver support, adding gas overhead

Answer

`_safeMint` calls `onERC721Received` on the recipient if it's a contract, adding an external call and re-entrancy guard overhead unnecessary for plain EOAs.

NFT Development Practice Test

NFT Development Practice Test

NFT Gas Optimization for NFTs 2