Abstract
This article tracks the development of non-fungible token (NFT) standards on Ethereum and alternative chains, evaluating trade-offs between storage efficiency, metadata flexibility, and batch transfers. It explores emerging standards that address on-chain royalty enforcement and composability, offering recommendations for NFT project architects seeking long-term viability.

Introduction

Non-fungible tokens (NFTs) have revolutionized digital ownership, provenance, and scarcity, spawning use cases ranging from digital art to gaming assets and real-world asset tokenization. The first major Ethereum standard, ERC-721, provided a blueprint for unique-token issuance, while ERC-1155 introduced a framework for mixed fungible and non-fungible assets with batch operations. As the NFT ecosystem matures, new standards seek to optimize on-chain storage, embed royalty rules, and enable seamless composability across protocols. This article examines the evolution of NFT standards—focusing on ERC-721, ERC-1155, and successor proposals—to help architects make informed decisions for long-term project success.

1. ERC-721: The Original NFT Standard

1.1 Overview

• Specification
  • Defines two core interfaces: ERC721 and ERC721Metadata.
    • ERC721: balanceOf(address), ownerOf(tokenId), transferFrom, approve, setApprovalForAll, etc.
    • ERC721Metadata: name(), symbol(), tokenURI(tokenId).
  • Each tokenId is guaranteed unique; ownership is tracked via a mapping tokenId → ownerAddress.
• Storage Model
  • Mappings
    • _owners[tokenId] → address
    • _balances[ownerAddress] → uint256
  • Token URIs
    • Stored externally (e.g., IPFS CID, centralized URL) referenced by tokenURI(tokenId).
    • No standardized on-chain metadata schema beyond a string URI.

1.2 Strengths

1. Simplicity
   • Well-defined interface makes integration straightforward for exchanges, wallets, and marketplaces.
2. Provenance and Rarity
   • Uniqueness per tokenId simplifies tracking provenance; each mint is a distinct asset.
3. Ecosystem Support
   • Wide adoption: OpenSea, Rarible, and many marketplaces support ERC-721 out of the box.

1.3 Limitations

1. On-Chain Storage Overhead
   • Minting each NFT increments _owners and _balances, incurring gas costs per token.
   • Large collections (10,000+ NFTs) require repetitive mint calls or batch mints via custom functions.
2. Lack of Batch Transfers
   • No standard method for transferring multiple tokens in a single transaction.
   • Wallets must submit separate transferFrom calls for each tokenId, increasing gas and UX friction.
3. Metadata Flexibility
   • tokenURI only points to an off-chain resource; no on-chain schema for attributes (e.g., traits, rarity tiers).
   • Requires broader off-chain indexers to present attribute data in marketplaces.

2. ERC-1155: A Multi-Token Standard

2.1 Overview

• Specification
  • Defines a single interface for both fungible and non-fungible tokens:
    • balanceOf(address, id), safeTransferFrom(address, address, id, amount, data), safeBatchTransferFrom(address, address, ids[], amounts[], data).
  • Distinguishes token types by numeric id:
    • Fungible tokens: amount > 1 shares same id.
    • Non-fungible tokens: amount == 1 and an id reserved per unique item, often using a bitmask (e.g., 2^255 bit indicates NFT).
• Storage Model
  • Single mapping: _balances[id][ownerAddress] → uint256
  • Batch operations operate over arrays of ids and amounts.

2.2 Strengths

1. Batch Transfers and Minting
   • safeBatchTransferFrom allows sending multiple ids and amounts in one call, reducing gas by an average of 50–70% compared to multiple ERC-721 transfers in bulk.
2. Unified Interface
   • Same contract can manage fungible and non-fungible items, simplifying tooling and wallet integrations.
3. Gas Efficiency
   • Shared mappings lower storage overhead when minting multiple tokens in one transaction—beneficial for on-demand or generative NFT collections.

2.3 Limitations

1. Metadata Standardization
   • Defines optional URI functionality: uri(id) returns a metadata URI with {id} substitution (hex-encoded) — wallet or marketplace must parse and replace token ID.
   • Less straightforward than tokenURI in ERC-721; developers must enforce consistent JSON schemas for metadata.
2. Permission Granularity
   • Approval model via setApprovalForAll grants blanket control over all token IDs of a given contract; no per-ID approvals.
   • Fine-grained delegation (approving a single NFT) requires custom logic, potentially reintroducing ERC-721–style patterns.
3. On-Chain Complexity for True NFTs
   • Strictly speaking, ERC-1155’s fungible/non-fungible distinction is semantic; external conventions must dictate that a particular id is an NFT.
   • Without enforcement, marketplaces may misinterpret amount > 1 versus amount == 1 semantics.

3. Emerging Standards: ERC-721A, ERC-4895, and Beyond

3.1 ERC-721A (Azuki’s Efficient NFT Minting)

• Objective
  • Reduce gas cost per token in large-scale mint events (e.g., 10,000–20,000 NFTs minting in a single transaction).
• Key Innovations
  1. Packed Ownership Structs
     • Store owner address, startTimestamp, and burned status in a single 256-bit uint256, minimizing storage slots.
  2. Lazy Ownership Resolution
     • Only record explicit ownership changes when token is transferred; otherwise, infer owner by scanning backward from tokenId to the last explicitly set owner, drastically cutting writes during batch mints.
  3. Sequential Token IDs
     • Requires sequential assignment of tokenIds at mint time (e.g., 0 to N–1), enabling lazy resolution.
• Benefits
  • Achieves mint costs as low as ~30,000 gas per token when minting 100+ tokens in one transaction.
  • Backward-compatible with ERC-721 interfaces, enabling marketplace integration.
• Trade-Offs
  • Increased gas for lookups in transfer functions due to backward resolution in edge cases.
  • Developers must ensure linear minting sequences, which may conflict with some random assignment or rarity distribution strategies.

3.2 ERC-4895 (Enabling Enumerable Functions for ERC-1155)

• Objective
  • Provide optional enumeration: list all token IDs owned by a user, akin to ERC-721’s tokenOfOwnerByIndex.
• Key Functions
  • balanceOfBatch, tokensOfOwner(address) → id[], totalSupply(id) → uint256 (optional).
  • Internally maintain additional mappings or arrays that track owners per id—incurs extra on-chain cost on mint and burn.
• Benefits
  • Improves discoverability of a user’s holdings in multi-token contracts (e.g., gaming items).
  • Facilitates marketplace listings and portfolio interfaces.
• Trade-Offs
  • Extra storage and gas costs upon minting/burning to maintain enumeration data structures.
  • Potentially unbounded array growth for users with many token types; careful design required to prevent O(n²) gas growth.

3.3 ERC-5069 (On-Chain Royalty Enforcement)

• Motivation
  • Enforce NFT creator royalties at protocol level, preventing marketplaces from bypassing royalty payments.
• Core Interface
  • royaltyInfo(tokenId, salePrice) → (receiver, royaltyAmount)
  • Standardized across enumerable and multi-token contracts, enabling marketplaces to query and distribute royalties on every safeTransferFrom.
• Implementation Options
  • On-Chain Fee Splitting
    • Integrate royalty logic into transfer hooks: split msg.value (sale proceeds) according to defined basis points, forwarding to creator address.
    • Requires marketplace contracts to respect msg.value semantics and perform transfer rather than transferFrom to enforce payments.
  • Protocol-Level Router
    • Route all secondary sales through a standardized router that enforces royaltyInfo checks before approving transfers.
    • May disincentivize non-compliant markets but centralizes enforcement in one contract.
• Challenges
  • Some jurisdictions treat royalties as contractual obligations rather than on-chain protocol rules; projects must align with legal frameworks.
  • Ensuring compatibility with gas-optimized minting contracts (e.g., ERC-721A) can be non-trivial if royalty logic adds conditional branches.

4. Beyond Ethereum: Cross-Chain and Layer-2 NFT Standards

4.1 EIP-838: Universal NFT Standard for EVM-Compatible Chains

• Goal
  • Create a unified set of interfaces for NFTs across any EVM-compatible chain (Polygon, BNB Smart Chain, Avalanche).
  • Ensure that tools (wallets, marketplaces) can interact with NFTs consistently, regardless of underlying chain.
• Key Provisions
  • Standardize event signatures: TransferSingle, TransferBatch, URI, with identical indexed parameters.
  • Enforce supportsInterface for IERC721, IERC1155, and IERC5069 to enable automatic feature detection.
• Benefits
  • Simplifies cross-chain bridging of NFTs: a wrapped NFT on Polygon can use the same interfaces as its Ethereum origin.
  • Reduces fragmentation for multi-chain wallets and marketplaces.
• Trade-Offs
  • Chains with different VM semantics (e.g., Solana’s BPF-based runtime) require adapter layers or wrappers.

4.2 Layer-2 NFT Standards (Optimistic and ZK Rollups)

• OP-L2-NFT (Proposed)
  • Mirrors ERC-721A but adds metadata commitments on-chain via ZK proofs, ensuring off-chain metadata integrity without revealing full JSON schema.
  • Minimizes on-chain calldata by storing only ZK circuit commitments, reducing gas for NFT mint and transfer on layer-2.
• StarkNet-ERC-721
  • Implements a Stark-friendly NFT standard with Cairo-specific constraints:
    • Uses smaller field elements; requires bit-packing of metadata.
    • Batch minting through recursive SNARK proofs to commit to 10,000+ NFTs in a single rollup block.
• Considerations
  • Must ensure that any layer-2 NFT standard interops with Ethereum-based indexing: The canonical tokenURI or URI event must be emitted during state commitment to layer-1.
  • Metadata anchoring: Off-chain metadata should be hashed and included in ZK proof’s public inputs, enabling on-chain verification of authenticity.

5. Designing for Longevity: Recommendations for NFT Architects

Based on the evolution of standards and emerging trends, NFT project architects should consider the following guidelines to maximize long-term viability:

5.1 Choose the Right Base Standard

1. Small Collection (<10,000 items)
   • ERC-721 is sufficient, given its simplicity and ecosystem support.
   • If minting in a single large batch, consider ERC-721A to reduce gas.
2. Large Collection (>10,000 items) or Mixed Asset Types
   • ERC-1155 with clear on-chain conventions for distinguishing NFTs (e.g., top bit of id set).
   • Include ERC-4895 enumeration if users need to query holdings directly on-chain.

5.2 Metadata and Storage Strategies

• On-Chain vs. Off-Chain Metadata
  • Store immutable metadata hashes on-chain (e.g., IPFS CID in tokenURI) to ensure provenance.
  • Use off-chain storage (IPFS, Arweave) for detailed JSON and asset files to avoid excessive on-chain costs.
• Dynamic Metadata
  • For evolving NFTs (e.g., game assets that level up), implement a metadata contract that updates URI values on-chain.
  • Include access controls (onlyOwner or role-based) to prevent unauthorized metadata changes.

5.3 Royalty and Fee Enforcement

• Adopt ERC-5069 Early
  • Integrate royaltyInfo into NFT contracts to facilitate marketplace recognition of royalty rules.
  • Consider on-chain splitting for primary sales when msg.value semantics allow, or rely on standardized routers for secondary market enforcement.
• Governance Overridable Royalties
  • Include a timelock or DAO approval mechanism to adjust royalty rates if market conditions change, balancing creator incentives with secondary market liquidity.

5.4 Batch Operations and Gas Optimization

• Batch Minting and Transfers
  • Use mintBatch and safeBatchTransferFrom for ERC-1155 deployments; use ERC-721A for batch mints to reduce per-token overhead.
  • Document batch-size limits to prevent out-of-gas failures for end-users.
• Optimize Solidity Compiler Settings
  • Enable Solidity optimizer with appropriate runs (e.g., --optimize --optimize-runs 200).
  • Use [immutable] keyword for contract-wide constants (e.g., base URI) to reduce storage reads.

5.5 Cross-Chain Compatibility

• Standardize Events and Interfaces
  • Emit both Transfer (ERC-721) and TransferSingle (ERC-1155) events when applicable for multi-token contracts.
  • Implement supportsInterface for all relevant interfaces, including ERC-5069 for royalties and ERC-4895 for enumeration.
• Bridge Readiness
  • If planning cross-chain expansion, design token IDs with chain-specific namespaces (e.g., using a prefix 0x01 for Ethereum layer, 0x02 for Polygon layer) to avoid ID collisions.
  • Provide mint and burn hooks that bridge contracts can call when locking/unlocking underlying assets.

5.6 Future-Proофing

• Upgradeable Contracts
  • Use OpenZeppelin’s Upgradeable Proxy pattern (UUPS or Transparent) to allow future bug fixes or standard enhancements.
  • Freeze the implementation once stability is achieved, minimizing upgrade risk.
• Governance and Decentralization
  • Decouple minting functions from a single key—use a multisig wallet or DAO to approve large mint events or metadata changes.
  • Publicly document governance processes for transparency, mitigating centralization concerns.

6. Conclusion

NFT standards have advanced significantly since ERC-721’s introduction, addressing scalability, batch operations, and metadata complexity. ERC-1155 introduced a versatile multi-token model that supports batch minting and transfers, reducing gas costs for large-scale projects. Innovations like ERC-721A, ERC-4895, and ERC-5069 optimize minting efficiency, on-chain enumeration, and royalty enforcement. As development moves to layer-2 rollups and alternative chains, maintaining cross-chain compatibility through event standardization and bridge-ready contract design becomes crucial. By selecting appropriate standards, optimizing storage and gas usage, and embedding robust royalty and upgrade patterns, NFT architects can build collections that endure, remain interoperable, and adapt to evolving blockchain ecosystems.

References

1. OpenZeppelin. (2023). “ERC-721A: Efficient ERC721 Contract.” GitHub Repository.
2. Ethereum Improvement Proposal (EIP) 721. (2018). “ERC-721 Non-Fungible Token Standard.”
3. Ethereum Improvement Proposal (EIP) 1155. (2019). “ERC-1155 Multi Token Standard.”
4. Ethereum Improvement Proposal (EIP) 4895. (2022). “ERC-1155 Token Enumeration Extension.”
5. Ethereum Improvement Proposal (EIP) 5069. (2022). “NFT Royalty Standard—On-Chain Enforcement.”
6. Azuki. (2022). “ERC-721A: Optimize Gas for NFT Minting.” Developer Documentation.
7. StarkWare. (2023). “StarkNet NFT Standard.” StarkNet Documentation.
8. IPFS. (2021). “Content Addressable Storage for NFT Metadata.” Documentation.
9. OpenSea Developer Documentation. (2023). “Metadata and Token Standards.”
10. Polygon Technology. (2022). “PoS Bridge NFT Integration Guide.”