Practice Test GeeksNFT Development Practice Test
← All NFT Flashcard Decks

Smart Contract Security Flashcards

7 cards from real NFT practice questions. Tap to flip, then mark Knew It or Still Learning — missed cards come back until you master them.

Read the first 7 Smart Contract Security flashcards as text

  1. What is a signature replay attack against an NFT lazy-minting voucher?

    Answer: The same signed voucher is reused to mint multiple times because no nonce or used-flag tracks it

    Without a nonce or used-voucher mapping, a valid signature can be replayed to mint repeatedly.

  2. How does EIP-712 typed structured data improve signature security in NFT minting?

    Answer: It produces human-readable, domain-separated hashes that resist cross-contract replay

    EIP-712 includes a domain separator and typed data so signatures are bound to a specific contract and chain, preventing reuse elsewhere.

  3. Why should a contract include a chain ID in its EIP-712 domain separator?

    Answer: To prevent a signature valid on one chain from being replayed on a forked or different chain

    Including the chain ID stops signatures from being replayed across chains such as forks or testnets.

  4. What is signature malleability and why does ecrecover require care?

    Answer: An ECDSA signature can have two valid s-values, so contracts must restrict s to the lower half to avoid duplicates

    ECDSA allows two valid s values for one signature; enforcing the lower-half s (as OpenZeppelin's ECDSA does) prevents malleability issues.

  5. Why must ecrecover's return value be checked against address(0)?

    Answer: ecrecover returns the zero address on invalid input, which could bypass checks if not validated

    An invalid signature makes ecrecover return address(0), so unvalidated results can be exploited to forge authorization.

  6. What is the security benefit of using a Merkle proof allowlist for NFT presale minting?

    Answer: Only one root is stored on-chain while membership is proven off-chain, saving gas and preventing unauthorized mints

    A Merkle root lets the contract verify allowlist membership via a proof without storing every address, gating mints efficiently.

  7. Why is hardcoding a privileged owner address without a transfer/renounce mechanism risky?

    Answer: A compromised or lost key permanently controls or bricks the contract with no recovery path

    Without ownership transfer or renounce functions, a lost or stolen key leaves the contract permanently mismanaged.