NachrichtenKryptoSmart Contracts für NFT-Marktplätze: Listings, Angebote, Auktionen und Tantiemen

Smart Contracts für NFT-Marktplätze: Listings, Angebote, Auktionen und Tantiemen

Autor: NFTENEX·

Wichtige Erkenntnisse

  • NFT-Verträge und Marktplatz-Verträge erfüllen getrennte Funktionen: Erstere definieren das Asset-Eigentum, letztere koordinieren Verkäufe, Gebührenrouting und Abwicklung.
  • ERC-721-Listings verkaufen in der Regel ein einzelnes, einzigartiges Token, während ERC-1155-Listings mehrere Kopien anbieten können, was Teilfüllungen und Mengenverfolgung bei der Abwicklung erfordert.
  • Escrow-Marktplätze sperren das NFT zum Zeitpunkt des Listings im Vertrag, während Lazy-Listings das Custody des Verkäufers durch Off-Chain-Signaturen wahren, aber On-Chain-Annullierungspfade erfordern.
  • EIP-2981 macht Tantiemen-Informationen lesbar, erzwingt jedoch keine universelle Zahlung, sodass tatsächliche Erstellererträge von der individuellen Marktplatz-Politik und der Abwicklungslogik abhängen.
  • Sicherheitstests sollten verifizieren, dass Verträge bei unsicheren Bedingungen kontrolliert fehlschlagen (fails closed), einschließlich Reentrancy, Replay-Angriffen, abgelaufenen Orders, Signaturen auf der falschen Chain und Teilfüllungen.
Smart Contracts für NFT-Marktplätze: Listings, Angebote, Auktionen und Tantiemen

Smart Contracts für NFT-Marktplätze steuern Listings, Angebote, Auktionen, Abwicklung, Stornierungen, Gebührenroutings, Tantiemen und administrative Kontrollen. Während die Standards ERC-721 oder ERC-1155 das Asset selbst beschreiben, führt die Einhaltung eines Token-Standards nicht automatisch zu einem sicheren Marktplatz.

Entwickler sollten Marktplatz-Verträge mit dem Gebühren- und Orderverhalten im OpenSea-Marktplatz-Review, den operativen Schichten im Leitfaden zur NFT-Marktplatz-Infrastruktur und den Auszahlungstriggern in NFT-Passive-Income-Modellen vergleichen, da Vertragsereignisse als Quelldaten für Abwicklung und Support-Workflows dienen.

NFT-Smart-Contracts erklärt

Ein NFT-Smart-Contract ist Code, der auf einer Blockchain bereitgestellt wird und Token erstellt sowie regelt, wie Eigentum erfasst und übertragen wird. Bei der Minting genannten Erstellung weist der Vertrag eine Token-ID einer Besitzeradresse zu. Beim Verkauf oder der Übertragung des Tokens aktualisiert der Vertrag den Eigentumsdatensatz erst nach Prüfung der Berechtigung des Senders und der geltenden Übertragungsregeln.

Der Vertrag erfasst üblicherweise den Besitzer des Tokens, das Angebot, Freigaben, die Übertragungshistorie und einen Metadaten-Verweis. Er speichert nicht zwingend das Kunstwerk selbst. Wie Hederas Erklärung zu NFT-Smart-Contracts feststellt, identifizieren die Token-ID und die Metadaten das Asset, während die Smart-Contract-Logik das Minting und die Eigentumswechsel übernimmt. Ein Smart Contract ist ausführbarer Computercode – er ist nicht automatisch eine rechtliche Vereinbarung zu Urheberrecht, Rückerstattungen oder kommerziellen Rechten.

NFT-Verträge vs. Marktplatz-Verträge

Der NFT-Vertrag und der Marktplatz-Vertrag erfüllen unterschiedliche Zwecke. Der NFT-Vertrag definiert das Asset, erstellt Token-IDs, erfasst Eigentum und setzt Freigaben und Übertragungen durch. Der Marktplatz-Vertrag koordiniert den Verkauf: Er validiert das Listing oder Angebot, zieht die Zahlung ein, überträgt das NFT, routet Gebühren und schließt oder storniert die Order.

Diese Trennung ist bedeutsam, da der Besitz eines gültigen NFT nicht bedeutet, dass es aktiv gelistet ist, und das Unterzeichnen einer Marktplatz-Order das Eigentum erst nach erfolgreicher Abwicklung ändert. Käufer sollten beide Adressen überprüfen: Der Collection-Vertrag identifiziert das NFT, während der Marktplatz-Vertrag oder Spender die Software kennzeichnet, die die Übertragungsberechtigung erhält. Für Teams, die Wallets, Support-Tools oder Indexer integrieren, bestimmt diese Unterscheidung zudem, welche Ereignisse als verbindliche Quelle für Artikelverfügbarkeit, Rückerstattungen und Erfüllung gelten.

Wie ERC-721 und ERC-1155 das Marktplatzdesign prägen

ERC-721 wird häufig verwendet, wenn jede Token-ID ein einzelnes, unabhängig eigenes Element repräsentiert. Er eignet sich für Unikate, einzigartige Spiel-Assets, Landparzellen und Sammlerstücke, deren Eigentum Token für Token geprüft wird. ERC-1155 kann mehrere Kopien derselben Token-ID darstellen, was für Spielverbrauchsgegenstände, Tickets, Editionen oder in Menge ausgegebene Artikel nützlich ist.

Der Token-Standard verändert, was eine Order enthalten muss. Ein ERC-721-Listing verkauft normalerweise eine Token-ID. Ein ERC-1155-Listing kann 20 Kopien anbieten, während ein Käufer nur drei erwirbt, wodurch der Marktplatz die verbleibende Menge aktualisieren muss, ohne die gesamte Order zu schließen. Eine Stornierung muss die verbleibende Menge ungültig machen, und das Abwicklungsereignis muss angeben, wie viele Einheiten den Besitzer gewechselt haben.

Auch die Freigabemechanismen unterscheiden sich. Eine token-spezifische ERC-721-Freigabe autorisiert ein einzelnes NFT, während eine Operator-Freigabe alle Token einer Collection abdecken kann. ERC-1155 verwendet häufig eine Operator-Freigabe für das gesamte Guthaben einer Wallet unter dem Vertrag. Ein Marktplatz kann aus Gründen der Bequemlichkeit weitreichendere Berechtigungen verlangen, jedoch sollte die Wallet-Aufforderung diesen Umfang sichtbar machen und der Nutzer sollte wissen, wie er ihn widerrufen kann.

Escrow- und Lazy-Listing-Designs

Ein Escrow-Marktplatz überträgt das NFT beim Einstellen des Listings in den Marktplatz-Vertrag. Dieser Ansatz macht die Verfügbarkeit leicht überprüfbar, jedoch zahlt der Verkäufer mehr Gas und verliert die Nutzungsmöglichkeit des Assets, solange es gelistet ist. Ein Lazy Listing behält das NFT in der Wallet des Verkäufers und zeichnet eine Off-Chain-Signatur auf, die Token, Preis, Chain, Ablauf, Nonce und Marktplatzadresse enthält. Dies senkt die Listing-Kosten und erhält das Custody, doch der Vertrag muss die Signatur validieren und der Verkäufer benötigt weiterhin einen On-Chain-Weg, um sie zu annullieren.

Für einen Spiele-Marktplatz beeinflusst diese Wahl mehr als nur die Gaskosten. Escrow kann verhindern, dass ein Gegenstand während des Listings ausgerüstet wird, während ein Lazy Listing das Spieler-Asset erhält, jedoch erfordert, dass Spiel und Marktplatz ein Listing verarbeiten, das nicht mehr erfüllbar ist, wenn sich das Eigentum ändert. Dieser operative Unterschied ist auch der Grund, warum Teams Randfälle wie Wallet-Übertragungen, Collection-Upgrades und Listing-Annullierungen vor dem Launch testen sollten, anstatt anzunehmen, dass das Listing-Modell diese automatisch abwickelt.

Listing- und Angebot-Lebenszyklus

Ein Festpreis-Listing sollte die Zustände Erstellen, Validieren, Kaufen, Abwickeln und Stornieren durchlaufen. Angebote erfordern Ablauf, Nonce, Chain-ID, Spender-Prüfungen und Stornierung. Jeder Zustand sollte Ereignisse ausgeben, die ein Indexer abstimmen kann.

Angebote benötigen zudem ein Zahlungsmodell, das der Vertrag zuverlässig ausführen kann. Ein Angebot in nativen Coins kann später in der Regel nicht ohne eine neue signierte Transaktion aus der Wallet des Käufers abgezogen werden, während ein genehmigter ERC-20-Token wie WETH oder USDC in Escrow gehalten oder bei Annahme durch den Verkäufer übertragen werden kann. Der Order-Datensatz sollte daher Währung, Betrag, Ablauf, Nonce, Käufer, Verkäufer, Token-ID und Stornierungsstatus umfassen – nicht nur einen angepriesenen Preis.

Die Auktionsabwicklung erfordert eine eigene Zustandsmaschine. Eine englische Auktion muss höhere Gebote, Rückerstattungen, die Endzeit und den finalen Abwicklungsaufrufer verarbeiten. Eine holländische Auktion muss den aktuellen Preis anhand der verstrichenen Zeit berechnen und veraltete Käufe ablehnen. Ein pull-basiertes Rückerstattungsguthaben ist sicherer, als sofort Gelder an jeden überbotenen Bieter zu senden, da ein fehlgeschlagener Rückerstattungs-Callback nicht die gesamte Auktion blockieren darf. Eine kurze Endzeitverlängerung hilft zudem, Last-Second-Bid-Sniping zu reduzieren.

Ein 0,5-ETH-NFT-Verkauf von der Signatur bis zur Abwicklung

Betrachten Sie ein ERC-721-NFT, das über eine signierte Order für 0,5 ETH gelistet wird. Der Verkäufer behält das NFT in der Wallet, genehmigt jedoch dem Marktplatz-Vertrag die Übertragung. Das signierte Listing identifiziert den Collection-Vertrag, die Token-ID, den Verkäufer, den Preis, den Ablauf, die Nonce, die Chain-ID und die Marktplatzadresse. Beim Erstellen dieser Signatur erfolgt kein Eigentumswechsel.

Wenn der Käufer den Kauf einreicht, prüft der Marktplatz-Vertrag, ob die Order nicht abgelaufen oder storniert wurde, die Signatur dem Verkäufer gehört, der Verkäufer noch Eigentümer des NFT ist und die Übertragungsfreigabe weiterhin gültig ist. Der Vertrag markiert dann die Order als erfüllt, verarbeitet die Zahlung, überträgt das NFT an den Käufer und gibt Ereignisse aus, die der Marktplatz zur Aktualisierung der Artikelseite verwenden kann.

Die oben beschriebene Gebührenverteilung ist illustrativ und keine Aussage über die Live-Gebühren eines bestimmten Marktplatzes.

Wenn die NFT-Übertragung fehlschlägt, darf die Zahlung nicht abgeschlossen bleiben, während das Eigentum unverändert bleibt. Wenn der Zahlungsempfänger kein ETH empfangen kann, hängt die sicherste Reaktion vom Vertragsdesign ab: Die Transaktion kann revertieren oder der Betrag einem abhebbaren Guthaben gutgeschrieben werden. Deshalb müssen Zahlungsrouting, Übertragungsreihenfolge, Zustandsaktualisierungen und Reentrancy-Schutz gemeinsam und nicht als isolierte Feature-Checklisten getestet werden.

Tantiemen und Gebührenrouting

Tantiemen-Informationen können EIP-2981 folgen, während Vertragsbibliotheken wie OpenZeppelin ERC-721 und OpenZeppelin ERC-1155 bei der Implementierung standardmäßigen Asset-Verhaltens helfen. Die Durchsetzung durch den Marktplatz erfordert jedoch weiterhin eine bewusste Produktpolitik.

EIP-2981 macht Tantiemen-Informationen lesbar, aber nicht universell durchsetzbar. Ein Marktplatz kann die Erstelleradresse und den Tantiemen-Betrag abfragen, aber eine andere Plattform kann eine andere Politik wählen oder das Ergebnis vollständig ignorieren. Wenn Erstellererträge unerlässlich sind, sollten Entwickler den tatsächlichen Übertragungspfad, den gewählten Marktplatz, das Aggregator-Verhalten und die Durchsetzungslogik der Collection testen, anstatt ein Tantiemen-Feld als garantierte Zahlung zu behandeln.

Sicherheitstests

Kritische Tests umfassen Reentrancy, Replay-Angriffe, abgelaufene Orders, Signaturen auf der falschen Chain, Kompromittierung von Admin-Keys, Pausenverhalten und Teilfüllungen. Ziel ist es nicht, eine lange Audit-Checkliste zu erstellen, sondern zu beweisen, dass der Marktplatz bei unsicheren Orders kontrolliert fehlschlägt (fails closed).

Die wertvollsten Tests sollten Fehler modellieren, die ein Käufer oder Verkäufer tatsächlich erleben könnte. Ein Kauf sollte einen geänderten Preis ablehnen statt einen Bait-and-Switch auszuführen. Eine signierte Order sollte an die Chain-ID und die Marktplatzadresse gebunden sein. Eine stornierte oder verbrauchte Nonce sollte nicht erneut ausgeführt werden. Bei Abwicklungscode sollte der Order-Zustand vor externen Aufrufen aktualisiert und ein Reentrancy-Guard um Zahlungs- und Übertragungspfade angewendet werden.

Ein Polygon-Nutzer, der Rarible bewertete, berichtete, dass das Netzwerkerlebnis keine Unterstützung für benutzerdefinierte Verträge und kein Metadata-Freezing in einem netzwerkspezifischen Vertrags-Review bot, erfasst am 11. August 2026. Dies ist kein Beweis dafür, dass ein Marktplatz-Vertrag unsicher ist, und die Ergebnisse können vom Netzwerk und der Produktversion abhängen. Dennoch hebt es eine nützliche Implementierungsgrenze hervor: Testen Sie Vertragsabdeckung, Metadaten-Unveränderlichkeit und Upgrade-Verhalten auf der exakten Chain, die für den Launch ausgewählt wurde.

Fazit

Ein Marktplatz-Vertrag sollte anhand seines Order-Lebenszyklus und seines Fehlerverhaltens bewertet werden. Ein sicherer Vertragspfad behandelt Erstellung, Ablauf, Stornierung, Abwicklung, Tantiemen, Indexierung und Pausenverhalten, ohne sich auf Annahmen zu verlassen. Der nächste Engineering-Schritt ist der Test des Order-Lebenszyklus.

Häufig gestellte Fragen

Welche Informationen werden in einem NFT-Smart-Contract gespeichert?

Der Vertrag erfasst üblicherweise Token-IDs, Eigentum, Guthaben, Freigaben, Übertragungsregeln, Angebot und einen Metadaten-URI. Das Bild oder Video wird oft separat gespeichert und über Metadaten referenziert.

Verwaltet der NFT-Vertrag auch Marktplatz-Listings?

Nicht zwingend. Der NFT-Vertrag verwaltet das Token, während ein separater Marktplatz-Vertrag üblicherweise Listings, Angebote, Auktionen, Zahlungen, Gebühren und die Abwicklung steuert.

Kann ein Marktplatz ein NFT ohne Berechtigung übertragen?

Er benötigt eine Berechtigung durch Eigentum, eine token-spezifische Freigabe oder eine Operator-Freigabe, die vom NFT-Vertrag anerkannt wird. Käufer und Verkäufer sollten den genehmigten Spender vor dem Signieren prüfen.

Garantiert ein NFT-Tantiemen-Feld eine Zahlung?

Nein. Ein Tantiemen-Standard kann den Empfänger und den Betrag kommunizieren, aber die tatsächliche Zahlung hängt von der Marktplatz-Politik und dem Abwicklungspfad ab.

Haftungsausschluss: Dieser Artikel dient ausschließlich Forschungs- und redaktionellen Vergleichszwecken. Er stellt keine Finanz-, Investment-, Rechts- oder Steuerberatung dar. NFT-Tools, Marktplätze, Gebühren, Chain-Unterstützung und Live-Verfügbarkeit können sich schnell ändern. Verifizieren Sie daher die aktuellen Bedingungen auf der offiziellen Plattform, bevor Sie eine Entscheidung treffen, die Gelder, Assets oder Private Keys betrifft.