ERC-2981: Wie NFT-Royalties definiert und implementiert werden

NFT-Royalties entstanden als sozialer Vertrag zwischen Schöpfern und Marktplätzen. Da der Handel ausgereifter wurde und Gebührenmodelle sich weiterentwickelten, benötigte die Branche eine einheitliche On-Chain-Methode zur Beschreibung von Royalty-Informationen, die jeder Marktplatz lesen konnte. Genau das bietet ERC-2981: eine minimale, interoperable Schnittstelle zur Abfrage, wie viel Royalty für einen bestimmten NFT-Verkauf geschuldet wird und an wen. Dieser Artikel erklärt, was ERC-2981 ist, wie es im Hintergrund funktioniert, welche Überlegungen für die Implementierung wichtig sind und welche aktuelle Landschaft bezüglich Marktplatz-Durchsetzung und Monetarisierung von Schöpfern existiert.

Was ERC-2981 tatsächlich standardisiert

ERC-2981 ist ein Ethereum-Standard, der eine einzige Funktion für Non-Fungible Tokens definiert:

• royaltyInfo(tokenId, salePrice) → (receiver, royaltyAmount)

Marktplätze, die Royalties berücksichtigen, rufen zur Verkaufszeit royaltyInfo auf, um die Auszahlung zu berechnen. Der Standard erzwingt keine Zahlung – er beschreibt nur die Schnittstelle. Die Durchsetzung ist eine Frage der Marktplatzrichtlinien.

Wichtige Designentscheidungen:

• Prozentbasiert: Royalties werden als Funktion des Verkaufspreises berechnet, typischerweise unter Verwendung eines Bruchteils wie Basispunkten (z. B. 500 = 5 %).
• Flexibilität des Empfängers: Der Royalty-Empfänger kann die Adresse eines Schöpfers, eine Multisig-Adresse, einen Split-Vertrag oder eine aktualisierbare Auszahlungsadresse sein.
• Funktioniert mit ERC-721 und ERC-1155: ERC-2981 ist mit gängigen NFT-Standards kompatibel und nutzt ERC-165 zur Schnittstellenerkennung.

Für eine produktionsreife Implementierung bauen viele Teams auf OpenZeppelins ERC2981.

Warum es jetzt wichtig ist

Ab 2023 stellten mehrere führende Marktplätze auf die optionale Durchsetzung von Royalties um. Die bemerkenswerteste Änderung war OpenSeas Entscheidung, seinen Operator Filter einzustellen, der es Schöpfern zuvor ermöglicht hatte, den Handel auf Royalty-durchsetzende Plattformen zu beschränken; siehe OpenSeas Ankündigung. Infolgedessen wurden On-Chain-Standards wie ERC-2981 zur Standardmethode, um Royalty-Daten plattformübergreifend anzuzeigen, auch wenn die Durchsetzung variiert.

Seitdem hat das Ökosystem reagiert mit:

• Registry-Infrastruktur, damit Marktplätze Royalty-Logik einheitlich auflösen können, z. B. Royalty Registry und die zugehörige Spezifikation.
• Programmierbare Standards für On-Chain-Durchsetzung oder Einschränkungen, insbesondere ERC-721C (Creator Token Standards).
• Alternative Verdienstmodelle wie protokollweite Belohnungen und Anreize für Schöpfer, z. B. Zoraz Creator Rewards.

In den Jahren 2024–2025 bleibt die Akzeptanz von ERC-2981 auf L1- und L2-Netzwerken weit verbreitet, und Marktplätze, die sich für die Berücksichtigung von Royalties entscheiden, werden diese Schnittstelle in der Regel abfragen, wenn sie Trades abwickeln.

Wie die Schnittstelle funktioniert (ohne Überraschungen)

Zum Zeitpunkt des Verkaufs führt ein konformer Marktplatz Folgendes aus:

1. Prüfen, ob das Token IERC2981 über ERC-165 unterstützt (Interface-ID 0x2a55205a).
2. Aufrufen von royaltyInfo(tokenId, salePrice), um zu erhalten:
   • receiver: Adresse, die die Auszahlung erhält.
   • royaltyAmount: Betrag, der basierend auf salePrice berechnet wird.

Schöpfer oder Sammlungseigentümer legen typischerweise eine „Standard-Royalty“ und optional eine „pro-Token-Royalty“ fest. Viele Implementierungen verwenden einen Nenner von 10.000 für Basispunkte. Die Buchhaltung des Marktplatzes teilt dann den Verkaufserlös zwischen Verkäufer, Protokollgebühren und dem Royalty-Empfänger auf.

Tipps zur Implementierung:

• Vermeiden Sie Reverts in royaltyInfo – Marktplätze können Auszahlungen überspringen, wenn Ihr Aufruf fehlschlägt.
• Halten Sie den Royalty-Empfänger aktualisierbar (z. B. über Ownable oder Admin-Kontrollen), um Schlüssel zu rotieren oder zu einem Split-Vertrag zu migrieren.
• Begrenzen Sie Royalties auf ein vernünftiges Maximum (viele Projekte bleiben ≤10 %), um die Liquidität des Sekundärmarktes zu fördern.

Minimales Solidity-Beispiel

Unten sehen Sie ein vereinfachtes Muster unter Verwendung von OpenZeppelin. Es zeigt, wie eine Standard-Royalty festgelegt und die Unterstützung für ERC-165 überschrieben wird. In der Produktion sollten Sie Zugriffskontrollen, Initialisierungsschutz und robuste Minting-Logik hinzufügen.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC721/ERC721.[sol](https://onekey.so/blog/de/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/token/common/ERC2981.[sol](https://onekey.so/blog/de/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/access/Ownable.[sol](https://onekey.so/blog/de/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

[contract](https://onekey.so/blog/de/ecosystem/what-is-a-smart-contract/) MyNFT is ERC721, ERC2981, Ownable {
    uint256 private _nextTokenId;

    constructor([address](https://onekey.so/blog/de/ecosystem/what-is-a-crypto-wallet-address/) defaultReceiver, uint96 defaultBps)
        ERC721("MyNFT", "MYN")
    {
        // Standard-Royalty festlegen (z. B. 500 = 5%)
        _setDefaultRoyalty(defaultReceiver, defaultBps);
    }

    function mint([address](https://onekey.so/blog/de/ecosystem/what-is-a-crypto-wallet-address/) to) external onlyOwner {
        _safeMint(to, _nextTokenId);
        _nextTokenId++;
    }

    // Optional: [Pro](https://onekey.so/products/onekey-pro-hardware-wallet/)-Token-Royalty für spezielle Artikel festlegen
    function setTokenRoyalty(uint256 tokenId, [address](https://onekey.so/blog/de/ecosystem/what-is-a-crypto-wallet-address/) receiver, uint96 bps)
        external
        onlyOwner
    {
        _setTokenRoyalty(tokenId, receiver, bps);
    }

    // Erforderlich: ERC-165 supportsInterface
    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721, ERC2981)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

Für tiefere Dokumentationen siehe OpenZeppelins ERC2981-Anleitung.

Behandlung von Splits, Upgrades und Sonderfällen

Reale Royalty-Flüsse haben selten einen einzelnen Empfänger. Berücksichtigen Sie:

• Split-Verträge: Leiten Sie Einnahmen in festen Proportionen an mehrere Parteien weiter, indem Sie gut getestete Infrastrukturen wie 0xSplits verwenden.
• Registry-Abfragen: Einige Marktplätze konsultieren eine Registry für die neuesten Royalty-Daten (Royalty Registry).
• Aktualisierbare Empfänger: Behalten Sie die Möglichkeit, die Empfängeradresse bei Schlüsselrotationen oder organisatorischen Änderungen zu aktualisieren.
• Pro-Token-Überschreibungen: Sondereditionen können einzigartige Royalty-Raten im Vergleich zum Standard haben.

Technische Hinweise:

• Konsistenter Nenner: Bleiben Sie bei Basispunkten (10.000) für Klarheit bei Off-Chain-Integrationen.
• Berücksichtigung des Token-Typs: ERC-1155-Implementierungen sollten die Royalty auf den Verkaufspreis pro Token berechnen, nicht auf den Bündelpreis.
• Graceful Fallback: Wenn der Royalty-Empfänger nicht festgelegt ist, geben Sie Null zurück, um fehlgeschlagene Marktplatzaufrufe zu vermeiden.

Marktplatzrealität: Signalgebung vs. Durchsetzung

ERC-2981 signalisiert die Absicht des Schöpfers; es erzwingt keine Zahlung. Verschiedene Plattformen:

• Können ERC-2981 vollständig berücksichtigen.
• Können Royalties unter bestimmten Bedingungen begrenzen oder reduzieren.
• Können Royalties ganz ignorieren.

Angesichts dieser Variabilität experimentieren viele Schöpfer mit hybriden Modellen:

• On-Chain-Einschränkungen über ERC-721C, um Übertragungen auf Royalty-respektierende Betreiber zu beschränken.
• Protokollweite Belohnungen wie Zoraz Creator Rewards.
• Community-Normen und sozialer Druck zur Anerkennung der Einnahmen von Schöpfern.

OpenSeas Entscheidung von 2023, das Operator-Filtering einzustellen, spiegelt den breiteren Trend von Marktauswahl gegenüber protokollweiter Durchsetzung wider, wie in ihrer Ankündigung detailliert beschrieben. In den Jahren 2024–2025 setzt sich dieses Gleichgewicht fort: ERC-2981 bleibt die kanonische Schnittstelle für Royalty-Metadaten, während die Durchsetzung fragmentiert ist.

Testen, Verifizieren und Überwachen

Um zuverlässiges Royalty-Verhalten sicherzustellen:

• Schnittstellenunterstützung überprüfen: Stellen Sie sicher, dass Ihr Vertrag gemäß ERC-165 supportsInterface(0x2a55205a) == true zurückgibt.
• Aufrufe simulieren: Testen Sie royaltyInfo für Randfälle bei Verkaufspreisen und Tokens.
• Indexierungs-Kompatibilität: Registrieren Sie Ihren Vertrag in relevanten Registries wie Royalty Registry, wenn Ihre Marktplatzpartner darauf angewiesen sind.
• Klar dokumentieren: Veröffentlichen Sie Ihre Royalty-Richtlinien, Obergrenzen und Empfängerlogik, um Überraschungen für Käufer und Marktplätze zu minimieren.
• Standard lernen: Wenn Sie neu bei ERC-2981 sind, ist dieser Überblick von Alchemy ein nützlicher Leitfaden: What is ERC-2981?.

Sicherheit und Schlüsselerwaltung für Schöpfer

Royalty-Konfigurationen werden von Administratoren gesteuert. Wenn ein Angreifer Zugriff auf Ihre Deployer- oder Admin-Schlüssel erhält, kann er Royalties umleiten oder deaktivieren. Best Practices:

• Verwenden Sie eine Hardware-Wallet für Aktionen mit hohem Privileg, wie die Festlegung von Standard-Royalties, die Aktualisierung von Empfängern oder die Bereitstellung von Split-Verträgen.
• Bevorzugen Sie Multisig-Setups für von Teams verwaltete Sammlungen.
• Halten Sie Signaturflüsse transparent und überprüfbar.

Für Schöpfer und Studios, die sicheres, portables Signieren wünschen, ohne die Benutzererfahrung zu beeinträchtigen, bieten OneKey Hardware-Wallets:

• Offline-Speicherung privater Schlüssel mit Open-Source-Firmware und transparenten Sicherheitspraktiken.
• Reibungslose Integration mit gängigen Ethereum-Tools für Vertragsbereitstellung und Admin-Operationen.
• Cross-Chain-Unterstützung, nützlich, wenn Ihre NFTs auf L2s oder mehreren EVM-Netzwerken gemintet werden.

Die Verwendung einer Hardware-Wallet zur Verwaltung von Royalty-Einstellungen stellt sicher, dass Ihre On-Chain-Einnahmensignale nicht durch kompromittierte Geräte oder Hot Wallets manipuliert werden können.

Fazit

ERC-2981 ist die Basisschicht für NFT-Royalties: eine einfache, universelle Schnittstelle, die Marktplätze lesen können, um Schöpferauszahlungen zu bestimmen. Es garantiert keine Durchsetzung – das tun Marktplatzrichtlinien –, aber es standardisiert das Signal. In einer Welt, in der die Durchsetzung optional und im Wandel ist, bietet die Kombination von ERC-2981 mit Registries, Split-Verträgen und programmierbaren Einschränkungen wie ERC-721C Schöpfern praktische Werkzeuge, um ihre Arbeit zu erhalten.

Wenn Sie NFT-Sammlungen oder Schöpfer-Infrastruktur verwalten, implementieren Sie ERC-2981 sauber, testen Sie es gründlich und schützen Sie Ihre Admin-Schlüssel mit einer Hardware-Wallet. Diese Kombination maximiert die Interoperabilität über Marktplätze hinweg und schützt gleichzeitig die Einnahmequellen, auf die Ihr Projekt angewiesen ist.