Allowlist and Presale Mechanics Flashcards

What is the key architectural difference between signature-based allowlisting and Merkle tree allowlisting?

Answer: Signature-based requires a trusted backend signer to issue per-user signatures; Merkle-based uses a precomputed tree with a single on-chain root

In signature-based allowlisting a trusted signer generates individual ECDSA signatures for each user, while Merkle trees precompute the full tree off-chain and store only the root, requiring no active signer at mint time.

In an ECDSA signature-based allowlist, what does the NFT smart contract verify during a mint call?

Answer: That the address recovered from the signature using ecrecover() matches the stored trusted signer address

The contract hashes the message, calls ecrecover() with the signature, and checks that the recovered address equals the stored trustedSigner variable, confirming the signature was created by an authorized party.

What is a signature replay attack in the context of NFT allowlists, and how is it prevented?

Answer: Submitting a valid signature multiple times to mint more NFTs than intended; prevented by tracking used signatures or including per-address nonces

A replay attack reuses a valid signature to call mint() repeatedly; the fix is to record signatures in a mapping after first use or to embed a nonce in the signed message that is incremented and validated on-chain.

How should an NFT contract correctly enforce per-address mint limits during a presale?

Answer: Maintain a mapping(address => uint256) on-chain that records how many tokens each address has minted, checked and updated atomically with the mint

A mapping(address => uint256) updated inside the mint function atomically records each address's usage, allowing the contract to revert if the caller exceeds their allowed quantity.

Which built-in Ethereum function is used in Solidity to recover the signing address from an ECDSA signature?

Answer: ecrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s)

ecrecover() is an Ethereum precompile that accepts a message hash and the three signature components (v, r, s) and returns the Ethereum address whose private key produced that signature.

Why should the contract address be included in the signed message payload for signature-based allowlists?

Answer: To prevent cross-contract replay attacks where a valid signature for one NFT collection is submitted to a different collection's contract

Binding the signature to a specific contract address ensures it cannot be replayed against a different contract that uses the same trusted signer, even if deployed by the same team.

What is the standard pattern for managing multiple minting phases (closed, allowlist, public sale) in an NFT smart contract?

Answer: Define an enum for sale phases, store the current phase in a state variable, and let the owner advance it with an onlyOwner setter

An enum (e.g., enum Phase { CLOSED, ALLOWLIST, PUBLIC }) paired with a state variable and an onlyOwner transition function is the canonical, auditable on-chain pattern for phase management.