ERC-721A: Gas-Efficient NFT Minting at Scale

TL;DR

I have shipped NFT collections using both ERC-721 and ERC-721A, and the gas savings from ERC-721A are not marginal — they are transformational. Minting 10 NFTs with standard ERC-721 costs roughly 10x the gas of minting a single one. With ERC-721A, minting 10 costs nearly the same as minting 1. This guide covers the exact mechanics behind those savings, a production-ready minting contract with Merkle tree whitelists and delayed reveal, real gas benchmarks from contracts I have deployed, and the pitfalls that trip up most developers. If you are planning an NFT drop and want to give your community the cheapest possible mint, this is the implementation I use for every client project through my services.

ERC-721 vs ERC-721A — Gas Comparison

Standard ERC-721, specifically the OpenZeppelin implementation, writes to storage on every single mint. Each token gets its own ownership record and its own balance update. When a user mints 5 NFTs in one transaction, that is 5 separate SSTORE operations for ownership and 5 balance increments. In Ethereum, SSTORE to a new storage slot costs 20,000 gas. That adds up fast.

ERC-721A, created by the Azuki team, fundamentally rethinks how ownership is tracked. Instead of writing one storage slot per token, it writes ownership data only for the first token in a batch. Tokens 2 through N in the batch are inferred by looking backward through storage until an explicit ownership record is found. The balance is updated once regardless of batch size.

Here is what that looks like in practice:

Standard ERC-721 — Minting 5 tokens:
  Token #1: SSTORE owner = 0xABC    (20,000 gas)
  Token #2: SSTORE owner = 0xABC    (20,000 gas)
  Token #3: SSTORE owner = 0xABC    (20,000 gas)
  Token #4: SSTORE owner = 0xABC    (20,000 gas)
  Token #5: SSTORE owner = 0xABC    (20,000 gas)
  Balance:  SSTORE balance += 5     (5 separate writes)
  Total storage writes: 10

ERC-721A — Minting 5 tokens:
  Token #1: SSTORE owner = 0xABC    (20,000 gas)
  Token #2: (no write — inferred)
  Token #3: (no write — inferred)
  Token #4: (no write — inferred)
  Token #5: (no write — inferred)
  Balance:  SSTORE balance += 5     (1 write)
  Total storage writes: 2

The tradeoff is clear: ERC-721A shifts cost from minting to transferring. When a user transfers token #3 from the batch above, the contract must write an explicit ownership record for token #4 so the chain of inference is not broken. First-time transfers cost slightly more gas. But for NFT drops where the primary user action is minting, this is the right tradeoff almost every time.

How ERC-721A Saves Gas

The gas savings come from three specific optimizations that work together.

1. Lazy Ownership Initialization

In ERC-721A, the _ownerOf mapping is not populated for every token. When you call ownerOf(tokenId), the contract scans backward from tokenId until it finds an explicitly set owner. For tokens minted in the same batch, the first token holds the owner address, and all subsequent tokens return that same owner until a different ownership record is found.

// Simplified ERC-721A ownership lookup
function ownerOf(uint256 tokenId) public view returns (address) {
    // Scan backward from tokenId
    for (uint256 curr = tokenId; curr >= _startTokenId(); ) {
        address owner = _ownerships[curr].addr;
        if (owner != address(0)) {
            return owner;
        }
        unchecked { curr--; }
    }
    revert OwnerQueryForNonexistentToken();
}

This means a mint of 20 tokens only writes ownership data once. The gas difference between minting 1 and minting 20 is negligible from a storage perspective.

2. Packed Storage Slots

ERC-721A packs the owner address and auxiliary data into a single 256-bit storage slot. The ownership struct looks like this:

struct TokenOwnership {
    address addr;        // 160 bits — owner address
    uint64 startTimestamp; // 64 bits — mint timestamp
    bool burned;         // 8 bits — burn flag
    uint24 extraData;    // 24 bits — custom data
}

All 256 bits of a single storage slot are used. No wasted space, no extra slots for metadata that could be packed alongside the address. This means reading ownership data is always a single SLOAD (2,100 gas for warm, 100 gas after first access in a transaction).

3. Batch Balance Update

Standard ERC-721 increments the balance mapping inside a loop — one SSTORE per token. ERC-721A increments the balance once per batch:

// Standard ERC-721 (inside a loop)
_balances[to] += 1; // Called N times = N SSTORE operations

// ERC-721A (single operation)
_balances[to] += quantity; // Called once regardless of batch size

This alone saves (N - 1) * 5,000 gas for warm storage writes when minting N tokens.

Implementation Guide

Here is the project structure I use for ERC-721A NFT drops. Every file has a clear purpose, and the separation keeps the minting logic, access control, and reveal mechanism cleanly isolated.

contracts/
  src/
    AzukiDrop.sol            # Main minting contract
    interfaces/
      IAzukiDrop.sol         # External interface
  test/
    AzukiDrop.t.sol          # Foundry tests
    MerkleHelper.sol         # Test helper for proof generation
  script/
    Deploy.s.sol             # Deployment script
    GenerateMerkle.s.sol     # Merkle root generation

Install ERC-721A in your Foundry project:

forge install chiru-labs/ERC721A --no-commit

Add the remapping to foundry.toml:

[profile.default]
remappings = [
    "erc721a/=lib/ERC721A/"
]

Batch Minting Contract

This is a production-ready contract I have used as the foundation for multiple client drops. It includes supply caps, per-wallet limits, phase-based minting (whitelist then public), and proper access control.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.24;

import "erc721a/contracts/ERC721A.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";
import "@openzeppelin/contracts/utils/ReentrancyGuard.sol";

contract GasEfficientDrop is ERC721A, Ownable, ReentrancyGuard {
    uint256 public constant MAX_SUPPLY = 10_000;
    uint256 public constant MAX_PER_WALLET = 5;
    uint256 public constant WHITELIST_PRICE = 0.05 ether;
    uint256 public constant PUBLIC_PRICE = 0.08 ether;

    enum Phase { Paused, Whitelist, Public }

    Phase public currentPhase;
    bytes32 public merkleRoot;
    string private _baseTokenURI;
    string private _preRevealURI;
    bool public revealed;

    mapping(address => uint256) public whitelistMinted;

    error ExceedsMaxSupply();
    error ExceedsWalletLimit();
    error InsufficientPayment();
    error InvalidProof();
    error MintingPaused();
    error NotWhitelistPhase();
    error NotPublicPhase();
    error WithdrawFailed();

    constructor(
        string memory preRevealURI,
        bytes32 _merkleRoot
    ) ERC721A("GasEfficientDrop", "GED") Ownable(msg.sender) {
        _preRevealURI = preRevealURI;
        merkleRoot = _merkleRoot;
    }

    function whitelistMint(
        uint256 quantity,
        bytes32[] calldata proof
    ) external payable nonReentrant {
        if (currentPhase != Phase.Whitelist) revert NotWhitelistPhase();
        if (totalSupply() + quantity > MAX_SUPPLY) revert ExceedsMaxSupply();
        if (whitelistMinted[msg.sender] + quantity > MAX_PER_WALLET) {
            revert ExceedsWalletLimit();
        }
        if (msg.value < WHITELIST_PRICE * quantity) {
            revert InsufficientPayment();
        }

        bytes32 leaf = keccak256(abi.encodePacked(msg.sender));
        if (!MerkleProof.verify(proof, merkleRoot, leaf)) {
            revert InvalidProof();
        }

        whitelistMinted[msg.sender] += quantity;
        _mint(msg.sender, quantity);
    }

    function publicMint(uint256 quantity) external payable nonReentrant {
        if (currentPhase != Phase.Public) revert NotPublicPhase();
        if (totalSupply() + quantity > MAX_SUPPLY) revert ExceedsMaxSupply();
        if (_numberMinted(msg.sender) + quantity > MAX_PER_WALLET) {
            revert ExceedsWalletLimit();
        }
        if (msg.value < PUBLIC_PRICE * quantity) {
            revert InsufficientPayment();
        }

        _mint(msg.sender, quantity);
    }

    function setPhase(Phase phase) external onlyOwner {
        currentPhase = phase;
    }

    function setMerkleRoot(bytes32 _merkleRoot) external onlyOwner {
        merkleRoot = _merkleRoot;
    }

    function reveal(string memory baseURI) external onlyOwner {
        _baseTokenURI = baseURI;
        revealed = true;
    }

    function tokenURI(
        uint256 tokenId
    ) public view override returns (string memory) {
        if (!_exists(tokenId)) revert URIQueryForNonexistentToken();

        if (!revealed) {
            return _preRevealURI;
        }

        return string(
            abi.encodePacked(_baseTokenURI, _toString(tokenId), ".json")
        );
    }

    function withdraw() external onlyOwner {
        (bool success, ) = payable(owner()).call{value: address(this).balance}(
            ""
        );
        if (!success) revert WithdrawFailed();
    }

    function _startTokenId() internal pure override returns (uint256) {
        return 1;
    }
}

A few design decisions worth calling out:

Custom errors over require strings. Custom errors are cheaper to deploy and cheaper to revert with. A require(condition, "some string") stores that string in the contract bytecode and includes it in the revert data. Custom errors use selector-based encoding — 4 bytes instead of a dynamic string.

`_startTokenId()` override. By default, ERC-721A starts token IDs at 0. I override to start at 1 because marketplaces and frontends almost universally expect token IDs starting at 1, and it avoids confusion with the zero-address check pattern.

Separate whitelist tracking. The whitelistMinted mapping tracks whitelist mints independently from _numberMinted(). This means a user who mints 3 during whitelist can still mint 2 more during the public phase, up to the total wallet limit. I have seen contracts that accidentally block whitelist minters from public minting by using a single counter.

Whitelist with Merkle Tree

Merkle trees are the standard for on-chain whitelists because they reduce storage cost to a single bytes32 root. Instead of storing thousands of addresses on-chain, you store one hash and let users provide proofs.

Here is how I generate the Merkle tree off-chain:

import { StandardMerkleTree } from "@openzeppelin/merkle-tree";
import { writeFileSync } from "fs";

const whitelist: [string][] = [
  ["0x1234567890abcdef1234567890abcdef12345678"],
  ["0xabcdefabcdefabcdefabcdefabcdefabcdefabcd"],
  ["0x9876543210fedcba9876543210fedcba98765432"],
  // ... up to thousands of addresses
];

const tree = StandardMerkleTree.of(whitelist, ["address"]);

console.log("Merkle Root:", tree.root);

// Save tree for proof generation later
writeFileSync("merkle-tree.json", JSON.stringify(tree.dump()));

// Generate proof for a specific address
for (const [i, v] of tree.entries()) {
  if (v[0] === "0x1234567890abcdef1234567890abcdef12345678") {
    const proof = tree.getProof(i);
    console.log("Proof:", proof);
  }
}

On the frontend, the user's proof is fetched and passed to the contract call:

import { useWriteContract } from "wagmi";
import { parseEther } from "viem";
import treeData from "./merkle-tree.json";
import { StandardMerkleTree } from "@openzeppelin/merkle-tree";

function useWhitelistMint() {
  const { writeContract } = useWriteContract();

  function mint(quantity: number, userAddress: string) {
    const tree = StandardMerkleTree.load(treeData);
    let proof: string[] = [];

    for (const [i, v] of tree.entries()) {
      if (v[0].toLowerCase() === userAddress.toLowerCase()) {
        proof = tree.getProof(i);
        break;
      }
    }

    writeContract({
      address: CONTRACT_ADDRESS,
      abi: CONTRACT_ABI,
      functionName: "whitelistMint",
      args: [BigInt(quantity), proof],
      value: parseEther((0.05 * quantity).toString()),
    });
  }

  return { mint };
}

One thing I always tell clients: do not expose the full Merkle tree JSON publicly. While the proofs themselves are not secret (they are submitted on-chain), exposing the tree reveals the entire whitelist before minting starts. Host the proof generation server-side and return only the proof for the authenticated user.

Reveal Mechanism

Delayed reveal is standard for NFT drops. All tokens initially point to a single pre-reveal metadata URI (usually a placeholder image), and the real metadata is revealed after minting completes. This prevents sniping — nobody can see which tokens have rare traits before they are all minted.

The contract I showed above handles this with a simple boolean flag and URI swap. The tokenURI function returns _preRevealURI for all tokens until the owner calls reveal(), which sets the base URI and flips the flag.

For projects that need provably fair randomization, I add a provenance hash and a randomized offset:

uint256 public revealOffset;
string public provenanceHash;

function setProvenanceHash(string memory hash) external onlyOwner {
    provenanceHash = hash;
}

function reveal(
    string memory baseURI,
    uint256 randomSeed
) external onlyOwner {
    _baseTokenURI = baseURI;
    revealOffset = randomSeed % MAX_SUPPLY;
    revealed = true;
}

function tokenURI(
    uint256 tokenId
) public view override returns (string memory) {
    if (!_exists(tokenId)) revert URIQueryForNonexistentToken();

    if (!revealed) {
        return _preRevealURI;
    }

    uint256 metadataId = (tokenId + revealOffset) % MAX_SUPPLY;
    return string(
        abi.encodePacked(
            _baseTokenURI,
            _toString(metadataId),
            ".json"
        )
    );
}

The provenance hash is the hash of all metadata concatenated in order. It is published before minting starts. After minting, the random offset shifts which metadata maps to which token ID. Anyone can verify that the metadata was not tampered with by comparing the provenance hash, and the offset ensures the assignment is not predictable during minting.

For the random seed, I use Chainlink VRF on mainnet. For smaller drops where the cost of VRF is not justified, I use block.prevrandao combined with a commitment scheme — the owner commits a secret hash before minting, then reveals it post-mint, and the seed is derived from the secret plus on-chain data.

Gas Benchmarks with Real Numbers

These benchmarks come from contracts I deployed on Ethereum mainnet and Arbitrum. I ran the same test suite against both an OpenZeppelin ERC-721 implementation and an ERC-721A implementation with identical functionality (supply cap, per-wallet limits, same metadata logic).

Key observations from these numbers:

Minting 1 token is slightly more expensive with ERC-721A. The packed struct and additional logic add around 1,700 gas for single mints. This is negligible — about $0.05 at 30 gwei and $3,000 ETH.

The savings compound with batch size. At 5 tokens, you save 71.9%. At 20 tokens, you save 89.7%. For a 10,000-token collection where the average mint size is 3-5 tokens, ERC-721A saves your community hundreds of ETH collectively.

First transfers cost more. When a token in the middle of a batch is transferred for the first time, ERC-721A must write the ownership record for the next token to preserve the inference chain. This adds roughly 24,000 gas to the first transfer. Subsequent transfers cost the same as standard ERC-721.

`ownerOf()` has variable cost. For the first token in a batch, ownerOf() is a single SLOAD. For the last token in a batch of 20, the contract scans backward through up to 20 slots. In practice, this is still cheap — under 8,000 gas even for large batches — and it only affects view calls, which are free off-chain.

At current gas prices (as of mid-2024), here is what the savings mean in USD terms on Ethereum mainnet at 30 gwei and ETH at $3,500:

For a 10,000-token collection with an average mint of 3 tokens, the total gas savings across all minters is approximately 350-400 ETH, or over $1 million at those prices. That is money staying in your community's wallets instead of going to validators.

Common Pitfalls

I have reviewed dozens of ERC-721A contracts, and the same mistakes keep showing up. Here are the ones that will cost you — either in gas, security, or a failed launch.

1. Using _safeMint When You Do Not Need It

// Wasteful — adds re-entrancy surface and gas overhead
_safeMint(msg.sender, quantity);

// Better — use _mint with nonReentrant modifier on the function
_mint(msg.sender, quantity);

_safeMint calls onERC721Received on the recipient if it is a contract. This adds gas and opens a re-entrancy vector. For public mints where msg.sender is always an EOA (enforced by tx.origin == msg.sender or simply by design), _mint is sufficient. I use _mint with nonReentrant on all minting functions.

2. Forgetting the Transfer Gas Tradeoff

Some projects launch with ERC-721A without telling their community that first transfers cost more. This leads to confused users posting "why did my transfer cost more than my friend's?" on Discord. Set expectations early. Put it in your FAQ. The overall savings still massively favor ERC-721A, but transparency builds trust.

3. Not Overriding _startTokenId()

// Default: tokens start at 0
// Override to start at 1:
function _startTokenId() internal pure override returns (uint256) {
    return 1;
}

Token ID 0 is a valid token in ERC-721A by default. This causes issues with frontends that use 0 as a sentinel value for "no token" and with marketplaces that display token #0 inconsistently. Always override to start at 1.

4. Exceeding Reasonable Batch Sizes

ERC-721A does not cap batch size. A user could theoretically mint 1,000 tokens in one transaction. This creates a gas estimation nightmare and can hit block gas limits. Always enforce a per-transaction limit:

uint256 public constant MAX_PER_TX = 10;

function publicMint(uint256 quantity) external payable {
    if (quantity > MAX_PER_TX) revert ExceedsTxLimit();
    // ...
}

5. Not Testing ownerOf After Partial Transfers

The backward scanning in ownerOf has edge cases. If a user mints tokens 1-5, then transfers token 3, the ownership map now has explicit records at tokens 1, 3 (new owner), and 4 (original owner, written during transfer). Test these scenarios thoroughly:

function testOwnershipAfterPartialTransfer() public {
    // Mint batch of 5 to alice
    vm.prank(alice);
    drop.publicMint{value: 0.4 ether}(5);

    // Transfer token 3 to bob
    vm.prank(alice);
    drop.transferFrom(alice, bob, 3);

    // Verify ownership chain
    assertEq(drop.ownerOf(1), alice);
    assertEq(drop.ownerOf(2), alice);
    assertEq(drop.ownerOf(3), bob);
    assertEq(drop.ownerOf(4), alice); // Must still be alice
    assertEq(drop.ownerOf(5), alice);
}

6. Ignoring ERC-721A Extensions

ERC-721A ships with useful extensions that many developers overlook:

• ERC721AQueryable — adds tokensOfOwner() which returns all token IDs owned by an address. Extremely useful for frontends. Standard ERC-721 has no equivalent without indexing.
• ERC721ABurnable — adds gas-efficient burn functionality that respects the packed ownership model.
• ERC721AConsecutive — optimized for airdrops where the owner pre-mints a large batch and transfers individually.

import "erc721a/contracts/extensions/ERC721AQueryable.sol";

contract MyDrop is ERC721AQueryable {
    // tokensOfOwner(address) is now available
    // tokenIds are returned as a uint256[] array
}

Key Takeaways

1. ERC-721A saves 40-90% gas on batch mints depending on batch size. For any collection where users mint more than 1 token, the savings are substantial.

1. The tradeoff is transfer cost. First transfers cost roughly 24,000 more gas. For mint-heavy use cases (PFP drops, generative art, membership passes), this tradeoff is almost always worth it.

1. Use Merkle trees for whitelists. Storing one bytes32 root instead of thousands of addresses saves massive deployment gas and is the industry standard.

1. Implement delayed reveal properly. Use a provenance hash committed before minting and a verifiable random offset. Chainlink VRF for high-value drops, commitment schemes for smaller ones.

1. Enforce per-transaction and per-wallet limits. ERC-721A does not cap batch size by default. Without limits, bots will drain your supply in a single transaction.

1. Test ownership after partial transfers. The backward scanning logic in ownerOf is correct but not intuitive. Write explicit tests for every transfer scenario.

1. Use extensions. ERC721AQueryable saves your frontend from needing a subgraph just to list a user's tokens. Ship it by default.

If you are planning an NFT drop and want production-grade contracts with proper gas optimization, Merkle whitelists, and battle-tested reveal mechanics, check out my services. I have shipped collections across Ethereum, Arbitrum, and Base — every one using ERC-721A as the foundation.

*Written by Uvin Vindula↗ — Web3 engineer and builder based between Sri Lanka and the UK. I build production smart contracts, DeFi protocols, and full-stack dApps. Find me at @IAMUVIN↗ or reach out at contact@uvin.lk↗.*