Placeholder URI ve Owner Reveal Hattı (Placeholder Uri Ve Owner Reveal Hattı)

Mint rastgele sanat vermez; reveal verir

Confident Gorillas 1.4'te mint çoğu zaman nihai görseli hemen göstermez. Placeholder / geçici URI mint anında yazılır; gerçek CID'ler uridata tablosunda tokenId → hash/link olarak bekler. Reveal container owner kontrolünden sonra reveal(tokenId, uriHash) gönderir — sanat 'cüzdanında belirir' vaadi bu hattır.

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

Bu bölüm reveal'i bir ürün ve güvenlik sınırı olarak sabitler; sonraki bölüm cüzdan bağlantısını mainnet için sertleştirir.

Kavramlar ilk geçtiği yerde

📦 Placeholder Metadata
Mint anında yazılan geçici URI; nihai traits/görsel henüz bağlı değildir.

📦 uridata
tokenId → { hash, link, index } haritası; reveal için hazır CID tablosu.

📦 reveal(tokenId, uri)
Owner'ın tokenURI'yi gerçek hash ile güncellediği sözleşme çağrısı.

📦 Owner Gate
revealToken içinde ownerOf === connected address kontrolü.

Viewer'da Reveal butonu disabled olabilir; operasyonel reveal bazen owner paneli veya script ile tetiklenir. Kapı yine owner'dır.

Neden placeholder?

Fairness ve operasyon: tüm supply basılmadan önce metadata sızıntısını azaltmak, art generation'ı mint ritminden ayırmak. Kullanıcı mint eder; sanat sonradan 'reveal' ile gelir. Landing FAQ bunu MetaMask'ta görünme olarak anlatır.

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

Reveal boru hattı

Reveal.ts uridata.uri[tokenId] okur, hash'i alır, revealToken(tokenId, hash) çağırır. nftContractUtils ownerOf doğrular; eşleşirse contract.methods.reveal(...).send({ from }). Sonra tokenURI yeni hash'i döner; retrieveJSON image CID'sini çözer.

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

ADR: off-chain tablo + on-chain owner reveal

Karar: nihai CID listesi client/bundle'da (uridata) tutulur; güncelleme yetkisi owner-gated reveal fonksiyonunda kalır. Alternatif (commit-reveal on-chain, VRF) daha pahalıdır. Trade-off: uridata bundle'ı sızdırılabilir — reveal zamanlaması ve erişim kontrolü ürün riskidir.

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

Başarısızlık senaryoları

Yanlış tokenId → yanlış sanat. Hash/link uyumsuzluğu → gateway 404. Owner olmayan cüzdan → sessiz no-op (fonksiyon null döner). ABI'de reveal yoksa encode patlar. Placeholder hiç güncellenmezse koleksiyon 'boş kutu' olarak kalır.

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

Bu bölümde en çok karışan eşleştirmeler

❌ Reveal = sadece UI'da blur kaldırmak
✓ Reveal = on-chain tokenURI güncellemesi; UI yalnızca sonucu gösterir

❌ Herkes herhangi bir token'ı reveal edebilmeli
✓ Yalnızca owner (veya tasarlanmış minter/owner rolü) reveal eder

❌ uridata gizli kalır çünkü bundle'da
✓ Frontend bundle okunabilir; zamanlama ve erişim asıl kontroldür

Kendi sisteminizi denetleme listesi

1. Her tokenId için uridata hash'i pinli ve retrieve edilebilir mi?
2. reveal öncesi ownerOf kontrolü hem client hem contract'ta mı?
3. Placeholder URI ile final URI net ayrılmış mı?
4. Reveal butonu non-owner'da güvenli şekilde disabled/denied mi?
5. 750 girdilik tabloda index kayması var mı?

Bu bölümden aklında kalması gerekenler

1. Placeholder mint ile reveal, fairness ve ops ayrımı sağlar.
2. Owner gate olmadan reveal, koleksiyon bütünlüğünü bozar.
3. uridata bir ürün kararıdır; gizlilik varsaymayın, zamanlamayı tasarlayın.

Sanatı mint anında vermek kolaydır; adil ve geri alınamaz vermek reveal disiplinidir.