Du mintest, und jeder Token der Sammlung zeigt denselben grauen Platzhalter. Einen Tag später erscheint das Bild, und eine Rarity-Seite sagt dir, was du hältst. Dazwischen hat sich dein Token nicht bewegt, und es wurde ihm nichts hinzugefügt. Ein Reveal ist eine Zeichenkette, die sich am Vertrag ändert, plus eine Zuordnung, die feststand, bevor irgendjemand das Ergebnis sehen konnte.
Was ein Reveal ändert
Ein NFT ist eine ID, die ein Smart Contract einer Eigentümeradresse zuordnet. Name, Beschreibung und Bild sind nicht Teil dieses Eintrags.
Der ERC-721 Token-Standard legt sie hinter eine einzige Funktion. Zu einer Token-ID gibt tokenURI einen Uniform Resource Identifier zurück, und die Spezifikation ergänzt, dass dieser URI auf eine JSON-Datei zeigen darf, die dem ERC721 Metadata JSON Schema entspricht. Alles, was eine Galerie zeichnet, kommt vom anderen Ende dieses Zeigers.
Vor einem Reveal gibt diese Funktion für jede ID der Sammlung dasselbe Platzhalterdokument zurück. Danach löst jede ID auf ihr eigenes Dokument auf. Das ist das ganze Ereignis: die Zeichenkette, die der Vertrag zurückgibt, ändert sich, und die Dokumente am anderen Ende unterscheiden sich nun je ID, was vorher nicht der Fall war.
Sonst ändert sich an deinem Token nichts. Die ID ist dieselbe, der Eigentümer ist derselbe, die Transferhistorie ist dieselbe, und du unterschreibst nichts. Ein Reveal ist etwas, das die Sammlung tut, nicht etwas, das deinem Token widerfährt.
Warum eine Sammlung verkauft, bevor sie zeigt
Wären die Bilder während des Verkaufs sichtbar, könnten Käufer die Zuordnung von ID zu Bild lesen und nur die lohnenden IDs kaufen. Das Minten würde zum Wettlauf um bestimmte Nummern, und der Rest der Sammlung bliebe liegen.
Ein blinder Verkauf nimmt diese Möglichkeit, indem er die Information nimmt. Jeder Käufer nimmt dieselbe Unbekannte, und die Zuordnung wird erst veröffentlicht, wenn der Verkauf sich damit nicht mehr steuern lässt. Die Verzögerung ist also Absicht und keine technische Notwendigkeit, und eine Sammlung kann tagelang ohne Reveal stehen, ohne dass etwas kaputt ist.
Aus welchen zwei Entscheidungen ein Reveal besteht
Ein Reveal besteht aus zwei trennbaren Dingen, die im Gespräch verschmelzen. Das eine ist die Zuordnung: welcher Metadateneintrag zu welcher Token-ID gehört. Das andere ist die Umschaltung: ab wann der Vertrag Dokumente je ID statt des Platzhalters zurückgibt.
Die Umschaltung ist eine Transaktion, die jeder sieht. Die Zuordnung ist eine vorab festgelegte Regel, und dort sitzt die Fairnessfrage tatsächlich. Eine Sammlung kann die Umschaltung vor aller Augen ausführen und die Zuordnung trotzdem erst gewählt haben, nachdem sie gesehen hat, wer welche ID gekauft hat. Die sichtbare Hälfte des Prozesses ist also nicht die Hälfte, die geprüft werden muss.
Die Umschaltung ist eine Transaktion des Eigentümers
In einem Vertrag, der den Platzhalter über einen festen URI ausliefert, bedeutet Reveal, dass das Konto mit den Eigentümerrechten einen Setter aufruft und den Basis-URI ändert, aus dem der Vertrag seine Antworten baut. Eine Transaktion, und jede ID der Sammlung löst woanders hin auf.
Genau dieser Hebel entscheidet auch, ob Metadaten eingefroren sind. Solange ein Konto die Sammlung woandershin zeigen lassen kann, kann es das auch nach dem Reveal wieder tun. Enthüllt und eingefroren sind zwei verschiedene Aussagen, und die erste zieht die zweite nicht nach sich.
Die Zuordnung ist ein einziger Versatz
Bilder einzeln je ID zuzuweisen hieße eine Transaktion pro ID. Stattdessen genügt eine Zahl: ein Startindex, einmal gezogen und auf die ganze Sammlung angewendet.
Nimm eine Sammlung aus 10.000 Token und einen Metadatensatz, der in einer festen veröffentlichten Reihenfolge nummeriert ist. Der gezogene Startindex sei 3.142, dann lautet die Regel: Token-ID eins bekommt Metadateneintrag 3.143, und die Folge läuft am Listenende um, sodass ID 6.859 den Eintrag am Anfang der Liste bekommt.
Eine Zahl legt damit die gesamte Zuordnung fest. Niemand muss darauf vertrauen, dass zehntausend Zuweisungen einzeln ehrlich erfolgt sind, denn es gibt nur eine Ziehung zu prüfen, und sobald sie on chain steht, lässt sie sich nicht still wiederholen.
Sich auf die Bilder festlegen, bevor sie jemand sieht
Der Versatz mischt eine Liste. Er sagt nichts darüber, ob die Liste selbst vorab feststand, und eine Sammlung, die die Liste nach der Ziehung bearbeiten kann, kann die begehrten Bilder immer noch dorthin legen, wohin sie will.
Ein Provenance-Hash schließt diese Hälfte. Die Bilder werden in ihrer veröffentlichten Reihenfolge gehasht, die Hashes werden verbunden, das Ergebnis wird noch einmal gehasht und vor Verkaufsbeginn veröffentlicht. Nach dem Reveal kann jeder diese Schritte an den enthüllten Dateien wiederholen und vergleichen. Eine Übereinstimmung sagt, dass Satz und Reihenfolge die zugesagten sind; eine Abweichung sagt, dass etwas verschoben wurde.
Lies die beiden Aussagen getrennt. Der Provenance-Hash deckt ab, was in der Liste stand. Der Startindex deckt ab, wo die Liste geschnitten wurde. Eines ohne das andere zu veröffentlichen lässt die andere Hälfte unbewiesen, und das prüft man besser vor dem Mint als danach.
Woher der Versatz kommt
Die Ziehung muss unvorhersehbar sein, solange der Verkauf läuft, und überprüfbar, sobald er vorbei ist. Diese beiden Anforderungen machen die Quelle der Zahl zum interessanten Teil und nicht zum Detail.
Sie im Vertrag aus Blockdaten abzuleiten ist der billige Weg, und seine Schwäche ist, dass Blockdaten von einer Partei erzeugt werden, die die Transaktion sieht und eine gewisse Kontrolle über sie hat. Ein Dienst für verifizierbare Zufälligkeit geht den anderen Weg: der Wert kommt mit einem Beweis, dass er aus einem festgelegten Schlüssel und der Anfrage erzeugt wurde, sodass der Vertrag den Beweis prüfen kann, bevor er die Zahl annimmt.
Ein drittes Muster umgeht die Zeitfrage: es wird nichts zugewiesen, bis der letzte Token verkauft ist, sodass die Ziehung nicht auf eine Position abgestimmt werden kann, die der Verkäufer noch hält.
Wenn ein Reveal festzuhängen scheint
| Was du siehst | Was darunter passiert | Was es ändert |
|---|---|---|
| Alle Token zeigen einen Platzhalter | Der Vertrag gibt weiter den URI vor dem Reveal zurück | Die Umschaltung durch die Sammlung |
| Bei anderen enthüllt, bei dir nicht | Die Plattform liefert eine ältere gespeicherte Kopie | Ein Refresh auf dieser Plattform |
| Bild da, Merkmale fehlen | Das Dokument lud, die Attribute nicht | Ein weiterer Lesevorgang, wenn das Dokument vollständig ist |
| Merkmale weichen von einer Rarity-Seite ab | Zwei Werkzeuge bewerten dieselben Merkmale anders | Nichts, sie beantworten verschiedene Fragen |
Die ersten beiden Zeilen werden als dasselbe Problem gelesen, sind es aber nicht. Die erste ist eine Aussage über die Chain, und kein Neuladen bewegt sie. Die zweite ist eine Aussage über die gespeicherte Kopie einer Plattform, und diese Plattform um einen Metadaten-Refresh zu bitten ist genau die Anweisung, die das beseitigt.
Prüfe den Vertrag, bevor du entscheidest, welchen Fall du vor dir hast. tokenURI für deine ID in einem Block-Explorer zu lesen gibt die Antwort der Chain, und wenn diese Antwort noch der Platzhalter ist, hat der Reveal für niemanden stattgefunden.
Was ein Reveal nicht entscheidet
Seltenheit entsteht nicht beim Reveal. Sie stand fest, als der Metadatensatz gebaut und der Versatz gezogen wurde; der Reveal macht sie nur lesbar. Ein Token wird nicht knapp, weil eine Seite anfängt, ihn anzuzeigen.
Der Reveal klärt auch nicht, was selten bedeutet. Zu zählen, wie ungewöhnlich jedes Merkmal ist, und einen ganzen Token zu bewerten sind verschiedene Operationen, weshalb zwei Werkzeuge dieselbe enthüllte Sammlung anders sortieren können, und Merkmalsseltenheit ist eine Methode von mehreren und nicht die Antwort.
Und er sperrt nichts ab. Der Reveal richtet die Sammlung auf neue Dokumente. Ob diese Dokumente später geändert werden können, hängt davon ab, wo sie liegen und wer den Schlüssel hält, der den Zeiger setzt.
Fazit
Ein Reveal ist eine Zeigeränderung plus eine vorher festgelegte Zuordnung. Die Zeigeränderung ist öffentlich und leicht zu prüfen. Die Zusagen liegen auf der Seite der Zuordnung: ein vor dem Verkauf veröffentlichter Provenance-Hash legt fest, was in der Liste steht, und ein Startindex aus einer nicht steuerbaren Quelle legt fest, wo die Liste geschnitten wurde.
Suche vor einem Mint beides schriftlich und prüfe, ob das Konto, das die Umschaltung ausgeführt hat, sie erneut ausführen kann. Trenne nach einem Mint eine Sammlung, die noch nicht enthüllt hat, von einer Plattform, die noch nicht nachgezogen ist, denn nur bei einer der beiden kannst du selbst handeln. Um weiter die Grundlagen zu lernen, folge der Bitbase Academy.
Weiterführende Artikel
Weitere Bitbase-Artikel zu diesem Thema:
- Anteiliges Eigentum an einem NFT und wo das Risiko liegt
- NFT-Mint erfolgreich, aber das NFT taucht in der Wallet nicht auf
- Optionale NFT-Tantiemen erklärt
- Privater Schlüssel vs Seed Phrase: Was ist der Unterschied?
Haftungsausschluss: Dieser Artikel ist Bildungsinhalt der Bitbase Academy, nur zu Informationszwecken. Er ist keine Anlage-, Handels-, Steuer- oder Finanzberatung. Krypto-Assets sind volatil — schätze dein Risiko selbst ein. Stand September 2026; maßgeblich sind die aktuellen offiziellen Informationen.
Quellen
[1] Ethereum Improvement Proposals, ERC-721: Non-Fungible Token Standard eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-4906: EIP-721 Metadata Update Extension eips.ethereum.org
