IPFS (InterPlanetary File System)-Metadaten, Mint und Multiple Mint (Ipfs Metadata Mint Und Multiple Mint)

Die Chain hält nicht das Bild — sie hält die CID

Im Confident-Gorillas-Mint-Flow landen Art und Traits zuerst auf IPFS: Infura-Add für JSON/File-Upload, Pinata für Pin. Dann laufen mint oder multipleMint; value ist 0.1 ETH × Menge. Der Landing-Mengenwähler (2–5) mappt direkt auf 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

Dieser Teil verdrahtet die Metadata-Pipeline mit der Mint-Tx; der nächste öffnet Placeholder-URI und Owner-Reveal.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 IPFS CID
Inhaltsadressierte ID; tokenURI verweist meist auf diesen Hash.

📦 Pinning
CID am Leben halten über einen Pin-Service wie Pinata.

📦 multipleMint
Mehrere NFTs in einer Tx minten; value und Gas skalieren mit der Anzahl.

📦 Mint Price
Bei Confident Gorillas: 1e17 Wei (0.1 ETH) × Mint-Anzahl.

Infura-Upload und Pinata-Pin sind getrennte Schritte. Upload ohne Pin riskiert später Gateway-404.

Metadata-Form

nftContractUtils baut name, description, image (IPFS-Hash), external_url und attributes (artist, background, body, eye, mouth). uploadJSON liefert den Hash als Mint-URI.

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

mint vs multipleMint

Einzel: mint(tokenId, ipfsMetadataHash) + 0.1 ETH. Multi: multipleMint(ipfsMetadataHash, num) + 0.1 ETH × num. HomePage-Select 2–5; Minter ruft multiplemintNFT. UI zeigt Remaining gegen Cap 750 via totalSupply.

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

ADR: zuerst IPFS, dann Chain

Entscheidung: Medien nicht on-chain einbetten; IPFS-Upload, URI on-chain. Vorteil: günstigerer Reveal und kleines Calldata. Risiko: Pinning/Gateway als Single Point — Pin plus öffentliche Gateway-Backups.

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

Failure-Szenarien

Hartes gasPrice: 0 lässt Mainnet-Txs stuck/underpriced. Falsches Netz (Rinkeby/Infura-Fallback) signiert die falsche Welt. ABI-Mismatch: Frontend-ABI vs. deployed multipleMint. Stub-Adresse: All-Stars zeigte vier Contracts auf eine Adresse.

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

Die am häufigsten verwechselten Zuordnungen

❌ Bild als Base64 in den Contract
✓ Bild auf IPFS; on-chain nur CID/URI

❌ Upload reicht; Pin optional
✓ Upload + Pin zusammen; sonst Unpin-Risiko

❌ gasPrice: 0 heißt 'automatisch'
✓ gasPrice: 0 heißt auf Mainnet meist underpriced

Checkliste zur Prüfung des eigenen Systems

1. Ist die CID vor dem Mint bei Pinata (o. ä.) gepinnt?
2. Ist 0.1 ETH × num in Wei verifiziert?
3. Ist totalSupply + num ≤ 750 in UI und Contract geprüft?
4. Sind gasPrice / maxFeePerGas für Mainnet dynamisch?
5. Teilen deployed ABI und Frontend-ABI einen Commit?

Was aus diesem Teil bleiben sollte

1. Mint-Pipeline: Traits → IPFS → Pin → Contract-Call → Value.
2. multipleMint ist das On-Chain-Gegenstück zum Mengenwähler.
3. gasPrice: 0, Stub-Adressen und ABI-Skew sind das klassische Mainnet-Trio.

Metadaten on-chain einbetten macht Mint teuer; die CID ungepinnt lassen verliert die Collection.