Allowlist and Presale Mechanics Flashcards

What is the main security benefit of using EIP-712 typed data signing for NFT allowlist signatures over signing a raw keccak256 hash?

Answer: EIP-712 displays a structured, human-readable breakdown in the wallet UI, helping users recognize and avoid signing malicious messages

EIP-712 structures the data so wallets like MetaMask render a readable summary of what is being signed (fields, values, domain), making phishing attacks that trick users into signing harmful messages much harder.

In a multi-tier allowlist where different addresses have different mint allocations, how is this efficiently encoded in a single Merkle tree?

Answer: Include the allocation quantity in the leaf: keccak256(abi.encodePacked(address, quantity)), then verify both address and quantity on-chain

Packing both the address and the quantity into the leaf hash cryptographically binds the proof to a specific allocation, so a holder of a 2-mint allocation cannot forge a proof claiming 5 mints.

What is the risk of not atomically checking and updating the per-address mint counter during an allowlist mint?

Answer: A valid allowlist member can call mint() multiple times before the counter increments, minting more than their allocation allows

If the counter is read but not updated before the external call or the next state check, a reentrancy or front-running scenario can allow the same address to mint beyond its limit — the counter must be incremented before any external interaction.

Why should the Merkle root setter function be restricted with onlyOwner and emit an event?

Answer: To restrict allowlist changes to authorized parties and create an auditable on-chain record that dApps and users can monitor for unauthorized updates

onlyOwner prevents unauthorized parties from swapping in a different allowlist, while the emitted event lets front-ends and community members detect any root change and audit who was added or removed.

What breaks proof verification if a developer uses abi.encode() instead of abi.encodePacked() when hashing Merkle leaves in Solidity?

Answer: abi.encode() pads values to 32 bytes with type metadata, producing different hashes than the JavaScript library that uses the equivalent of encodePacked, so all proofs fail

JavaScript leaf generation (e.g., ethers.utils.solidityKeccak256) mirrors encodePacked; using abi.encode() on-chain inserts extra padding bytes, producing a different hash that will never match the client-generated leaf.

Why should chainId be included in the signed payload for signature-based NFT allowlists?

Answer: To prevent cross-chain replay attacks where a valid mainnet signature is reused on a testnet or another EVM chain

Binding the signature to a specific chainId ensures it is only valid on that network, preventing an attacker from taking a mainnet allowlist signature and using it to mint on Goerli, Sepolia, or another EVM chain.

Which approach is most scalable for an allowlist of 500,000 addresses while keeping on-chain gas costs minimal?

Answer: Use a Merkle tree with only the root stored on-chain; users supply their proof (about 19 hashes) at mint time

A Merkle tree for 500,000 addresses is only ~19 levels deep, so each proof costs roughly 19 keccak256 operations on-chain — a tiny fixed cost regardless of list size, compared to storing 500,000 storage slots.