NFT Allowlist and Presale Mechanics

Question 1

What data structure is most commonly used to implement gas-efficient NFT allowlists on Ethereum?

Accepted Answer

Merkle tree

Answer

Merkle trees represent the entire allowlist with a single 32-byte root stored on-chain, while users provide off-chain proofs to verify membership.

Question 2

In a Merkle tree allowlist, what must a user provide at mint time to prove they are on the list?

Accepted Answer

A Merkle proof consisting of sibling hashes along the tree path

Answer

A Merkle proof is an array of sibling hashes from the leaf up to the root, enabling anyone to recompute and verify the root without storing the full list on-chain.

Question 3

Which OpenZeppelin library provides Merkle proof verification for NFT allowlists?

Accepted Answer

@openzeppelin/contracts/utils/cryptography/MerkleProof.sol

Answer

OpenZeppelin's MerkleProof.sol exposes the verify() function that checks whether a given proof correctly maps a leaf to the stored root.

Question 4

What is the primary gas advantage of Merkle tree allowlists over storing all allowed addresses in an on-chain mapping?

Accepted Answer

Only the 32-byte root is stored on-chain, regardless of how many addresses are allowlisted

Answer

Storing a Merkle root costs one SSTORE (32 bytes), whereas an on-chain mapping requires one storage slot per address, making large allowlists orders of magnitude cheaper with Merkle trees.

Question 5

How is a Merkle leaf typically generated from an Ethereum address in Solidity for allowlist verification?

Accepted Answer

keccak256(abi.encodePacked(address))

Answer

The standard convention is keccak256(abi.encodePacked(address)), which matches how JavaScript libraries like merkletreejs generate leaves, ensuring proof compatibility.

NFT Development Practice Test

NFT Development Practice Test

NFT Allowlist and Presale Mechanics