Minting and Burning Mechanics Flashcards

Which storage pattern enforces a hard cap on the number of NFTs that can ever be minted?

Answer: A require check comparing totalSupply() against a MAX_SUPPLY constant

Comparing current supply to a maximum constant before minting enforces a supply cap.

What is a common reentrancy risk in a mint function that uses _safeMint?

Answer: onERC721Received callback can re-enter before state updates complete

_safeMint invokes the recipient's onERC721Received hook, which can re-enter if state isn't updated first.

To mitigate reentrancy during minting, which principle should be followed?

Answer: Checks-Effects-Interactions: update state before external calls

Updating contract state before making external calls prevents reentrant exploitation.

Why might a contract use a counter (e.g., Counters.Counter) for tokenIds during minting?

Answer: To guarantee unique, sequentially increasing token ids

A counter ensures each minted token receives a unique, monotonically increasing id.

What risk arises if a mint function reads the per-wallet mint limit from tx.origin instead of msg.sender?

Answer: A contract intermediary can bypass the per-wallet limit

Using tx.origin lets relayer/contract patterns circumvent per-wallet checks and is generally unsafe.

When burning frees storage by zeroing the owner mapping, what EVM mechanism partially refunds gas?

Answer: The SSTORE gas refund for clearing a storage slot

Clearing a non-zero storage slot to zero triggers an SSTORE gas refund.

What is a key reason to make the mint price and supply checks happen before _mint in a public sale?

Answer: To revert early and avoid minting if conditions aren't met

Validating payment and supply before minting ensures invalid transactions revert without side effects.