ERC-1363 erklärt: Token-Zahlungen mit Callback, Smart Contracts und Risiken

ERC-1363 erweitert den ERC-20-Tokenstandard um Funktionen, die einen Token-Transfer oder eine Freigabe mit einem unmittelbaren Aufruf an einen Smart Contract verbinden. Statt eine Zahlung und die nachfolgende Aktion als zwei separate Schritte auszuführen, kann eine Anwendung beide Vorgänge in einer Transaktion kombinieren. Das klingt nach einer kleinen technischen Änderung, beeinflusst aber Zahlungsabläufe, Berechtigungen, die Fehlerbehandlung und die Angriffsfläche von Smart Contracts. Dieser Fachartikel erklärt den Standard anhand der offiziellen Spezifikation, ordnet ihn gegenüber ERC-20 und anderen Ethereum-Verfahren ein und zeigt, welche Sicherheitsprüfungen für Nutzer und Entwickler wichtig sind.

Was ist ERC-1363?

ERC-1363 trägt den offiziellen Titel Payable Token. Der als final klassifizierte Standard wurde von Vittorio Minacori eingereicht und baut auf ERC-20 sowie ERC-165 auf. ERC-20 definiert grundlegende Tokenfunktionen wie transfer, transferFrom, approve und allowance. ERC-165 erlaubt es, die Unterstützung bestimmter Schnittstellen programmatisch abzufragen. ERC-1363 ergänzt diese Grundlagen, ersetzt sie aber nicht. Der Kern ist ein Callback: Nach dem vorgesehenen Tokenvorgang ruft der Tokenvertrag eine definierte Funktion beim Empfänger oder beim freigegebenen Vertrag auf. Quelle: https://eips.ethereum.org/EIPS/eip-1363

Ein ERC-20-Transfer übermittelt Token, aber er löst beim empfangenden Smart Contract nicht automatisch eine standardisierte Zahlungsaktion aus. Ein Shop könnte deshalb zunächst Token erhalten und danach einen separaten Aufruf benötigen, der eine Bestellung zuordnet. ERC-1363 ermöglicht es dagegen, die Zahlung und die Reaktion des Empfängers zusammenzuführen. Ob das im konkreten Produkt sinnvoll ist, hängt von dessen Architektur, dem unterstützten Token, der Wallet und dem empfangenden Vertrag ab. Nicht jeder ERC-20-Token unterstützt ERC-1363. Auch die blosse Existenz der Schnittstelle garantiert keine sichere Implementierung.

Die drei Funktionsfamilien im Überblick

transferAndCall: Überweisen und Empfänger aufrufen

Mit transferAndCall(address to, uint256 value) sendet der Aufrufer Token an eine Empfängeradresse. Anschliessend wird bei einem kompatiblen Empfängervertrag onTransferReceived aufgerufen. Eine Variante nimmt zusätzlich bytes data entgegen. Darin kann eine Anwendung beispielsweise eine Bestellkennung transportieren. Das Datenformat legt der Standard nicht allgemein fest. Deshalb müssen Sender und Empfänger dasselbe Format vereinbaren. Ein beliebiger Datenwert ist keine sichere Zahlungsbestätigung und ersetzt niemals die Prüfung des tatsächlichen Tokenvertrags und des empfangenen Betrags.

transferFromAndCall: Zahlung aus einer bestehenden Freigabe

transferFromAndCall(address from, address to, uint256 value) nutzt das aus ERC-20 bekannte Prinzip der allowance: Ein zuvor autorisierter Vertrag kann Token von einem Konto übertragen. Zusätzlich erhält der Zielvertrag den Callback. Der entscheidende Unterschied zu transferAndCall ist also nicht die Empfängerfunktion, sondern die Herkunft der Transferberechtigung. Eine Anwendung muss vor dem Aufruf prüfen, ob die benötigte allowance besteht und ob sie ausreichend ist. Eine unbegrenzte Freigabe kann den Schaden bei einem kompromittierten Spendervertrag erheblich vergrössern.

approveAndCall: Freigeben und Spender benachrichtigen

approveAndCall(address spender, uint256 value) verbindet eine ERC-20-artige Freigabe mit onApprovalReceived beim Spendervertrag. Dieser kann anschliessend eine definierte Aktion durchführen. Das Verfahren ist keine kryptografische Off-Chain-Signatur und nicht mit ERC-2612 Permit gleichzusetzen. approveAndCall benötigt einen On-Chain-Aufruf. Bei beiden Verfahren muss der Nutzer verstehen, wem er welche Tokenrechte einräumt. Eine Freigabe ist nicht dasselbe wie eine einzelne Zahlung: Der Spender kann je nach Vertrag und allowance später weitere Token bewegen.

Praxisbeispiel: Eine Rechnung mit einem ERC-1363-Token bezahlen

Stell Dir vor, ein Dienstleister akzeptiert einen kompatiblen Token mit sechs Dezimalstellen. Eine Rechnung beträgt 25 Token. Der Kunde ruft transferAndCall mit dem Wert 25'000'000 Basiseinheiten und einer kodierten Rechnungsnummer auf. Der Tokenvertrag überträgt den Betrag und ruft onTransferReceived beim Zahlungsdienst auf. Dieser prüft den tatsächlichen Tokenvertrag, den Betrag und die Rechnungskennung und markiert die Rechnung als bezahlt. Die Zahl 25'000'000 ist eine reine Beispielrechnung: 25 mal 10 hoch 6. Sie beschreibt weder einen realen Kurs noch eine aktuelle Gebühr.

Wichtig ist die atomare Ausführung: Wenn der empfangende Vertrag den Callback zurückweist und die Transaktion revertiert, werden die Änderungen dieser Transaktion zurückgenommen. Der offizielle Standard verlangt beim Receiver einen bestimmten Rückgabewert; ein anderer Wert muss zur Rückabwicklung führen. Das schützt vor bestimmten Teilzuständen, beseitigt aber keine Logikfehler. Wenn der Empfänger eine falsche Rechnungsnummer akzeptiert oder eine schädliche externe Aktion auslöst, kann die gesamte Transaktion trotz korrektem Callback wirtschaftlich unerwünscht sein.

Werbung: Bitcoin mit Relai kaufen

Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten.

Bitcoin mit Relai kaufen – Code AUSWANDERNSCHWEIZ nutzen: https://relai.app/de/

Receiver, Spender und Schnittstellenprüfung

Ein ERC1363Receiver implementiert onTransferReceived(address operator, address from, uint256 value, bytes data). Dabei bezeichnet operator den Aufrufer, from das belastete Konto und value den Tokenbetrag. Der Tokenvertrag ist der unmittelbare Aufrufer des Callbacks. Ein Receiver sollte daher msg.sender gegen eine explizite Liste erlaubter Tokenverträge prüfen. Wer lediglich den vom Aufrufer übergebenen Namen oder die Datenfelder vertraut, kann auf gefälschte Tokenzahlungen hereinfallen. Der Receiver muss ausserdem den vorgesehenen Magic Value zurückgeben, andernfalls soll die Transaktion scheitern.

Der ERC1363Spender verarbeitet onApprovalReceived(address owner, uint256 value, bytes data). Auch hier ist der tatsächliche Aufrufer entscheidend. Ein Vertrag sollte Freigaben nicht allein aufgrund eines frei wählbaren Datenfelds als gültig behandeln. Über ERC-165 lässt sich die Unterstützung von ERC-1363 abfragen; die Schnittstellenkennung für den Token ist laut Spezifikation 0xb0202a11. Die Existenz der Kennung sagt jedoch nichts über Auditqualität, Administratorrechte, Upgrade-Mechanismen oder wirtschaftliche Solvenz eines Tokenprojekts aus.

ERC-1363 im Vergleich zu ERC-20 und ERC-2612

ERC-20 ist die breite Basisschnittstelle für fungible Ethereum-Token. ERC-1363 ergänzt atomare Callbacks für bestimmte Zahlungen und Freigaben. ERC-2612 ergänzt hingegen signaturbasierte Freigaben mittels permit, sodass eine Genehmigung unter bestimmten Voraussetzungen durch eine Signatur autorisiert werden kann. ERC-3009 verwendet ebenfalls signierte Autorisierungen für Transfers, verfolgt aber einen anderen Ablauf. Die Standards sind keine austauschbaren Namen für dieselbe Funktion. Eine Wallet, die ERC-20 anzeigen kann, unterstützt deshalb nicht zwangsläufig jede zusätzliche Methode.

Für eine Zahlungsintegration zählt die gesamte Kette: Tokenvertrag, Wallet-Oberfläche, Empfängervertrag, Gaszahlung, Datenkodierung und eventuelle Relayer. Ein Entwickler sollte den tatsächlichen Vertragscode und die dokumentierte Schnittstelle prüfen, nicht bloss den Marketingnamen eines Tokens. Auch Blockexplorer können bei einer Transaktion mehrere interne Aktionen zeigen. Entscheidend ist, ob die Anwendung die gewünschten Zustandsänderungen nach erfolgreicher Bestätigung tatsächlich vorgenommen hat.

Gasgebühren, Skalierung und Wirtschaftlichkeit

Die Spezifikation motiviert ERC-1363 unter anderem damit, dass eine getrennte Zahlung und anschliessende Aktion zwei Transaktionen benötigen können. Ein kombinierter Aufruf kann den Ablauf vereinfachen und in geeigneten Fällen Kosten sparen. Eine pauschale Einsparung lässt sich daraus nicht ableiten. Der Callback selbst verbraucht Gas, komplexe Empfängerverträge können teuer sein und die Kosten hängen vom jeweiligen Netzwerkzustand sowie der Implementierung ab. Ein Vergleich muss denselben wirtschaftlichen Ablauf auf demselben Netzwerk messen.

Beispiel: Ein zweistufiger Ablauf koste hypothetisch 48'000 und 72'000 Gas, zusammen 120'000 Gas. Eine kombinierte Variante benötige 100'000 Gas. Bei identischem Gaspreis wären das 20'000 Gas weniger, entsprechend rund 16,7 Prozent. Diese Zahlen sind frei gewählte Rechenwerte und keine Messung eines bestimmten Tokens. Umgekehrt könnte ein ineffizienter Callback den kombinierten Ablauf verteuern. Auf Layer-2-Netzwerken kommen zusätzliche Besonderheiten der Gebührenberechnung hinzu.

Sicherheitsrisiken: Reentrancy, Allowances und falsche Token

Callbacks erweitern die Interaktion zwischen Verträgen. Sobald ein Tokenvertrag einen Empfänger aufruft, kann dieser seinerseits weitere externe Funktionen ausführen. Dadurch entstehen mögliche Reentrancy-Pfade, insbesondere wenn ein Vertrag interne Guthaben oder Buchungen erst nach einem externen Aufruf aktualisiert. Bewährte Schutzmassnahmen sind sorgfältige Zustandsübergänge, Checks-Effects-Interactions, geeignete Reentrancy-Schutzmechanismen und Tests mit absichtlich bösartigen Empfängerverträgen. Ein Audit kann Risiken reduzieren, garantiert aber keine Fehlerfreiheit.

Bei approveAndCall und transferFromAndCall bleiben die bekannten ERC-20-Allowance-Risiken bestehen. Der ERC-1363-Standard weist ausdrücklich auf das Problem hin, dass beim Ändern einer bestehenden Freigabe unter ungünstiger Transaktionsreihenfolge sowohl der alte als auch der neue Betrag genutzt werden können. Eine mögliche Gegenmassnahme besteht darin, zunächst auf null zu reduzieren und erst danach neu freizugeben. Ob ein bestimmter Token diese Änderung unterstützt, muss separat geprüft werden. Wallet-Nutzer sollten ausserdem nicht unbesehen unbegrenzte Freigaben erteilen.

Weitere Risiken sind gefälschte Token mit gleichem Symbol, manipulierte Vertragsadressen, unerwartete Dezimalstellen, unklare bytes-Daten und fehlende Prüfung des Callback-Absenders. Bei Upgrade-fähigen Verträgen kann sich das Verhalten nach einer Governance- oder Administratorentscheidung ändern. Hinzu kommen allgemeine Krypto-Risiken: starke Kursschwankungen, Totalverlust, Phishing, Hacks, Bridge-Fehler, Verwahrungs- und Gegenparteirisiken. ERC-1363 ist ein technischer Standard, keine Qualitäts- oder Renditezusage.

Werbung: Bitcoin-App Relai

Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten.

Bitcoin mit Relai kaufen – Code AUSWANDERNSCHWEIZ nutzen: https://relai.app/de/

Checkliste für Entwickler und Betreiber

Prüfe zuerst, ob der konkrete Token ERC-1363 und ERC-165 nachweislich implementiert. Teste danach alle drei Aufrufvarianten und die Versionen mit zusätzlichen bytes-Daten. Der Receiver muss den aufrufenden Tokenvertrag, den Sender, den Betrag und die Datenstruktur validieren. Simuliere Rückabwicklungen, fehlende Freigaben, fehlerhafte Magic Values, Reentrancy, Zero-Value-Transfers und unterschiedliche Token-Dezimalstellen. Achte auf klare Ereignisprotokolle und eine eindeutige Zuordnung von Zahlung und Bestellung. Führe Tests mit realistischen Gaslimits und Netzwerkbedingungen durch.

Für eine produktive Zahlungsanwendung sind ausserdem Rückerstattungen, Fehlzahlungen, Supportprozesse und die buchhalterische Erfassung zu klären. Ein technischer Transfer ersetzt weder die rechtliche Prüfung einer Zahlungsdienstleistung noch die steuerliche Beurteilung. Wer in der Schweiz oder grenzüberschreitend Krypto-Zahlungen annimmt, sollte die konkreten Pflichten mit qualifizierten Fachpersonen prüfen. Eine Blockchain-Transaktion kann technisch irreversibel sein, während vertragliche Rückzahlungsansprüche trotzdem bestehen können.

FAQ zu ERC-1363

Kann jeder ERC-20-Token ERC-1363 verwenden?

Nein. ERC-1363 ist eine zusätzliche Schnittstelle. Ein bestehender ERC-20-Token wird nicht automatisch kompatibel. Prüfe die konkrete Vertragsimplementierung und die unterstützten Funktionen.

Brauche ich für ERC-1363 ETH?

Auf Ethereum Mainnet benötigt ein gewöhnlicher On-Chain-Aufruf grundsätzlich Gas in der nativen Netzwerkwährung. Auf anderen EVM-Netzwerken gelten deren jeweilige Gebührenmodelle. Ein Dritter kann Gebühren in bestimmten Architekturen übernehmen, aber das folgt nicht automatisch aus ERC-1363.

Ist ERC-1363 sicherer als ERC-20?

Nicht generell. Die atomare Kopplung kann bestimmte Fehlerabläufe vereinfachen, eröffnet aber zusätzliche externe Aufrufe. Sicherheit hängt vom gesamten Vertragsdesign, der Berechtigungsverwaltung und der konkreten Implementierung ab.

Ist ERC-1363 dasselbe wie Permit2 oder ERC-2612?

Nein. ERC-1363 definiert Callback-basierte Tokenoperationen. ERC-2612 beschreibt signierte Freigaben, während Permit2 eine andere Freigabeinfrastruktur ist. Die Verfahren können sich ergänzen, haben aber unterschiedliche Vertrauensannahmen.

Fazit

ERC-1363 ist eine sinnvolle Erweiterung für Anwendungen, die Tokenzahlung und anschliessende Vertragsaktion in einer Transaktion verbinden möchten. Die wichtigsten Funktionen heissen transferAndCall, transferFromAndCall und approveAndCall. Ihr Nutzen liegt in klareren Zahlungsabläufen und möglichen Effizienzgewinnen, nicht in einer garantierten Gebührenersparnis. Besonders wichtig bleiben die Prüfung des tatsächlichen Tokenvertrags, sichere Callback-Implementierungen, kontrollierte Freigaben und realistische Tests. Für Anleger ist ERC-1363 allein kein Kaufargument; für Entwickler ist es eine konkrete Schnittstelle, die sorgfältig integriert werden muss.

Quellen und weiterführende Literatur

Ethereum Improvement Proposals: ERC-1363 Payable Token (Final), https://eips.ethereum.org/EIPS/eip-1363

Ethereum Improvement Proposals: ERC-20 Token Standard, https://eips.ethereum.org/EIPS/eip-20

Ethereum Improvement Proposals: ERC-165 Standard Interface Detection, https://eips.ethereum.org/EIPS/eip-165

Ethereum Improvement Proposals: ERC-2612 Permit Extension, https://eips.ethereum.org/EIPS/eip-2612

Vertiefung auf Auswandern Schweiz: ERC-2612 Permit – https://www.auswandernschweiz.ch/post/erc-2612-permit-erklärt-token-freigaben-per-signatur-und-risiken

Vertiefung auf Auswandern Schweiz: ERC-3009 – https://www.auswandernschweiz.ch/post/erc-3009-erklärt-usdc-transfers-mit-signatur-relayer-und-sicherheitsrisiken

Vertiefung auf Auswandern Schweiz: ERC-20 Approvals – https://www.auswandernschweiz.ch/post/erc20-token-approvals-permit-phishing-freigaben-widerrufen

Vertiefung auf Auswandern Schweiz: Reentrancy – https://www.auswandernschweiz.ch/post/reentrancy-angriffe-smart-contract-defi-sicherheit

Vertiefung auf Auswandern Schweiz: Ethereum Gas Fees – https://www.auswandernschweiz.ch/post/krypto-gas-fees-ethereum-solana-layer2-erklaert