Placeholder-URI und Owner-Reveal-Pipeline (Placeholder Uri Und Owner Reveal Pipeline)

Mint gibt nicht die finale Kunst — Reveal tut es

In Confident Gorillas 1.4 zeigt Mint oft nicht sofort die finale Kunst. Eine Placeholder-/Interim-URI wird beim Mint geschrieben; echte CIDs warten in uridata als tokenId → hash/link. Der Reveal-Container sendet nach Owner-Check reveal(tokenId, uriHash) — das ist das Versprechen 'erscheint in deiner Wallet'.

mint → placeholder / interim tokenURI
              │
         uridata[tokenId] = { hash, link }
              │
   ownerOf(tokenId) === connected wallet?
         yes │ no → deny
              ↓
   reveal(tokenId, uriHash)
              ↓
   tokenURI updated → retrieveJSON / image

Dieser Teil fixiert Reveal als Produkt- und Sicherheitsgrenze; der nächste härtet Wallet-Connect für Mainnet.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 Placeholder Metadata
Interim-URI beim Mint; finale Traits/Kunst noch nicht gebunden.

📦 uridata
tokenId → { hash, link, index }-Map; CID-Tabelle für Reveal.

📦 reveal(tokenId, uri)
Contract-Call, mit dem der Owner tokenURI auf den echten Hash setzt.

📦 Owner Gate
ownerOf === connected address in revealToken.

Viewer-Reveal kann disabled sein; operatives Reveal läuft oft über Owner-Panel oder Script. Die Gate bleibt Ownership.

Warum Placeholder?

Fairness und Ops: Metadata-Leaks vor vollem Supply reduzieren, Art-Generation vom Mint-Rhythmus trennen. Nutzer minten; Kunst kommt später per Reveal. Landing-FAQ rahmt es als 'in MetaMask sichtbar'.

Mint window
  → same placeholder look
Reveal window
  → unique CID per tokenId

Reveal-Pipeline

Reveal.ts liest uridata.uri[tokenId], nimmt den Hash, ruft revealToken(tokenId, hash). nftContractUtils prüft ownerOf; bei Match contract.methods.reveal(...).send({ from }). Danach liefert tokenURI den neuen Hash; retrieveJSON löst die Image-CID.

Reveal.ts
  uridata[tokenId].hash
       ↓
revealToken → owner check
       ↓
reveal(tokenId, hash).send

ADR: Off-Chain-Tabelle + On-Chain-Owner-Reveal

Entscheidung: finale CID-Liste lebt im Client/Bundle (uridata); Mutationsautorität bleibt owner-gated reveal. Alternativen (Commit-Reveal on-chain, VRF) sind teurer. Trade-off: uridata kann aus dem Bundle leaken — Timing und Zugriff sind Produktrisiken.

ADR-03 Placeholder + owner reveal
  Store: uridata off-chain map
  Auth: ownerOf gate
  Mutate: reveal(tokenId, uriHash)
  Reject: non-owner / wrong id

Failure-Szenarien

Falsche tokenId → falsche Kunst. Hash/Link-Mismatch → Gateway-404. Non-Owner → stilles No-Op. Reveal fehlt in ABI → Encode-Fail. Placeholder nie aktualisiert → Collection aus leeren Boxen.

Fail matrix
  wrong tokenId     → wrong art
  hash ≠ pinned CID → 404
  non-owner         → no-op / deny
  missing reveal ABI→ encode fail

Die am häufigsten verwechselten Zuordnungen

❌ Reveal = nur UI-Blur entfernen
✓ Reveal = on-chain tokenURI-Update; UI zeigt nur das Ergebnis

❌ Jeder darf jedes Token revealen
✓ Nur Owner (oder definierte Minter/Owner-Rolle) reveal't

❌ uridata bleibt geheim, weil Bundle
✓ Frontend-Bundles sind lesbar; Timing und Zugriff sind die echte Kontrolle

Checkliste zur Prüfung des eigenen Systems

1. Ist jeder tokenId-Hash in uridata gepinnt und abrufbar?
2. Wird ownerOf vor Reveal in Client und Contract geprüft?
3. Sind Placeholder- und Final-URI klar getrennt?
4. Ist Reveal für Non-Owner sicher disabled/denied?
5. Gibt es Index-Drift in der 750er-Tabelle?

Was aus diesem Teil bleiben sollte

1. Placeholder-Mint plus Reveal trennt Fairness von Ops-Kadenz.
2. Ohne Owner-Gate zerstört Reveal die Collection-Integrität.
3. uridata ist eine Produktentscheidung; keine Geheimhaltung annehmen — Timing designen.

Kunst beim Mint zu geben ist leicht; fair und irreversibel zu geben ist Reveal-Disziplin.