NFT-Metadaten erklärt: Was eingefroren heißt und wann ein Refresh nötig ist

2026-09-03

Drei Tage nach dem Reveal zeigt dein Token immer noch ein Platzhalterbild. Eine Kollektion, die du hältst, zeigt plötzlich andere Traits als vorige Woche. Nichts davon betrifft den Token selbst. Beides betrifft eine einzige Zeichenkette im Contract und das, was an ihrem anderen Ende sitzt; eingefroren und Refresh sind die zwei Wörter dafür, was mit dieser Zeichenkette geschehen kann und was nicht.

NFT-Metadaten erklärt: Was eingefroren heißt und wann ein Refresh nötig ist: die wichtigsten Punkte auf einen Blick

Was der Token hält und was nicht

Ein NFT ist eine Kennung, die ein Smart Contract zu einer Inhaberadresse festhält. Name, Beschreibung und Bild stehen nicht in diesem Eintrag.

Sie liegen hinter einer einzigen Funktion, die der Token-Standard ERC-721 vorgibt. Zu einer Token-Kennung liefert tokenURI einen Uniform Resource Identifier zurück, und die Spezifikation ergänzt, dass diese URI auf eine JSON-Datei zeigen darf, die dem ERC721 Metadata JSON Schema entspricht.

Dieses Schema hat drei Eigenschaften: name benennt das Asset, das der NFT darstellt, description beschreibt es, und image ist eine URI, die auf eine Ressource mit einem Bild-MIME-Typ zeigt. Das Bild ist damit ein zweiter Sprung: Der Contract zeigt auf ein Dokument, und das Dokument zeigt auf eine Datei.

Jenseits der Kennung und des Inhabers liest eine Anwendung alles, was sie dir zeigt, aus diesem Dokument und nicht aus der Chain. Der Teil, auf den alle schauen, ist genau der Teil, den die Chain nicht hält.

Wohin der Zeiger führt, entscheidet, was sich ändern kann

Eine Token-URI ist eine Zeichenkette, und sie kann sehr Verschiedenes sein. Sie kann eine Webadresse auf einem Server sein, den jemand betreibt. Sie kann eine IPFS-Adresse rund um eine Inhaltskennung sein. Sie kann das ganze Dokument in sich tragen, sodass gar nichts abgerufen wird.

Der Unterschied zählt wegen dem, was jede Variante werden kann. Eine Webadresse benennt einen Ort, keinen Inhalt: Wer den Server betreibt, kann morgen unter derselben Adresse andere Bytes ausliefern, und auf der Chain ändert sich dadurch nichts. Eine Inhaltskennung verhält sich anders. Die IPFS-Dokumentation hält fest, dass CIDs auf dem kryptografischen Hash des Inhalts beruhen und dass jeder Unterschied im Inhalt eine andere CID ergibt. Eine CID kann deshalb nicht auf bearbeiteten Inhalt auflösen, denn bearbeiteter Inhalt ist eine andere CID und braucht einen anderen Zeiger.

Ein eingebettetes Dokument geht einen Schritt weiter, weil kein Abruf mehr übrig ist, den man abfangen könnte. Es kostet Größe, denn jedes Byte davon liegt im Contract-Speicher.

Wohin die Token-URI zeigt	Kann das andere Ende später anderen Inhalt liefern	Was sich ändern muss, damit sich das Bild ändert
Eine Webadresse auf fremdem Server	Ja	Auf der Chain nichts
Eine IPFS-Inhaltskennung	Nein	Der Contract muss eine andere URI liefern
Das in der URI kodierte Dokument	Nein	Der Contract muss eine andere URI liefern

Was eingefrorene Metadaten wirklich bedeuten

Eingefroren ist eine Aussage über zwei Schlösser, und sie gilt nur, wenn beide zu sind. Das erste sitzt am anderen Ende: Der Inhalt hinter dem Zeiger lässt sich nicht gegen anderen Inhalt tauschen. Das zweite sitzt am Zeiger selbst: Der Contract lässt sich nicht dazu bringen, eine andere URI herauszugeben.

Eine Kollektion kann jede Datei auf IPFS legen, die Inhaltskennungen veröffentlichen und trotzdem eine Funktion behalten, mit der die deployende Adresse eine neue Base-URI setzt. Inhaltsadressierung schließt das erste Schloss und lässt das zweite offen. Eine Kollektion aus 10.000 Token kann über eine einzige Base-URI ausgeliefert werden, und dann ändert eine Transaktion des Eigentümers, worauf jede Kennung darin auflöst.

Eingefroren liest sich deshalb genauso wie die Eigentümer-Privilegien in jedem anderen Contract. Die Frage ist nicht, was der Contract heute tut, sondern was der Inhaber des Eigentümerschlüssels ihn noch tun lassen kann.

Warum du eine zwischengespeicherte Kopie siehst

Marktplätze und Wallets rufen nicht bei jedem Scrollen tokenURI auf und holen ein Dokument. Sie lesen es einmal, behalten ihre eigene Kopie des JSON, laden das Bild herunter und liefern dir diese Kopie, denn eine Galerie anders zu rendern hieße ein externer Abruf pro Kachel gegen Server, die die Seite nicht kontrolliert.

Es gibt also drei Kopien der Antwort, und sie können auseinandergehen: was der Contract jetzt zurückgibt, was das Dokument unter dieser URI jetzt sagt, und was der Indexer beim letzten Blick notiert hat. Eine falsche Anzeige ist eine Aussage über die dritte Kopie, kein Beleg dafür, dass die ersten beiden falsch sind.

ERC-4906 gibt es genau wegen dieser Lücke. Es trägt den Titel EIP-721 Metadata Update Extension und fügt ein MetadataUpdate-Ereignis hinzu, damit, in seinen eigenen Worten, Drittplattformen wie NFT-Marktplätze die Bilder und zugehörigen Attribute eines NFT rechtzeitig aktualisieren können; ein BatchMetadataUpdate-Ereignis deckt einen Bereich von Kennungen in einer Emission ab. Als Motivation nennt es, dass Contracts dafür ohnehin schon eigene Ereignisse ausgaben und dass eine eigene Lösung je Kollektion zusätzlichen Aufwand für die Plattformen bedeutete, die sie lesen.

Was ein Refresh wirklich tut

Ein Refresh ist eine Anweisung an den Indexer, nicht an die Chain. Er sagt der Plattform, das Notierte zu verwerfen und das ganze Lesen neu zu machen: tokenURI aufrufen, das Zurückgelieferte holen, es parsen und die im Feld image benannte Datei neu herunterladen. Nichts wird signiert, keine Gebühr fällt an, und der Contract bleibt unberührt.

Deshalb hilft ein Refresh nur in einer Lage, nämlich wenn die gespeicherte Kopie hinter der aktuellen Antwort zurückliegt. Liefert der Contract jetzt eine neue URI, oder hält das Dokument unter der alten URI jetzt andere Bytes, bringt der Refresh die Anzeige in Übereinstimmung. Trifft beides nicht zu, ersetzt er die gespeicherte Kopie durch eine identische.

Ein Refresh ist die manuelle Fassung dessen, was ERC-4906 automatisiert: Gibt eine Kollektion das Update-Ereignis aus, wiederholt ein darauf wartender Indexer das Lesen ungefragt.

Wann ein Refresh nicht hilft

Die nützliche Frage ist nicht, ob man auffrischt, sondern welchen Fehler man vor sich hat, denn unverbundene Fehler zeigen sich gleich: Das Bild ist falsch, oder das Bild fehlt.

Was du siehst	Was darunter geschieht	Ändert ein Refresh das
Platzhalterbild nach dem Reveal	Der Contract liefert weiter die URI von vor dem Reveal	Nicht, bevor der Contract die neue liefert
Kaputtes Bild, Dokument lädt noch	Die Bild-URI ist tot oder nicht erreichbar	Nein, die Reparatur liegt beim Host
Es lädt überhaupt nichts	Das Metadaten-Dokument ist nicht erreichbar	Nein
Traits weichen vom Dokument ab	Die gespeicherte Kopie ist veraltet	Ja
Bild richtig, Kollektionsseite falsch	Du siehst auf einen anderen Contract	Nein

Die Zeilen mit totem Zeiger sind genau die, die als Plattformfehler gelesen werden. Ist die Token-URI eine Webadresse, lässt sich der Server dahinter abschalten, und der Zeiger zeigt weiter auf nichts. Ist sie eine Inhaltskennung, kommt dasselbe Ergebnis über einen anderen Weg: Die IPFS-Dokumentation hält fest, dass IPFS zwar die Auffindbarkeit jedes Inhalts im Netz garantiert, aber nicht garantiert, dass ein Inhalt dauerhaft verfügbar bleibt, und dass Daten an einem oder mehreren IPFS-Knoten gepinnt werden können, damit sie bei der Garbage Collection nicht gelöscht werden. Eine CID, die kein Knoten hält, ist ein gültiger und dauerhafter Name für nichts.

Was du prüfst, bevor du einen Refresh anforderst

Drei Lesevorgänge trennen diese Fälle, und keiner davon braucht einen funktionierenden Marktplatz.

Lies zuerst den Contract. Öffne im Block-Explorer den Contract der Kollektion und rufe tokenURI mit deiner Token-Kennung auf. Die Zeichenkette, die zurückkommt, ist die Antwort aus der Chain und die einzige der drei Kopien, für die die Chain einsteht.

Öffne dann, was sie geliefert hat. Hol diese URI und lies das JSON. Stehen in name, description und image die erwarteten Werte, ist die Chain-Seite in Ordnung und das Problem liegt weiter unten. Lädt die URI nicht, zaubert kein Refresh ein Dokument herbei, das nicht da ist.

Folge dann dem Feld image, denn ein Dokument kann heil sein, während die von ihm benannte Datei verschwunden ist, und zwar auf einem anderen Host als dem, der die Metadaten ausliefert. Sind alle drei Lesevorgänge korrekt und der Marktplatz zeigt trotzdem etwas anderes, dann ist das der Fall für einen Refresh, und nur dann.

Fazit

Metadaten sind ein Dokument, auf das die Chain zeigt, keine Sache, die die Chain hält. Eingefroren heißt, dass beide Schlösser zu sind: Das andere Ende kann keinen anderen Inhalt liefern, und der Contract lässt sich nicht dazu bringen, woanders hinzuzeigen. Ein Schloss ohne das andere ist nicht eingefroren, und Inhaltsadressierung allein schließt nur das erste.

Ein Refresh berührt nichts davon. Er liest Zeiger und Dokument neu und überschreibt eine zwischengespeicherte Kopie, repariert also genau einen Fehler: eine Anzeige, die zurückgefallen ist. Lies tokenURI, öffne, was er liefert, folge dem Feld image. Diese drei Lesevorgänge trennen einen Indexer, der noch einmal schauen muss, von einem Zeiger, an dessen Ende nichts mehr ist. Um die Grundlagen weiter zu lernen, folge weiteren Beiträgen 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

- Der NFT Reveal Prozess: Was sich ändert und wann

- Optionale NFT-Tantiemen erklärt

- Kreuzungen gleitender Durchschnitte: Golden und Death Cross

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.