Token-Freigaben: Die Berechtigungen, die Sie immer wieder erteilen

Jedes Mal, wenn Sie mit einer DeFi-App interagieren — ein Swap auf einer DEX, eine Einzahlung in einen Kreditmarkt, eine Bridge mit einem ERC-20 — haben Sie mit ziemlicher Sicherheit eine Token-Freigabe erteilt. Die meisten Nutzer signieren sie in Sekunden und vergessen sie. Trotzdem ist diese eine Approve-Transaktion eine der folgenreichsten Dinge, die Sie auf Ethereum tun: Sie verleiht einem Smart Contract eine dauerhafte Erlaubnis, Ihre Tokens zu bewegen — oft ohne weitere Bestätigung. Dieser Leitfaden erklärt, was eine Token-Freigabe ist, warum dApps sie verlangen, welche Risiken unbegrenzte Allowances mit sich bringen und was das alles bedeutet, wenn Sie Freigaben über SSP signieren.

Warum es Freigaben überhaupt gibt

ERC-20-Tokens werden nicht "in" Ihrer Wallet gespeichert wie ETH. Ein ERC-20-Token-Vertrag ist ein Hauptbuch: eine Zuordnung von Adressen zu Salden. Wenn Sie 1.000 USDC halten, existiert on-chain eine Zeile im USDC-Vertrag, die besagt, dass Ihre Adresse 1.000 Einheiten besitzt.

Da das Guthaben innerhalb des Token-Vertrags lebt, kann nur dieser Vertrag es bewegen. Wenn Sie USDC an einen Freund senden, ruft Ihre Wallet direkt die transfer-Funktion des Tokens auf.

Aber eine DEX, bei der ein anderer Vertrag (der Router) USDC aus Ihrer Adresse ziehen muss, um einen Swap auszuführen, kann nicht in den Token-Vertrag greifen und Ihr Guthaben nehmen. ERC-20 löst das mit einem zweistufigen Delegationsmuster:

1. Sie rufen approve(spender, amount) auf dem Token-Vertrag auf. Das setzt eine Allowance: einen Eintrag, dass der Spender bis zu amount Ihrer Tokens bewegen darf.
2. Der Spender ruft später transferFrom(yourAddress, destination, amount) auf dem Token-Vertrag auf. Der Vertrag prüft die Allowance, verringert sie und bewegt die Tokens.

Die Freigabe ist der Schlüssel. Ohne sie kann der Router Ihre USDC überhaupt nicht anrühren.

Was tatsächlich gewährt wird

Lesen Sie approve(spender, amount) wörtlich. Sie sagen dem ERC-20-Vertrag: "Diese Adresse darf bis zu so viele meiner Tokens abheben, jederzeit, in beliebig vielen Transaktionen, bis ich es ändere."

Daraus folgt einiges:

• Dauerhafte Erlaubnis, keine einmalige Aktion. Einmal erteilt, braucht der Spender Ihre Signatur nicht erneut, um Tokens abzurufen, bis die Allowance aufgebraucht oder widerrufen ist.
• Pro Token. Den DEX-Router für USDC freizugeben, erlaubt ihm nicht, auf Ihr DAI zuzugreifen; dafür ist eine separate Freigabe für DAI nötig.
• Pro Spender. Ein anderer Vertrag — auch von derselben dApp — hat seine eigene Allowance.
• Kein Ablauf. ERC-20 hat keine eingebaute Frist. Eine 2023 gesetzte Allowance ist 2026 immer noch aktiv, sofern sie nicht aufgebraucht oder widerrufen wurde.

Jede Allowance können Sie auf einem Block-Explorer wie etherscan prüfen, indem Sie die View-Funktion allowance(owner, spender) des Token-Vertrags lesen.

Das Muster der unendlichen Allowance

Wenn Freigaben pro Betrag erfolgen, warum fragt fast jede DEX nach einer enormen Zahl — meist 2^256 - 1, angezeigt als "unlimited" oder MaxUint256 — statt nur nach dem Betrag, den Sie gerade tauschen?

Die Antwort ist UX und Gas. Würde eine DEX bei jedem Swap eine frische Allowance in Höhe des Trades verlangen, würden Sie jedes Mal eine Approve-Transaktion bezahlen und müssten zwei Transaktionen bestätigen für das, was sich wie eine Aktion anfühlt. Indem die dApp einmal eine unbegrenzte Allowance erbittet, können Sie anschließend mit nur einer Transaktion pro Trade frei swappen.

Das ist wirklich bequem. Es ist auch wirklich riskanter. Eine unbegrenzte Allowance bedeutet, dass der Spender-Vertrag berechtigt ist, Ihr gesamtes aktuelles Guthaben dieses Tokens — und jedes künftige Guthaben — jederzeit zu leeren, ohne dass Sie etwas weiteres signieren.

Bei einem bekannten, geprüften, unveränderlichen Vertrag ist das praktische Risiko meist gering. Bei einer frisch deployten dApp, einem upgradebaren Proxy oder einem unbekannten Vertrag ist eine unbegrenzte Allowance eine viel größere Angriffsfläche als der Trade, den Sie beabsichtigt hatten.

Das echte Risiko: ein dauerhafter Schlüssel zu Ihren Tokens

Die Gefahr von Freigaben liegt nicht in der Approve-Transaktion selbst. Sondern in dem, was danach passiert. Einige Szenarien:

• Der Spender-Vertrag hat einen Bug. Ein Angreifer nutzt seine transferFrom-Logik aus, und jede Wallet mit einer Allowance ungleich null wird geleert.
• Der Spender-Vertrag ist upgradebar. Wer die Upgrade-Schlüssel kontrolliert, deployt neue Logik, die Tokens von jedem mit einer aktiven Allowance einzieht.
• Sie haben einen bösartigen Klon freigegeben. Eine Phishing-Seite imitierte die URL einer echten dApp, und der Vertrag, den Sie freigegeben haben, war von Anfang an unter der Kontrolle eines Angreifers.
• Die Signier-Schlüssel des Spenders sind kompromittiert. Der offizielle Vertrag ist in Ordnung; die Wallet des Betreibers nicht, und die Allowances werden von einem Eindringling ausgeübt.

In jedem Fall signieren Sie nichts, wenn der Drain passiert. Die Wochen zuvor erteilte Freigabe ist die einzige Autorisierung, die der Angreifer braucht. "Genehmige nur, was du brauchst, und widerrufe, was du nicht mehr nutzt" ist keine Paranoia; es ist dasselbe Prinzip wie keinen Ersatzschlüssel an jeden Handwerker zu verteilen, den man je beauftragt hat.

Wie sich Freigaben leise ansammeln

Eine Wallet, die ein bis zwei Jahre in DeFi aktiv ist, hat dutzende Freigaben angesammelt: jede DEX, jeden Aggregator, jeden Lending-Markt-Deposit, jeden NFT-Marktplatz, jede Bridge. Nutzer widerrufen so gut wie nie. Das Resultat ist ein langer Schwanz dauerhafter Berechtigungen, viele davon unbegrenzt, viele für Verträge, mit denen der Nutzer gar nicht mehr interagiert.

Das ist die stille Angriffsfläche. Sie zeigt sich in keiner einzelnen Transaktion; sie ist der kumulative Rückstand normaler Nutzung. Diese Liste zu prüfen und zu beschneiden ist eine der wirksamsten Sicherheitsgewohnheiten in der Selbstverwahrung — der nächste Artikel zeigt genau wie in Token-Freigaben aus SSP widerrufen.

Ein neueres Muster: EIP-2612 permit

ERC-20 ist älter als ein Großteil moderner DeFi, und der Zwei-Transaktionen-Tanz aus Approve-und-dann-Swap gilt seit Langem als umständlich. EIP-2612 führte eine Alternative für Tokens ein, die das unterstützen: Statt eine approve-Transaktion on-chain zu senden, signiert der Nutzer eine Off-chain-Nachricht (ein permit), die einen bestimmten Spender, Betrag und eine Frist autorisiert. Die dApp reicht diese Signatur zusammen mit dem Swap in einer einzigen Transaktion ein.

permit ist gas-sparsam, eingegrenzt (es trägt einen expliziten Betrag und Ablaufzeitpunkt) und schwerer hängen zu lassen, weil die Frist den Ablauf erzwingt. Nicht jeder ERC-20 unterstützt es — USDC und DAI tun es, viele ältere Tokens nicht — aber wo es verfügbar ist, ist es in der Regel sicherer als eine langlebige approve-Allowance. Trotzdem können auch permit-Signaturen Ziel von Phishing sein: Eine bösartige Seite, die Sie zum "Einloggen" auffordert, kann ein permit darunter schieben. Lesen Sie, was Sie signieren.

Was das innerhalb von SSP bedeutet

SSP ist eine selbstverwahrte 2-of-2-Multisig-Wallet: Jede on-chain Transaktion wird von der SSP-Browser-Extension und der SSP-Key-Mobile-App gemeinsam signiert. Auf Ethereum und den von SSP unterstützten EVM-Netzwerken (Polygon, Base, BNB Smart Chain, Avalanche) ist dies als ERC-4337 Smart Account mit Schnorr-aggregierter Signatur implementiert — aber auf Anwendungsebene sieht eine Freigabe aus wie jede andere Transaktion.

Ein paar Dinge zu beachten:

• Eine Freigabe ist eine Transaktion, die Ihre 2-of-2 co-signieren muss. Wenn eine dApp approve anfordert, zeigt SSP sie wie jede andere Tx an. Sie sehen die Spender-Adresse und den angeforderten Betrag auf beiden Geräten, bevor Sie bestätigen.
• Einmal erteilt, braucht der Spender SSP nicht mehr, um zu handeln. Das Multisig schützt den Moment der Freigabe, nicht die dauerhafte Berechtigung danach. Wenn Sie einem bösartigen Vertrag eine unbegrenzte Allowance erteilen, wird Ihr Multisig Sie nicht vor dem späteren Drain bewahren.
• Achten Sie auf die Spender-Adresse. dApps aktualisieren ihre Router gelegentlich; passt der Spender im Approval-Bildschirm nicht zum erwarteten Vertrag, stoppen Sie und prüfen Sie.
• Über WalletConnect ausgelöste Freigaben sehen gleich aus. Egal ob die dApp Sie in der Seite oder über WalletConnect auffordert, der Ablauf und die Risiken sind identisch.

Gewohnheiten, die sich lohnen

Ein paar konkrete Praktiken halten die Freigabe-Fläche überschaubar:

• Bevorzugen Sie die kleinstmögliche Allowance. Wenn eine dApp "exakter Betrag" gegenüber "unlimited" anbietet, ist exakt die sicherere Standardwahl für Verträge, die Sie nicht regelmäßig nutzen.
• Behandeln Sie unbegrenzte Freigaben als Verpflichtungen. Reservieren Sie sie für eine kleine Menge an Verträgen, denen Sie vertrauen und die Sie oft nutzen. Alles andere: eingrenzen.
• Prüfen Sie regelmäßig. Einmal pro Quartal Ihre aktiven Freigaben pro Chain auflisten und alles widerrufen, was Sie nicht mehr nutzen. Tools wie revoke.cash machen das zur Routine.
• Seien Sie skeptisch bei unbekannten dApps. Ein neues Protokoll ohne Audit-Historie, das eine unbegrenzte Allowance verlangt, ist die riskanteste Kombination in DeFi.
• Schützen Sie die Schlüssel, die Freigaben erteilen. SSPs Multisig hebt die Hürde, aber Standardhygiene gilt weiterhin — siehe Best Practices für die Seed-Phrase.

Das mentale Modell zum Mitnehmen

Eine Token-Freigabe ist kein Klick; sie ist ein Schlüssel. Jeder bleibt im Schloss, bis Sie ihn entfernen, und jeder verleiht seinem Inhaber die Fähigkeit, Tokens zu bewegen, die Sie noch gar nicht verdient haben. Mit Sorgfalt verwendet, sind Allowances die Klempnerei, die DeFi überhaupt zum Laufen bringt. Als wegwerfbare Klicks behandelt, sind sie das langsame Anhäufen von Risiken, die Sie vergessen haben einzugehen.

Verstehen Sie die Berechtigung, die Sie erteilen, bevorzugen Sie eingegrenzte Vergaben, wo die dApp das zulässt, und beschneiden Sie Ihre dauerhaften Freigaben nach einem festen Rhythmus. Für tiefere Protokolldetails ist die ERC-20-Standard-Dokumentation auf ethereum.org die kanonische Referenz. Neu bei SSP auf Ethereum? Unser Leitfaden Ethereum in SSP deckt die Grundlagen ab.