Engineering NFT Smart Contracts: Mint Logic, Security and Testing

An NFT contract is usually a few hundred lines on top of an audited library, but those lines handle money, supply caps and permanent ownership records. Most NFT exploits come from the custom parts: mint pricing, allowlists, randomness, withdrawals and admin powers.

Choosing the token standard is covered in the NFT token development guide. This page is about writing and shipping the contract.

What the contract does, and what it should not

A contract enforces ownership, transfers and the rules of minting. It replaces a central registry, so nobody can quietly reassign your token, and every transfer is publicly verifiable. It should not try to do everything. Game logic, search, pricing and most business rules belong off-chain, where they can change without migrating tokens. Keep the on-chain part small, predictable and boring.

Start from audited building blocks

Use OpenZeppelin Contracts or a similarly well-reviewed library for ERC-721, ERC-1155, access control and royalty support. ERC-721A is a popular alternative implementation when collections mint many tokens per transaction. Do not hand-write transfer or approval logic; it is where subtle bugs live.

Mint patterns

Public mint

Fixed price, per-wallet cap, global supply cap. Check that the cap is enforced after all mint paths, including owner mints and airdrops.

Merkle allowlist

Store one Merkle root on-chain; each allowlisted wallet submits a proof. Cheap to deploy and to update. Include the wallet address and allowed quantity in each leaf.

Signature mint

A backend signs an EIP-712 message authorizing a specific wallet to mint a specific quantity before a deadline. Flexible, but the signing key becomes a critical secret. Include a nonce or record used signatures so they cannot be replayed, and bind the signature to the chain ID and contract address.

Lazy mint

A creator signs a voucher describing the token; the buyer's transaction mints it and pays the creator. Common on creator platforms. See minting platform development for the product side.

A minimal allowlist check looks like this:

function allowlistMint(uint256 qty, uint256 maxQty, bytes32[] calldata proof)
    external payable
{
    bytes32 leaf = keccak256(bytes.concat(keccak256(abi.encode(msg.sender, maxQty))));
    require(MerkleProof.verify(proof, merkleRoot, leaf), "not allowlisted");
    require(minted[msg.sender] + qty <= maxQty, "over allowance");
    require(totalSupply() + qty <= MAX_SUPPLY, "sold out");
    require(msg.value == qty * price, "wrong payment");
    minted[msg.sender] += qty;
    _mint(msg.sender, qty);
}

Common vulnerabilities

• Reentrancy through safe-mint callbacks. _safeMint calls the receiver's onERC721Received, which can re-enter your mint function. Update counters before minting, or use a reentrancy guard.
• Weak randomness. Using block values for trait assignment or reveal offsets lets miners, validators or bots influence results. Use a commit-reveal scheme or verifiable randomness such as Chainlink VRF.
• Signature replay. Missing nonces, chain IDs or contract addresses in signed messages.
• Broken withdrawals. Funds stuck because withdrawal sends to a contract that rejects ETH, or drained because withdrawal is not access-controlled.
• Overpowered admins. A single key that can mint unlimited tokens, change all metadata and pull funds. Use role separation and a multisig.
• Integer and boundary errors. Off-by-one supply checks that let one extra token through.

Royalties and transfer restrictions

EIP-2981 reports royalties; it does not enforce them. In 2022 and 2023 some collections restricted transfers to marketplaces that paid royalties, through an operator filter registry. OpenSea retired its filter in 2023 and royalties became largely optional on major venues. Restrictions remain useful for tickets and credentials, where the issuer has a reason to control resale; for art they mostly frustrate collectors.

Upgradeability

Proxy contracts let you fix bugs, but they also let the deployer change the rules after people buy. For collectibles, many teams ship an immutable token contract and keep upgradeable logic in separate minter or utility contracts. If you do use a proxy, put the upgrade key behind a multisig and a timelock, and say so publicly.

Testing and audit

1. Unit tests for every mint path, cap and payment calculation.
2. Fuzz tests (Foundry makes these easy) for quantities, prices and allowlist proofs.
3. Invariant tests: total minted never exceeds max supply; contract balance equals payments minus withdrawals.
4. A mainnet-fork rehearsal of the full launch, including the reveal and withdrawal.
5. An external audit, with fixes re-reviewed. See smart contract audits and why audits matter.
6. Verify source on the block explorer at deployment.

For broader Solidity practice beyond NFTs, see Ethereum smart contract development.

Frequently asked questions