ERC-721 and ERC-1155 with IPFS Metadata — Smart Contract NFTs That Actually Work

Why an NFT is not just an expensive image

When a client asks us to build a marketplace or an NFT collection, the first problem we see is always the same: they start with the image, the design, the marketing. Few stop to think about what makes an NFT technically solid, transferable, persistent. A token that points to an image on a centralized server? That's not an NFT, it's a fragile bookmark. If the server goes down, the token is worth zero. At Meteora Web, we approach these projects starting from the blockchain — ERC-721 or ERC-1155? And where do we put the metadata? IPFS, nowhere else. In this guide we'll see exactly how to write NFT smart contracts that stand the test of time, market, and on-chain verification.

What differentiates ERC-721 from ERC-1155 in practice?

ERC-721: one token per identity

ERC-721 is the original standard for non-fungible tokens. Each token has a unique ID. Use it when every asset is distinct: digital art, collectibles, certificates. The smart contract assigns an ID and links it to an owner via a mapping. The ownerOf(tokenId) function returns the address. Simple, straightforward. But if you have 10,000 tokens, you must deploy 10,000 storage entries. Minting cost is fixed per token.

ERC-1155: multi-token that saves gas

ERC-1155 was designed to handle both fungible and non-fungible tokens in a single contract. Each ID can represent a token class with a quantity. Example: a game has 5 rare swords (ID 1) and 100 potions (ID 2). With ERC-1155 a single contract suffices. Moreover, batch transfers reduce gas: one transaction moves multiple tokens. We recommend it for high-volume projects or multiple economies (items, currencies, skins).

In our experience, if you need to sell 100 limited editions of a piece, ERC-721 works. If you have a complex ecosystem, ERC-1155 is the right choice.

How to implement an ERC-721 smart contract with OpenZeppelin?

Let's start with the code we use in real projects. Install Hardhat and OpenZeppelin dependencies, then write the contract.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";

contract MyNFT is ERC721URIStorage {
    uint256 private _nextTokenId;

    constructor() ERC721("MyNFT", "MNFT") {}

    function safeMint(address to, string memory uri) public returns (uint256) {
        uint256 tokenId = _nextTokenId++;
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
        return tokenId;
    }
}

The critical point: _setTokenURI stores the metadata URI. If you use a centralized server, the token is vulnerable. That's why we always point to IPFS.

How to handle metadata on IPFS securely?

IPFS (InterPlanetary File System) ensures persistence through content addressing. The URI is a hash of the content: if you modify the file, the hash changes. No one can alter the image without changing the URI. The problem? Files on IPFS are not guaranteed to persist unless someone pins them. Services like Pinata or Infura offer pinning, but we often advise clients to run their own IPFS node or use Filecoin for long-term storage.

The metadata format per the de facto OpenSea standard is a JSON:

{
  "name": "Artwork #1",
  "description": "First artwork of the collection",
  "image": "ipfs://Qm...hash.../image.png",
  "attributes": [
    {"trait_type": "Rarity", "value": "Legendary"}
  ]
}

The URI passed to safeMint will be ipfs://Qm...hash.../token1.json. NEVER use HTTP links. Losing control means losing the token's value.

How to use ERC-1155 for multiple collections and batch transfers?

The ERC-1155 standard includes balanceOf, safeTransferFrom, and safeBatchTransferFrom. Here's a basic example:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";

contract MyCollection is ERC1155 {
    uint256 public constant ART_1 = 0;
    uint256 public constant ART_2 = 1;

    constructor() ERC1155("ipfs://Qm.../{id}.json") {
        _mint(msg.sender, ART_1, 100, "");
        _mint(msg.sender, ART_2, 50, "");
    }
}

Note: the base URI contains {id} which is automatically replaced with the token ID. Metadata files on IPFS must be named accordingly (e.g., 0.json, 1.json). This simplifies managing hundreds of tokens.

What errors to avoid in off-chain metadata management?

The first mistake: centralized URLs. We've seen projects using Google Drive links or AWS servers. If the server goes down, your NFT is an empty string. The second mistake: mutable URIs. If you use a proxy contract or an updatable URI, you lose buyer trust. The third mistake: forgetting to pin metadata on IPFS after deployment. Pinning files before minting is essential.

At Meteora Web, we use a deployment script that automatically uploads metadata to IPFS and pins it via API. Then it generates the contract with the correct URI. No manual steps, no errors.

What to do next

1. Choose the standard: ERC-721 for simple collections, ERC-1155 for multi-asset projects.
2. Use IPFS for metadata: upload JSON and images, get hashes, pin them.
3. Implement with OpenZeppelin: use audited libraries for security and gas savings.
4. Test on testnet: Goerli or Sepolia with Hardhat. Verify that tokenId and URI match.
5. Lock the URI: do not include functions to change metadata after minting.

To dive deeper into the entire blockchain ecosystem for developers, read our pillar Blockchain and Web3 for Developers.