ERC-7674 erklärt: Temporäre Token-Freigaben, Transient Storage und Risiken
Eine Token-Freigabe sollte möglichst genau auf die beabsichtigte Handlung begrenzt sein. ERC-7674 verfolgt diesen Ansatz mit temporären ERC-20-Allowances. Hier erfährst Du, wie die Technik funktioniert, welche Risiken bleiben und warum die Unterscheidung zu Permit-Signaturen entscheidend ist.
Einordnung: Warum temporäre Token-Freigaben wichtig sind
Wenn Du eine dezentrale Börse, einen Kreditmarkt oder eine andere Ethereum-Anwendung nutzt, musst Du häufig einem Smart Contract erlauben, bestimmte ERC-20-Token aus Deiner Wallet zu übertragen. Diese Berechtigung heisst Allowance oder Approval. Im klassischen ERC-20-Modell bleibt eine einmal erteilte Freigabe grundsätzlich bestehen, bis sie verbraucht, verändert oder widerrufen wird. Viele Nutzer bemerken deshalb nicht, dass alte Freigaben nach einem einzelnen Tausch weiterhin aktiv sind. ERC-7674 beschreibt einen anderen Ansatz: eine temporäre Freigabe, die ausschliesslich innerhalb derselben Transaktion gilt.
Der Standard ist keine neue Kryptowährung und auch kein Schutzmechanismus, den jede Wallet automatisch besitzt. Er beschreibt eine optionale Erweiterung von ERC-20. Entscheidend ist, ob der betreffende Tokenvertrag die Schnittstelle tatsächlich implementiert, ob die Anwendung sie korrekt verwendet und ob die gesamte Transaktion sicher aufgebaut ist. Dieser Artikel grenzt ERC-7674 von gewöhnlichen Approvals, ERC-2612 und Permit2 ab, erklärt die technische Grundlage EIP-1153 und zeigt die praktischen Grenzen. Der Schwerpunkt liegt auf Berechtigungen und Sicherheit, nicht auf Kursprognosen.
Das Grundproblem dauerhafter ERC-20-Allowances
Im klassischen Ablauf rufst Du zunächst approve(spender, amount) beim Tokenvertrag auf. Der Tokenvertrag speichert daraufhin eine Zuordnung aus Eigentümer, berechtigtem Spender und Betrag. Anschliessend kann der Spender über transferFrom innerhalb dieses Limits Token bewegen. Das ist nützlich, weil ein Smart Contract einen Tausch oder eine Einzahlung selbständig abschliessen kann. Die Berechtigung ist jedoch unabhängig davon, ob Du die ursprünglich geplante Aktion tatsächlich durchführst. Wird der Tausch abgebrochen oder nur teilweise ausgeführt, kann ein Restbetrag freigegeben bleiben.
Ein einfaches Beispiel: Du erlaubst einem Router, 1'000 Einheiten eines Tokens zu verwenden. Tatsächlich werden nur 300 benötigt. Je nach Implementierung und Verbrauchslogik können 700 Einheiten als verbleibende Allowance bestehen bleiben. Bei einer unbeschränkten Freigabe kann die Berechtigung noch deutlich grösser sein. Wird der Spendervertrag später kompromittiert, erhält eine bösartige Implementierung zusätzliche Angriffsmöglichkeiten. Eine Freigabe ist keine direkte Überweisung, aber sie schafft eine potenzielle Verfügungsmacht. Darum sollte die Entscheidung über den Spender mindestens so sorgfältig erfolgen wie die Entscheidung über den Betrag.
Nicht jede bestehende Freigabe führt zu einem Verlust. Ein geprüfter und unveränderlicher Vertrag kann über lange Zeit korrekt funktionieren. Dennoch wächst mit jeder unnötigen Berechtigung die Zahl der Verträge, deren Sicherheit für Deine Vermögenswerte relevant wird. Wer mehrere DeFi-Protokolle ausprobiert, kann über Jahre einen unübersichtlichen Bestand an Approvals ansammeln. Temporäre Freigaben sollen diese zeitliche Angriffsfläche reduzieren, ersetzen aber weder die Prüfung des Vertragscodes noch eine sichere Wallet.
Was ERC-7674 konkret standardisiert
ERC-7674 trägt den Titel Temporary Approval Extension for ERC-20. Die Spezifikation beschreibt eine zusätzliche Funktion temporaryApprove(spender, value), mit der ein Tokeninhaber eine zeitlich begrenzte Berechtigung erteilen kann. Die temporäre Allowance wird innerhalb der laufenden Transaktion berücksichtigt und danach automatisch verworfen. Der Standard setzt auf EIP-1153, das eine besondere Speicherart für die Ethereum Virtual Machine bereitstellt. Zum Zeitpunkt dieser redaktionellen Prüfung ist ERC-7674 in der offiziellen EIP-Sammlung als Review gekennzeichnet; eine Review-Spezifikation ist nicht mit einer verpflichtenden, flächendeckend eingeführten Tokenfunktion gleichzusetzen.
Das Wort temporär bezieht sich präzise auf eine Transaktion, nicht auf zehn Minuten, einen Block oder eine frei gewählte Frist. Sobald die Transaktion vollständig abgeschlossen ist, existiert der transient gespeicherte Wert nicht mehr. Innerhalb einer Transaktion können allerdings mehrere interne Aufrufe stattfinden. Diese Aufrufe teilen unter bestimmten EVM-Regeln denselben temporären Speicher des betreffenden Vertrags. Entwickler müssen deshalb genau verstehen, welche Aufrufe auf die Berechtigung zugreifen können und in welcher Reihenfolge sie ausgeführt werden.
ERC-7674 verlangt keinen eigenen Token und ändert nicht die maximale Gesamtmenge eines bestehenden Tokens. Es ist eine Schnittstellenerweiterung. Für Nutzer ist die Unterscheidung zentral: Ein ERC-20-Token unterstützt ERC-7674 nicht automatisch, nur weil er auf Ethereum existiert. Auch eine Börse, die mit ERC-20 umgehen kann, muss die neue Funktion nicht zwingend verwenden. Eine Wallet-Anzeige kann daher eine klassische Freigabe zeigen, obwohl eine Anwendung zusätzlich mit temporären Berechtigungen arbeitet.
Technische Grundlage: EIP-1153 und Transient Storage
EIP-1153 führt die EVM-Operationen TLOAD und TSTORE ein. TSTORE schreibt einen Wert in einen transaktionsgebundenen Speicherbereich; TLOAD liest ihn. Anders als persistenter Contract Storage wird dieser Speicher am Ende der Transaktion vollständig verworfen. Dadurch müssen temporäre Werte nicht dauerhaft in der Blockchain-Zustandsdatenbank erhalten bleiben. Die Spezifikation beschreibt für beide Operationen im ursprünglichen Gasmodell jeweils 100 Gas. Das ist ein Protokollwert für die jeweilige Operation und keine vollständige Nutzergebühr einer DeFi-Transaktion.
Die Unterschiede zwischen Storage, Memory und Transient Storage sind wichtig. Persistenter Storage bleibt über Transaktionen hinweg erhalten. Memory ist auf den jeweiligen Ausführungskontext beschränkt. Transient Storage kann dagegen über mehrere Aufrufrahmen desselben besitzenden Vertrags hinweg innerhalb einer Transaktion zugänglich sein. Bei DELEGATECALL gelten andere Besitzregeln als bei CALL. Wer diese Regeln verwechselt, riskiert unbeabsichtigte Freigaben oder fehlerhafte Schutzmechanismen. Ein temporärer Speicherwert ist deshalb nicht gleichbedeutend mit einer automatisch isolierten oder geheimen Variable.
Die EIP regelt ausserdem, dass Schreibvorgänge eines zurückgesetzten Ausführungsrahmens entsprechend zurückgerollt werden. TSTORE innerhalb eines statischen Aufrufs ist nicht zulässig, TLOAD dagegen schon. Diese Details sind nicht nur für Entwickler interessant: Sie erklären, warum ein scheinbar einfacher Ein-Transaktions-Approval komplexe Sicherheitsannahmen mitbringt. Ein Standard kann die Lebensdauer einer Berechtigung begrenzen, aber er kann keinen fehlerhaften Smart Contract in einen sicheren verwandeln.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Relai bietet Bitcoin an, nicht die hier besprochenen ERC-20-Token.
Wie eine temporäre Freigabe in der Praxis abläuft
Stell Dir eine Anwendung vor, die Token in einem einzigen atomaren Ablauf tauscht. Ein ausführender Smart Contract ruft beim Token zunächst temporaryApprove für den gewünschten Spender und Betrag auf. Danach wird die eigentliche Aktion durchgeführt, bei der transferFrom die verfügbare Berechtigung berücksichtigt. Anschliessend endet die Transaktion und die temporäre Allowance verschwindet automatisch. Der konkrete Aufrufpfad muss so konstruiert sein, dass die Eigentümerberechtigung und die Spenderidentität korrekt geprüft werden. Eine isolierte Wallet-Transaktion, die nur temporaryApprove ausführt, schafft gerade keine Freigabe für eine spätere zweite Transaktion.
Atomar bedeutet hier, dass die miteinander verknüpften Schritte innerhalb einer Transaktion stattfinden und bei einem vollständigen Revert die vorgesehenen Zustandsänderungen zurückgerollt werden. Das verhindert nicht, dass eine erfolgreich abgeschlossene, aber unerwünschte Aktion wirtschaftlichen Schaden verursacht. Wenn Du beispielsweise einen manipulierten Router als Spender autorisierst und dieser die Token innerhalb derselben Transaktion an einen Angreifer weiterleitet, hilft die spätere automatische Löschung der Allowance nicht mehr. Die zeitliche Begrenzung reduziert vor allem das Risiko ungenutzter Restberechtigungen nach der Transaktion.
Für die Benutzeroberfläche ergibt sich eine wichtige Pflicht: Sie muss deutlich machen, welche Transaktion Du signierst, welche Verträge beteiligt sind und welche Token tatsächlich bewegt werden können. Die blosse Bezeichnung temporäre Freigabe ist kein Sicherheitsnachweis. Nutzer sollten sich nicht auf das Marketingwort gasless oder sicher verlassen, sondern den Token, den Spender, die Betragsgrenze und die Transaktionssimulation prüfen, soweit die Wallet diese Informationen zuverlässig bereitstellt.
Klassisches approve, ERC-2612, Permit2 und ERC-7674
Vier Konzepte werden häufig vermischt. Ein klassisches ERC-20-approve setzt eine persistente Allowance. ERC-2612 ermöglicht die Autorisierung einer solchen Freigabe über eine signierte Permit-Nachricht mit Nonce und Deadline; die daraus resultierende Berechtigung ist aber nicht automatisch auf dieselbe Transaktion begrenzt. Permit2 ist eine gesonderte Architektur für die Verwaltung und Nutzung von Tokenberechtigungen und Signaturen, die wiederum eigene Vertrauensannahmen besitzt. ERC-7674 adressiert dagegen ausdrücklich die zeitliche Lebensdauer einer zusätzlichen temporären Allowance auf Tokenebene.
Diese Verfahren sind nicht beliebig austauschbar. Eine signierte Nachricht kann bequem sein, weil der Nutzer nicht zwingend eine separate Freigabetransaktion senden muss. Gleichzeitig kann eine betrügerische Signatur sehr weitreichende Berechtigungen erzeugen. Eine temporäre Allowance kann das Risiko später ungenutzter Approvals reduzieren, verlangt jedoch eine geeignete Transaktionsarchitektur. Wenn eine Anwendung ERC-2612, Permit2 oder ERC-7674 erwähnt, solltest Du deshalb nachfragen, welche Berechtigung tatsächlich entsteht und wie lange sie gültig bleibt. Der Name des Standards allein beantwortet diese Frage nicht.
Eine sinnvolle Vergleichsfrage lautet: Kann der Spender nach Abschluss der konkreten Aktion noch Token bewegen? Bei einem vollständig verbrauchten klassischen Approval lautet die Antwort möglicherweise nein, bei einem grosszügigen Rest-Approval möglicherweise ja. Bei einer korrekt eingesetzten temporären ERC-7674-Freigabe endet die zusätzliche transiente Berechtigung mit der Transaktion. Allerdings können daneben bestehende klassische Allowances weiterbestehen. Das ist ein entscheidender Punkt für eine realistische Sicherheitsbewertung.
Rechenbeispiel: Restfreigabe und wirtschaftliches Risiko
Angenommen, Du hältst 2'000 Token und möchtest davon 250 über einen Router tauschen. Du erteilst klassisch eine Allowance von 2'000 Token. Nach einem transferFrom über 250 Token verbleiben rechnerisch 1'750 Token Allowance, sofern die Implementierung sie um den verbrauchten Betrag reduziert und keine weiteren Änderungen stattfinden. Die Rechnung lautet 2'000 minus 250 gleich 1'750. Diese Restfreigabe ist kein sofortiger Verlust, könnte aber bei einem späteren Angriff auf den Spender relevant werden. Eine passende temporäre Freigabe von 250 Token würde nach dem erfolgreichen Ablauf nicht als zusätzliche transiente Berechtigung bestehen bleiben.
Ein zweites Beispiel verdeutlicht die Gasgebühren. Wenn ein hypothetischer Ablauf 80'000 Gas verbraucht und der effektive Gaspreis 15 Gwei beträgt, ergeben sich 80'000 mal 15 Gwei gleich 1'200'000 Gwei oder 0,0012 ETH. Bei einem rein illustrativen ETH-Preis von 2'000 CHF wären das 2,40 CHF. Diese Zahlen sind Rechenannahmen und ausdrücklich keine aktuellen Netzwerkpreise. ERC-7674 garantiert nicht, dass jede Anwendung billiger ist: Zusätzliche Vertragsaufrufe, die konkrete Architektur, Netzwerkauslastung und gegebenenfalls Layer-2-Gebühren beeinflussen die Gesamtkosten.
Auch das Verlustrisiko lässt sich nicht allein an der nominellen Freigabe ablesen. Ein Token kann wertlos werden, ein Liquiditätspool kann durch einen Smart-Contract-Fehler geleert werden und eine Bridge kann scheitern. ERC-7674 befasst sich mit einem Teil der Berechtigungsverwaltung, nicht mit dem Marktpreis oder der Solvenz eines Gegenübers. Wer Token verwahrt oder DeFi nutzt, muss diese Risiken getrennt beurteilen.
Sicherheitsrisiko: Reentrancy und verschachtelte Aufrufe
Reentrancy bezeichnet Situationen, in denen ein Vertrag während seiner Ausführung erneut aufgerufen wird, bevor der ursprüngliche Ablauf abgeschlossen ist. Temporäre Speicherwerte können über verschachtelte Aufrufrahmen hinweg sichtbar bleiben. Ein Entwickler darf deshalb nicht annehmen, dass eine transiente Allowance nach einem internen Funktionsaufruf automatisch verschwindet. Wenn eine Anwendung untrusted Calls erlaubt, muss sie Berechtigungen, Zustandsübergänge und mögliche Wiedereintritte sorgfältig absichern. Die Sicherheitsüberlegungen von EIP-1153 weisen ausdrücklich auf unerwartete Effekte nicht zurückgesetzter transienter Slots hin.
Ein korrekt gestalteter Reentrancy-Schutz kann selbst Transient Storage verwenden. Das ist jedoch eine separate Anwendung derselben Technik und kein automatischer Bestandteil von ERC-7674. Wenn ein Lock zu früh freigegeben wird, kann er unwirksam sein. Bleibt er innerhalb einer Transaktion unbeabsichtigt gesetzt, kann er spätere legitime Aufrufe blockieren. Ein Security Audit sollte daher nicht nur prüfen, ob der Speicher nach Transaktionsende leer ist, sondern auch alle Zwischenzustände, externe Calls, Reverts und Proxy-Konstellationen betrachten.
Sicherheitsrisiko: Phishing, falsche Spender und manipulierte Frontends
Ein Angriff kann bereits vor dem eigentlichen Smart-Contract-Aufruf beginnen. Eine gefälschte Webseite kann Dich dazu verleiten, eine Transaktion für einen fremden Spender zu signieren. Selbst wenn diese Berechtigung nur eine Transaktion lang besteht, kann der Angreifer die Token während dieser Transaktion transferieren. Die zeitliche Beschränkung ist also keine Alternative zu Domainprüfung, Vertragsadressprüfung und einer verständlichen Transaktionsvorschau. Besonders bei unbekannten DeFi-Anwendungen solltest Du mit kleinen Beträgen beginnen und verdächtige Signaturaufforderungen ablehnen.
Bei komplexen Transaktionen ist eine Wallet-Simulation hilfreich, aber nicht unfehlbar. Simulationen beruhen auf einem bestimmten Zustandsstand und können von späteren Ausführungsbedingungen abweichen. Ausserdem zeigen manche Oberflächen interne Tokenbewegungen nur unvollständig an. Eine Hardware Wallet schützt den privaten Schlüssel vor direkter Offenlegung, kann aber eine von Dir ausdrücklich bestätigte bösartige Transaktion nicht grundsätzlich verhindern. Sicherheitsbewusstsein bleibt auch bei moderneren Approval-Standards unverzichtbar.
Kompatibilität: Welche Token und Wallets unterstützen ERC-7674?
Eine allgemeingültige Liste unterstützter Token, Wallets und DeFi-Protokolle lässt sich nicht aus der ERC-Spezifikation ableiten. Der Standard beschreibt ein Interface, aber keine verbindliche Einführungspflicht. Du musst für jeden konkreten Tokenvertrag prüfen, ob temporaryApprove implementiert ist und wie die Anwendung diese Funktion nutzt. Ein identischer Tokenname auf zwei Netzwerken garantiert zudem nicht, dass die jeweiligen Vertragsversionen dieselben Funktionen besitzen. Besonders bei Bridged Tokens und Wrapped Assets sind zusätzliche Vertrags- und Emittentenrisiken zu beachten.
Vermeide deshalb Aussagen wie alle ERC-20-Token sind kompatibel oder Wallet X verwendet automatisch temporäre Freigaben. Auch ein sichtbarer Approval-Dialog kann ein klassisches approve meinen. Eine zuverlässige technische Prüfung betrachtet den verifizierten Contract-Code, die unterstützte Schnittstelle und die tatsächliche Transaktionsspur. Ohne diese Prüfung sollte eine Anwendung ihre Unterstützung nicht als gesichert bewerben. Für Einsteiger reicht als praktische Regel: Eine temporäre Freigabe ist nur dann vorhanden, wenn sie im konkret verwendeten Vertrag und Ablauf tatsächlich umgesetzt wurde.
Wann temporäre Approvals sinnvoll sind
Besonders naheliegend sind Anwendungen, die eine klar begrenzte Tokenbewegung vollständig innerhalb einer Transaktion ausführen können. Dazu gehören bestimmte Router-, Aggregator- und Abwicklungsarchitekturen. Ein Nutzer möchte beispielsweise genau einen Tausch durchführen und danach keine neue dauerhafte Spenderberechtigung hinterlassen. Die temporäre Freigabe passt zu dieser Absicht. Sie kann auch bei komplexeren atomaren Abläufen interessant sein, wenn mehrere interne Schritte eine kontrollierte Berechtigung benötigen und am Ende ein eindeutiges Ergebnis steht.
Weniger geeignet ist ein Verfahren, bei dem die eigentliche Abbuchung erst in einer späteren Transaktion stattfinden soll. Ein wiederkehrender Zahlungsdienst, eine zeitverzögerte Abrechnung oder ein mehrstufiger Prozess über verschiedene Transaktionen kann sich nicht auf eine ERC-7674-Freigabe aus der Vergangenheit stützen. Dafür braucht es andere Autorisierungsmodelle mit eigenen Sicherheitsregeln. Entwickler sollten die zeitliche Begrenzung nicht durch unsichere Umgehungen aushebeln, nur um ein bestimmtes Marketingversprechen erfüllen zu können.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Code: AUSWANDERNSCHWEIZ.
Was ERC-7674 nicht löst
Der Standard schützt nicht vor einem kompromittierten privaten Schlüssel, einer manipulierten Wallet, einem gefälschten Token, fehlerhaften Preisorakeln oder einer insolventen zentralen Börse. Er schützt auch nicht vor Slashing beim Staking und nicht vor einer Bridge, deren Verwahrungs- oder Validierungsmodell scheitert. Wer einen Altcoin kauft, trägt weiterhin Kursrisiken bis hin zum Totalverlust. Temporäre Freigaben sind ein Baustein der Smart-Contract-Sicherheit, nicht die Lösung sämtlicher Risiken des Blockchain-Ökosystems.
Zudem können bestehende persistente Allowances neben einer temporären Berechtigung weiterhin eine Rolle spielen. Eine Anwendung, die beide Modelle kombiniert, muss genau festlegen, welche Berechtigung zuerst verbraucht wird und wie der verfügbare Gesamtbetrag berechnet wird. Ein Nutzer, der eine neue temporäre Freigabe erteilt, sollte nicht daraus schliessen, dass alte klassische Approvals automatisch widerrufen wurden. Dafür sind separate Kontrollen und gegebenenfalls Revocation-Transaktionen erforderlich.
Checkliste für Nutzer in der Schweiz
Prüfe zuerst, ob Du die Anwendung wirklich benötigst und ob Du ihre offizielle Domain geöffnet hast. Kontrolliere dann den Tokenvertrag, die Netzwerkkennung, die Spenderadresse und den maximalen Betrag. Nutze nach Möglichkeit eine Wallet mit verständlicher Transaktionsvorschau und überprüfe die angezeigten Tokenbewegungen. Trenne grössere langfristige Bestände von einer Wallet, mit der Du experimentelle DeFi-Anwendungen testest. Diese organisatorische Trennung reduziert die Auswirkungen einzelner Fehlentscheidungen, auch wenn sie keine absolute Sicherheit bietet.
Dokumentiere grössere Tokenbewegungen und die zugehörigen Transaktionskennungen. Für die Schweizer Steuererklärung können Bestände und Erträge relevant sein; die steuerliche Behandlung hängt vom Sachverhalt und der Einordnung durch die zuständigen Behörden ab. Eine temporäre Approval-Transaktion ist nicht automatisch ein steuerpflichtiger Verkauf, aber der anschliessende Tausch, ein Staking-Ertrag oder eine andere wirtschaftliche Handlung kann gesondert zu beurteilen sein. Verlasse Dich nicht auf pauschale Steuerbehauptungen in Krypto-Foren und prüfe bei Bedarf die Hinweise der ESTV und Deines Kantons.
Risiken für Entwickler und Protokollbetreiber
Für Entwickler reicht es nicht, die Funktion temporaryApprove in einen bestehenden Tokenvertrag einzufügen. Sie müssen prüfen, wie die temporäre und die persistente Allowance zusammenspielen, welche Ereignisse ausgegeben werden, wie externe Integrationen reagieren und ob Proxy- oder Delegatecall-Architekturen besondere Effekte erzeugen. Unit Tests sollten sowohl erfolgreiche Transfers als auch Reverts, Teilverbräuche, verschachtelte Aufrufe, mehrfaches Setzen und Grenzwerte abdecken. Besonders wichtig ist ein Test, der zeigt, dass nach dem Ende einer Transaktion keine transiente Berechtigung mehr genutzt werden kann.
Eine Sicherheitsprüfung sollte zudem analysieren, ob untrusted Contracts während des erlaubten Zeitfensters erneut aufrufen können und ob die Spenderprüfung in allen Codepfaden konsistent bleibt. Auditberichte sind hilfreiche Hinweise, aber kein Garant für Fehlerfreiheit. Upgrades, geänderte Integrationen oder neue Angriffstechniken können alte Prüfungen entwerten. Für Protokollbetreiber ist transparente Dokumentation wichtig: Nutzer müssen erkennen können, welche Berechtigungen dauerhaft und welche nur temporär sind.
FAQ: Häufige Fragen zu ERC-7674
Ist ERC-7674 dasselbe wie ERC-2612? Nein. ERC-2612 definiert signierte Permit-Freigaben, während ERC-7674 eine transaktionsgebundene temporäre Allowance beschreibt. Beide können die Nutzererfahrung beeinflussen, lösen aber unterschiedliche Probleme. Brauche ich dafür eine neue Kryptowährung? Nein. Der Standard ist eine optionale Erweiterung eines Tokenvertrags und kein eigenständiger Coin.
Kann ich mit ERC-7674 ganz ohne Gasgebühren handeln? Nein. Auch eine temporäre Freigabe und die nachfolgende Tokenbewegung benötigen Rechenarbeit auf dem Netzwerk. Wer die Gebühr bezahlt und wie hoch sie ausfällt, hängt vom konkreten Transaktionsmodell ab. Muss ich nach einem temporären Approval noch etwas widerrufen? Die transiente Berechtigung endet automatisch mit der Transaktion. Unabhängige ältere, persistente Freigaben bleiben jedoch bestehen, solange sie nicht anderweitig verändert oder widerrufen werden.
Schützt mich ERC-7674 vor einem betrügerischen Smart Contract? Nicht zuverlässig. Ein bösartiger Spender kann innerhalb der autorisierten Transaktion Schaden verursachen. Ist ERC-7674 überall verfügbar? Nein. Entscheidend sind die konkrete Tokenimplementierung, die Integrationen und der technische Entwicklungsstand. Kann eine temporäre Berechtigung mehrere Transaktionen überdauern? Gerade das ist nicht ihr Zweck: Sie wird nach der jeweiligen Transaktion verworfen.
Fazit: Kürzere Berechtigungen sind sinnvoll, aber kein Freipass
ERC-7674 setzt an einem echten Problem an: Klassische Token-Freigaben bleiben oft länger bestehen als nötig. Die Kombination mit EIP-1153 ermöglicht eine Berechtigung, die nur innerhalb einer Transaktion verfügbar ist. Das kann die Angriffsfläche durch ungenutzte Restfreigaben reduzieren und passt besonders zu atomaren DeFi-Abläufen. Die technische Umsetzung verlangt jedoch sorgfältige Prüfung der Aufrufreihenfolge, der Vertragskompatibilität und des Zusammenspiels mit vorhandenen Allowances.
Für Dich als Nutzer ist die wichtigste Erkenntnis nicht der Name eines ERC-Standards, sondern die tatsächliche Verfügungsmacht, die Du einem Smart Contract erteilst. Prüfe Betrag, Spender, Transaktion und die Seriosität der Anwendung. Halte grössere Bestände getrennt von experimentellen Wallets und betrachte temporäre Approvals als zusätzliche Sicherheitsmassnahme, nicht als Ersatz für Vorsicht. Dieser Artikel dient der allgemeinen Information und ist keine individuelle Anlage-, Steuer- oder Rechtsberatung.
Kommentare