# Der ERC-4804 Moment *Author: Bankless* *Published: Jan 8, 2026* *Source: https://www.bankless.com/de/read/the-erc-4804-moment* --- [![](https://bankless.ghost.io/content/images/2026/01/Group-681--1-.png)](https://www.bankless.com/sponsor/the-defi-report-1767388444?ref=read/erc-4804-shield-broken-nfts&email=true) Der ERC-4804 Moment Veröffentlicht am 8. Januar 2026 [ Im Browser anzeigen ](https://www.bankless.com/metaversal) --- [**Sponsor: The DeFi Report**](https://www.bankless.com/sponsor/the-defi-report-1767388444?ref=read/erc-4804-shield-broken-nfts&email=true) – Branchenführende Krypto-Forschung, der Finanzprofis vertrauen. [](https://bankless.ghost.io/ghost/#/editor/post/69580059dbc84d000120d568)[](https://www.bankless.com/portal/content/posts/view?id=8502) [](javascript:;) [Weitere Informationen](https://www.bankless.com/sponsor/the-defi-report-1767388444?ref=read/erc-4804-shield-broken-nfts&email=true) . . . EINFÜHRUNG ERC-4804: Ein neuer Schutz gegen defekte NFTs Bankless Autor: [ ](https://x.com/wmpeaster) [ William Peaster ](https://x.com/wmpeaster) [![](https://bankless.ghost.io/content/images/2026/01/image---2026-01-07T221351.865-1.png)](https://www.bankless.com/read/erc-4804-shield-broken-nfts)Was die Metadaten von NFTs angeht, werden uns die Geister der Vergangenheit weiterhin verfolgen. Natürlich gibt es eine Vielzahl von Möglichkeiten, die Medien von NFTs zu untermauern. Aus Gründen der Langlebigkeit habe ich mich immer zu On-Chain-Projekten hingezogen gefühlt, von denen es viele Varianten gibt, wie zum Beispiel: - **Semi-Onchain** – d. h. wenn *einige Metadaten *Onchain gespeichert sind, aber nicht alle - **Hashed Onchain** – d. h. wenn NFT-Verträge einen kryptografischen Hash enthalten, der dauerhaft auf Offchain-Daten verweist - **Hybrid-Onchain** – d. h. wenn ein Projekt eine separate Onchain-Sammlung einsetzt, um eine frühere Offchain-Sammlung zu archivieren - **Fully Onchain** – d. h. wenn alle Daten, die zur Anzeige eines NFT erforderlich sind, im Smart Contract der Sammlung gespeichert sind - **Inchain** – d. h. wenn NFT-Grafiken zum Zeitpunkt der Darstellung live durch vollständig Onchain-Code generiert und nicht als Dateien gespeichert werden Natürlich hat jede der oben genannten Methoden Vor- und Nachteile. Im Großen und Ganzen ist die Onchain-Speicherung jedoch kostspieliger als die Offchain-Speicherung und erfordert mehr Fachwissen über Smart Contracts. Daher ist die Offchain-Speicherung, bei der *nur NFT-Token *Onchain gespeichert werden, während ihre Metadaten auf externen Plattformen wie IPFS oder privaten Servern gehostet werden, der Status quo für die meisten NFT-Sammlungen, die in den letzten 5 Jahren entstanden sind. Das Problem dabei ist, dass IPFS-Pinning mit der Zeit oft nachlässt und viele Startups pleitegehen und ihre privaten Server schließen. In diesen Fällen bleiben nur die Token als wertlose Überbleibsel zurück, die ihre Bilder nicht mehr anzeigen können. Ich könnte viele Beispiele für verlorene NFTs aus den letzten Jahren anführen, aber Sie können sich selbst davon überzeugen. Mit der neuen [NFTimeless-App](https://app.nftimeless.com/) können Nicht-Gast-Benutzer beispielsweise einen Zustandsbericht für ihre NFT-Sammlungen abrufen. Darin wird angezeigt, welche NFTs Offchain sind und nun defekt sind. [![](https://bankless.ghost.io/content/images/2026/01/G9bVumKXsAAO5sc--1-.jpg)](https://x.com/G4SP4RD/status/2006031261974831578)*via [G4SP4RD](https://x.com/G4SP4RD/status/2006031261974831578)* Für *bereits defekte *Sammlungen kann nichts mehr getan werden. Glücklicherweise können Projekte mit Offchain-Speicher, die noch nicht verloren gegangen sind, eine neue Technik für rückwirkende Haltbarkeit einsetzen, die keine zweite Sammlung erfordert: [ERC-4804](https://eips.ethereum.org/EIPS/eip-4804). Dieser Standard ähnelt einem HTTP-ähnlichen System für Ethereum, da er eine neue Art von URI `web3://` einführt, mit der NFT-Metadaten direkt aus Smart Contracts abgerufen werden können. Die URI verweist nicht auf Offchain, sondern beschreibt einen Onchain-Lesevorgang. Mit anderen Worten: Wenn ein NFT-Marktplatz eine `web3://` -URI sieht, kann er den bereitgestellten ENS-Link in einen `eth_call` übersetzen, ihn gegen einen Smart Contract ausführen und die zurückgegebenen Daten als NFT-Metadaten behandeln. Stellen Sie sich beispielsweise einen NFT-Vertrag vor, dessen `tokenURI(123)` Folgendes zurückgibt `web3://testcollection.eth/tokenURI/123`... Folgendes passiert dabei im Hintergrund: - Ein Marktplatz löst `testcollection.eth` über ENS in eine Ethereum-Adresse auf - Er ruft `tokenURI(uint256)` für diesen Vertrag mit dem Argument `123` auf - Der Vertrag gibt JSON-Metadaten zurück (z. B. Name, Beschreibung, Bild, Attribute) - Schließlich rendert der Marktplatz die NFT unter Verwendung dieser Daten, genau wie bei IPFS, jedoch ohne Off-Chain-Abhängigkeiten All dies bedeutet, dass Metadaten vollständig on-chain generiert oder gespeichert werden können, entweder im selben NFT-Vertrag oder in einem separaten Metadaten-Resolver-Vertrag. Das Schema `web3://` macht Aufrufe hier überprüfbar und unabhängig von der Online-Verfügbarkeit eines Gateways. Dies ist eine leistungsstarke Funktion. Aber warum? Weil es eine einfache Möglichkeit für alte NFT-Sammlungen ist, ihre ursprünglichen Token-Verträge unverändert zu lassen, neue On-Chain-Metadatenverträge zu implementieren und ihre baseURIs so zu aktualisieren, dass sie auf den entsprechenden `web3://` ENS-Link verweisen. Im Wesentlichen handelt es sich nur um ein neues Zeigersystem, sodass keine NFT-Migrationen erforderlich sind. Dementsprechend würden Marktplätze nach Updates Metadaten direkt von Ethereum selbst abrufen, und dank der URI kann jeder die dafür erforderlichen Aufrufe für immer reproduzieren. Dieser Standard *ist auch *deshalb *wichtig *, weil selbst Projekte, die ihre Kunstwerke und Metadaten in der Blockchain *speichern*, [in der Vergangenheit gezwungen waren,](https://x.com/MichaelHirsch/status/1988314722710790148) `ipfs://` oder `https://` baseURIs zu veröffentlichen, da Apps und Wallets nichts anderes lesen konnten. Jetzt haben diese Projekte jedoch eine praktikable On-Chain-Alternative. Ein weiterer wichtiger Aspekt ist, dass OpenSea gerade [die Unterstützung für ERC-4804](https://docs.opensea.io/docs/metadata-standards#erc-4804-web3-uri-support) hinzugefügt hat. Dies ist eine große Bestätigung für den Standard und ein Hinweis darauf, dass er von hier aus ernsthaft an Fahrt gewinnen kann. Ich weiß, dass die Minting-Plattform [Carve](https://x.com/0xCarve/status/2009081155254178289) ebenfalls plant, die Unterstützung hinzuzufügen, und weitere Integrationen werden folgen. Wenn wir also auf die Möglichkeiten des neuen Jahres blicken, werde ich insbesondere die Einführung von ERC-4804 im Auge behalten. Es könnte sich still und leise zu einem der wichtigsten Tools für die Beständigkeit von NFTs im Ethereum-Ökosystem entwickeln, und das auch noch in kurzer Zeit. [Lesezeichen auf Bankless.com](https://www.bankless.com/read/erc-4804-shield-broken-nfts)