IPFS (InterPlanetary File System) Metadata, Mint, and Multiple Mint (Ipfs Metadata Mint And Multiple Mint)

The chain does not hold the art — it holds the CID

In the Confident Gorillas mint flow, art and traits hit IPFS first: Infura add for JSON/file upload, Pinata for pin. Then the contract mint or multipleMint runs; value is 0.1 ETH × quantity. The landing quantity selector (2–5) maps straight to multipleMint(num).

traits + image
    ↓
uploadJSON / uploadFile (Infura IPFS)
    ↓
pinHash (Pinata)
    ↓
CID / metadata hash
    ↓
mint(tokenId, uri)  |  multipleMint(uri, num)
    ↓
value = 0.1 ETH × num   supply ≤ 750

This part wires the metadata pipeline to the mint tx; the next part opens placeholder URI and owner reveal.

Concepts, defined where they first appear

📦 IPFS CID
Content-addressed id; tokenURI usually references this hash.

📦 Pinning
Keeping a CID alive via a pin service such as Pinata.

📦 multipleMint
Mint several NFTs in one tx; value and gas scale with count.

📦 Mint Price
On Confident Gorillas: 1e17 wei (0.1 ETH) × mint count.

Infura upload and Pinata pin are separate steps. Upload without pin risks eventual gateway 404s.

Metadata shape

nftContractUtils builds name, description, image (IPFS hash), external_url, and attributes (artist, background, body, eye, mouth). uploadJSON returns a hash used as the mint URI.

metadata JSON
  name / description / image
  attributes[] → traits
       ↓
  uploadJSON → ipfsMetadataHash

mint vs multipleMint

Single: mint(tokenId, ipfsMetadataHash) + 0.1 ETH. Multi: multipleMint(ipfsMetadataHash, num) + 0.1 ETH × num. HomePage select offers 2–5; Minter calls multiplemintNFT. UI shows remaining against a 750 cap via totalSupply.

UI qty (2..5)
   ↓
multipleMint(uri, num)
   value = 1e17 * num
   gasLimit ≈ 300000 (app default)

ADR: IPFS first, chain second

Decision: do not embed media on-chain; upload to IPFS, store URI on-chain. Benefit: cheaper reveal path and small calldata. Risk: pinning/gateway become single points of failure — pin plus public gateway backups.

ADR-02 Content-addressed mint
  Off-chain: Infura add + Pinata pin
  On-chain: store URI hash only
  Read path: tokenURI → retrieveJSON

Failure scenarios

Hardcoded gasPrice: 0 leaves mainnet txs stuck/underpriced. Wrong network (Rinkeby/Infura fallback) signs against the wrong world. ABI mismatch: frontend ABI vs deployed multipleMint signature fails encode. Stub address: All-Stars once pointed four contracts at one address.

Fail matrix
  gasPrice=0     → stuck / underpriced
  wrong chainId  → silent wrong net
  ABI skew       → encode / revert
  stub address   → call nowhere useful

The mappings that get confused most often

❌ Stuff the image as base64 in the contract
✓ Put the image on IPFS; keep only CID/URI on-chain

❌ Upload is enough; pin is optional
✓ Upload + pin together; otherwise content can go unpinned

❌ gasPrice: 0 means 'automatic'
✓ gasPrice: 0 usually means underpriced on mainnet

A checklist for auditing your own system

1. Is the CID pinned on Pinata (or equivalent) before mint?
2. Is 0.1 ETH × num verified in wei?
3. Is totalSupply + num ≤ 750 checked in UI and contract?
4. Are gasPrice / maxFeePerGas dynamic for mainnet?
5. Do deployed ABI and frontend ABI share one commit?

What to take away from this part

1. Mint pipeline: traits → IPFS → pin → contract call → value.
2. multipleMint is the on-chain twin of the landing quantity selector.
3. gasPrice: 0, stub addresses, and ABI skew are the classic mainnet trio.

Embed metadata on-chain and you make mint expensive; leave the CID unpinned and you lose the collection.