ERC-777 erklärt: Der moderne Token-Standard mit Hooks

ERC-777 ist ein neuerer Ethereum-Token-Standard, der entwickelt wurde, um langjährige Einschränkungen von ERC-20 zu beheben und gleichzeitig programmierbare „Hooks“ für reichhaltigere Token-Flüsse einzuführen. Wenn Sie Entwicklergespräche über Komponierbarkeit, sicherere Genehmigungen und Protokollautomatisierung verfolgt haben, dann ist ERC-777 an der Schnittstelle dieser Bedürfnisse angesiedelt. Dieser Artikel erklärt, wie ERC-777 funktioniert, warum es existiert, wo seine Stärken liegen, welche Sicherheitskompromisse zu beachten sind und wie Benutzer und Entwickler es im Jahr 2025 angehen können.

Das Problem, das ERC-777 lösen sollte

ERC-20 wurde zum Standard für fungible Token, hat aber bemerkenswerte Schwachstellen:

• Genehmigungen sind umständlich und fehleranfällig (z. B. das Vergessen, die Zulassungen zurückzusetzen).
• Verträge können nicht automatisch reagieren, wenn Token ankommen; sie benötigen Interaktionen im Pull-Stil.
• Die Transfersemantik ist begrenzt, was komplexe Abläufe (Gebühren, Rückrufe, mehrstufige Arbeitsabläufe) erschwert.

ERC-777 versucht, dies zu modernisieren, indem es Folgendes bietet:

• Integrierte Sende-/Empfangs-Hooks, damit Verträge auf Überweisungen innerhalb derselben Transaktion reagieren können.
• Operator-basierte Überweisungen, die die Token-Verwaltung für Verwahrer und Dienste vereinfachen.
• Abwärtskompatibilität mit ERC-20-Schnittstellen, um die Akzeptanz im Ökosystem zu erleichtern.

Eine formale Spezifikation finden Sie im kanonischen ERC-777-Standard auf der Website der Ethereum Improvement Proposals: EIP-777. Um ihn im breiteren Token-Ökosystem zu verorten, bieten die Entwicklerdokumente von Ethereum zu Token-Standards Kontext und Links zu verwandten EIPs: Übersicht über Ethereum-Token-Standards.

Wie ERC-777 funktioniert: Hooks und Operatoren

Zwei Kernideen treiben ERC-777 an.

1. Hooks

• tokensToSend: Ein Hook auf Senderseite, der aufgerufen wird, bevor Token verschoben werden.
• tokensReceived: Ein Hook auf Empfängerseite, der aufgerufen wird, nachdem Token angekommen sind.
• Diese sind optional und werden über die globale Schnittstellenregistrierung EIP-1820 entdeckt.

Mithilfe von Hooks können Verträge während Überweisungen Geschäftslogik implementieren: automatisches Staking, Gebührenaufteilung, Protokollierung, Sperrung oder Ablehnung unerwarteter Token. Hooks erhöhen die Komponierbarkeit und reduzieren die Notwendigkeit separater "Genehmigen und dann aufrufen"-Abläufe.

2. Operatoren

• Ein Operator ist autorisiert, Token im Namen eines Halters zu übertragen, ähnlich einem beauftragten Verwahrer.
• Standardoperatoren können von einem Token festgelegt werden, und Benutzer können sie jederzeit widerrufen.
• Operatoren auf ERC-777 sind ein expliziteres und flexibleres Modell im Vergleich zu ERC-20-Zulassungen.

In der Praxis verlassen sich die meisten Teams auf geprüfte Bibliotheken. OpenZeppelin bietet eine weit verbreitete Implementierung mit klaren APIs und Leitplanken: OpenZeppelin ERC-777 Verträge.

Ein minimales Entwicklerbeispiel

Unten sehen Sie ein Schema eines Empfängervertrags, der tokensReceived über EIP-1820 verwendet. Verwenden Sie für Produktionscode immer geprüfte Bibliotheken und führen Sie Audits durch.

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

import "@openzeppelin/contracts/token/ERC777/IERC777.[sol](https://onekey.so/blog/de/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/interfaces/IERC1820Registry.[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/) ExampleReceiver {
    IERC1820Registry constant _ERC1820 =
        IERC1820Registry(0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24);

    bytes32 constant TOKENS_RECIPIENT_INTERFACE_HASH =
        keccak256("ERC777TokensRecipient");

    event Received(address operator, address from, uint256 amount, bytes data, bytes operatorData);

    constructor() {
        _ERC1820.setInterfaceImplementer(address(this), TOKENS_RECIPIENT_INTERFACE_HASH, address(this));
    }

    // ERC777 tokensReceived hook
    function tokensReceived(
        [address](https://onekey.so/blog/de/ecosystem/what-is-a-crypto-wallet-address/) operator,
        [address](https://onekey.so/blog/de/ecosystem/what-is-a-crypto-wallet-address/) from,
        [address](https://onekey.so/blog/de/ecosystem/what-is-a-crypto-wallet-address/) /*to*/,
        uint256 amount,
        bytes calldata data,
        bytes calldata operatorData
    ) external {
        // Benutzerdefinierte Logik, z. B. Einzahlung aufzeichnen oder interner Buchhaltung auslösen
        emit Received(operator, from, amount, data, operatorData);
    }
}

Schlüsselbotschaft: Hooks ermöglichen es Verträgen, Token-Bewegungen zu „belauschen“, ohne separate Funktionsaufrufe zu tätigen, was die Reibung reduziert und komplexe Abläufe nativ erscheinen lässt.

Sicherheitsüberlegungen: Reentrancy und Protokolldesign

Hooks sind mächtig, führen aber zu Reentrancy-Risiken, wenn Verträge nicht defensiv konzipiert sind. In der frühen DeFi hat eine Reihe von Vorfällen gezeigt, wie Token-Rückrufe unerwartet mit Protokollen interagieren konnten, die ein ERC-20-ähnliches Verhalten annahmen. Diese Lektionen haben zu Best Practices geführt, die bis heute relevant sind:

• Bevorzugen Sie Checks-Effects-Interactions in zustandsverändernden Funktionen.
• Verwenden Sie Reentrancy-Schutzvorrichtungen für externe Aufrufpfade.
• Entwerfen Sie Pool-/Buchhaltungslogik sorgfältig so, dass sie robust gegen die Ausführung von Rückrufen während einer Überweisung ist.
• Ziehen Sie nach Möglichkeit ein "Pull"-Modell für sensible Vorgänge in Betracht.
• Vermeiden Sie die Annahme, dass Überweisungen nebenwirkungsfrei sind.

Auch wenn die spezifischen Exploits aus der Uniswap v1-Ära Geschichte sind, gilt das Prinzip: Hooks machen Token-Überweisungen aktiv, nicht passiv. Moderne Audits und Bibliotheken haben sich entsprechend weiterentwickelt. Als grundlegende Referenz zum Standard und seinen Sicherheitshinweisen siehe EIP-777. Um gut gepflegte Muster und Leitplanken zu studieren, siehe Dokumentation von OpenZeppelin zu ERC-777.

Interoperabilität und Migration von ERC-20

ERC-777-Token sind im Allgemeinen abwärtskompatibel mit ERC-20-Schnittstellen, aber die Annahmen unterscheiden sich:

• Überweisungen können Hooks auslösen, die Nebenwirkungen haben können.
• Operatoren ersetzen oder ergänzen Zulassungen und verändern, wie Dienste interagieren.
• Wallets und dApps müssen Metadaten und Hook-basierte Abläufe korrekt behandeln.

Einige Teams bleiben bei ERC-20 plus Verbesserungen wie EIP-2612 Permit (gasfreie Genehmigungen), angesichts der breiten Vertrautheit im Ökosystem. Andere übernehmen ERC-777, wo programmierbare Empfangs- oder Operator-Semantik die Benutzererfahrung oder die Protokollogik maßgeblich verbessert.

Landschaft 2025: Wo Hooks passen

Während ERC-20 immer noch die fungiblen Token dominiert, haben Hooks das Design an anderer Stelle beeinflusst. Ein klares Beispiel ist die Architektur von Uniswap v4, die programmierbare "Hooks" auf der Ebene von Liquiditätspools nutzt, um Funktionen wie dynamische Gebühren und maßgeschneiderte Logik zu ermöglichen und das Protokoll dadurch von vornherein komponierbarer zu machen. Kontext zu dieser Entwicklung finden Sie in der Uniswap v4-Übersicht und der Diskussion über Hooks: Uniswap v4 Ankündigung und Hooks.

Auf Token-Ebene bleibt die Akzeptanz von ERC-777 selektiv – insbesondere in Kontexten, in denen automatische Rückrufe und Operator-Semantik einen greifbaren Mehrwert bieten, wie z. B.:

• Verwahrungs- oder Dienstleister-Abläufe, die von Operator-Überweisungen profitieren.
• On-Chain-Treueprogramme oder Streaming-Zahlungen, die beim Empfang reagieren.
• Infrastrukturschichten, die Token-native Rückrufe für Buchhaltungs- oder Gebührenerfassungszwecke wünschen.

In der Zwischenzeit verbessern Layer-2-Netzwerke weiterhin ihre Durchsatz- und Kostenprofile, wodurch komplexere Token-Lebenszykluslogik praktikabel wird. Dieses Umfeld macht die Programmierbarkeit von ERC-777 zu einer zeitgerechten Option für Teams, die reichhaltigere Überweisungsschemata benötigen, aber in robuste Sicherheitstechnik investieren können.

Best Practices für Entwickler

• Verwenden Sie geprüfte Bibliotheken und greifen Sie standardmäßig auf bekannte Implementierungen zurück. Beginnen Sie mit OpenZeppelin ERC-777.
• Entwerfen Sie Hook-Logik für Fehlerfälle: Unerwartete Token ablehnen, Ursprung validieren und Invarianzprüfungen aufrechterhalten.
• Dokumentieren Sie Standardoperatoren deutlich; bieten Sie einfache Widerrufswege für Benutzer an.
• Wenden Sie Reentrancy-Schutzmaßnahmen an, insbesondere bei tokensReceived, und vermeiden Sie externe Aufrufe während kritischer Buchhaltungsschritte, es sei denn, dies ist unbedingt erforderlich.
• Überlegen Sie, ob Sie Hooks wirklich benötigen. Wenn nicht, können ERC-20 plus EIP-2612 Permit die Integration und die Erwartungen der Benutzer vereinfachen.
• Testen Sie auf verschiedenen Wallets und dApps, die ERC-777 möglicherweise unterschiedlich behandeln. Verwenden Sie das EIP-1820 Registry korrekt, um Implementierer zu registrieren.

Praktische Tipps für Benutzer

• Verstehen Sie, dass ERC-777-Token Logik auslösen können, wenn sie bestimmte Verträge erreichen. Dies ist in der Regel vorteilhaft, ändert aber die Annahmen im Vergleich zu "passiven" ERC-20-Überweisungen.
• Überprüfen Sie, was Sie genehmigen und wem. Wenn ein Token Betreiber oder Rückrufe verwendet, stellen Sie sicher, dass Sie dem Code und dem Ruf des empfangenden Vertrags vertrauen.
• Bevorzugen Sie Wallets, die klare Vertragsmethodendetails anzeigen, nicht nur "transfer" oder "send". Wenn etwas ungewohnt aussieht oder willkürliche Datenfelder enthält, halten Sie inne und verifizieren Sie.

Wann ERC-777 in Betracht ziehen

ERC-777 ist sinnvoll, wenn:

• Sie ereignisgesteuertes Token-Verhalten im Moment der Überweisung benötigen (z. B. automatische Einzahlung, Gebührenweiterleitung, benutzerdefinierte Sperrung).
• Operatoren Ihr Dienstleistungs- oder Verwahrungsmodell sinnvoll vereinfachen.
• Sie sich zu rigoroser Sicherheitstechnik und Audits verpflichten, um Rückruf-basierte Semantik sicher zu handhaben.

ERC-777 ist möglicherweise weniger ideal, wenn:

• Einfachheit und breite Ökosystemkompatibilität oberste Priorität haben.
• Sie Ihre Ziele über ERC-20 plus Permit oder übergeordnete Protokollmechanismen (z. B. anwendungsspezifische Controller ohne Token-Hooks) erreichen können.

Eine Hardware-Wallet-Perspektive

Bei Token-Standards mit reicherem Verhalten und potenziellen Nebenwirkungen sind klare Transaktionsinspektion und Offline-Signierung von unschätzbarem Wert. OneKey ist eine Open-Source-Hardware-Wallet, die transparente On-Device-Bestätigungen und breite EVM-Token-Unterstützung hervorhebt. Wenn Sie regelmäßig mit fortgeschrittenen Token-Standards oder DeFi-Protokollen interagieren, die Rückrufe nutzen, hilft die Verwendung einer Hardware-Wallet sicherzustellen, dass Sie genau überprüfen, was Sie signieren, und reduziert die Exposition gegenüber bösartigen Verträgen. Mit anderen Worten, die Komplexität von ERC-777 macht ein sicheres Schlüsselmanagement und explizite, menschenlesbare Bestätigungen noch wichtiger – Bereiche, in denen ein Gerät wie OneKey spürbare Beruhigung bieten kann.

Fazit

ERC-777 führt moderne Token-Funktionen ein – Hooks und Operatoren –, die reichhaltigere, besser komponierbare Token-Flüsse auf Ethereum und EVM-Chains ermöglichen. Seine Stärke geht mit Verantwortung einher: Hooks sind aktiv, nicht passiv, und erfordern defensive Programmierung und sorgfältige Benutzererfahrung. Im Jahr 2025 hat das Konzept der Hooks das Protokolldesign über Token hinaus beeinflusst, wie bei Uniswap v4 zu sehen ist, während ERC-777 selbst eine gezielte Wahl für Teams bleibt, die wirklich von programmierbarer Rezeption und Operator-Semantik profitieren. Egal, ob Sie ERC-777 übernehmen oder bei verbesserten ERC-20-Mustern bleiben, kombinieren Sie gute Ingenieurspraktiken mit sicheren Benutzer-Workflows – und ziehen Sie Hardware-gestützte Signierung in Betracht –, damit Ihre Token-Logik sowohl leistungsfähig als auch sicher ist.