top of page
ERC-3156 Flash Loans erklärt: Ablauf, Gebühren und Sicherheitsrisiken

ERC-3156 Flash Loans erklärt: Ablauf, Gebühren und Sicherheitsrisiken

vor 1 Stunde
9 Min. Lesezeit

Flash Loans gehören zu den ungewöhnlichsten Bausteinen dezentraler Finanzanwendungen. Ein Smart Contract kann für die Dauer einer einzigen Blockchain-Transaktion vorübergehend Token erhalten, damit handeln oder Sicherheiten umschichten und anschliessend die geliehene Menge samt möglicher Gebühr zurückgeben. ERC-3156 definiert dafür eine einheitliche Schnittstelle. Das ist keine gewöhnliche Kreditlinie für Privatpersonen und auch kein Weg zu risikolosen Gewinnen. Entscheidend ist die atomare Ausführung: Entweder werden sämtliche vorgesehenen Schritte erfolgreich abgeschlossen oder die Zustandsänderungen der Transaktion werden zurückgenommen. Die für den fehlgeschlagenen Versuch verbrauchte Netzwerkgebühr kann dennoch anfallen.

Was ist ERC-3156?

ERC-3156 ist ein Ethereum-Standard für Flash Loans mit einem einzelnen geliehenen Asset. Er beschreibt die Zusammenarbeit zwischen einem verleihenden Smart Contract, dem Lender, und einem empfangenden Smart Contract, dem Receiver. Die Schnittstelle regelt, wie eine verfügbare Menge abgefragt, die Gebühr ermittelt, die Auszahlung ausgelöst, der Empfänger aufgerufen und die Rückzahlung geprüft wird. Der Standard schafft Interoperabilität zwischen Implementierungen; er garantiert weder, dass eine bestimmte Plattform liquide ist, noch, dass ihr Code sicher ist. Nicht jeder Flash-Loan-Anbieter verwendet ERC-3156, und die Unterstützung muss im konkreten Protokoll überprüft werden.

Warum ein Kredit ohne klassische Sicherheit möglich ist

Ein normaler Kredit überlässt dem Schuldner Geld für eine längere Zeit. Der Kreditgeber trägt das Risiko, dass später nicht zurückgezahlt wird, und verlangt daher häufig Sicherheiten oder Bonitätsnachweise. Beim Flash Loan existiert dagegen kein offener Kredit über mehrere bestätigte Transaktionen. Die Rückzahlung ist Teil derselben atomaren Ausführung. Fehlt am Ende der erforderliche Betrag oder schlägt eine verpflichtende Prüfung fehl, wird die gesamte Transaktion zurückgesetzt. Diese technische Eigenschaft ersetzt aber keine Sicherheitsprüfung der beteiligten Verträge. Ein fehlerhaftes Protokoll kann trotz atomarer Rückzahlung geschädigt werden.

Der Ablauf in sechs Schritten

Zunächst ermittelt der aufrufende Vertrag, ob der Lender den gewünschten Token unterstützt und welche Menge verfügbar ist. Anschliessend fragt er die für diesen Betrag geltende Gebühr ab. Dann wird flashLoan mit Receiver, Token, Menge und zusätzlichen Daten aufgerufen. Der Lender überträgt die Token und ruft onFlashLoan beim Receiver auf. Der Receiver führt die beabsichtigten Operationen aus und ermöglicht die Rückzahlung von Kapital und Gebühr. Schliesslich prüft der Lender den festgelegten Rückgabewert des Callbacks und zieht die Rückzahlung ein. Scheitert eine notwendige Bedingung, wird die Transaktion zurückgesetzt. Die genaue Implementierung und mögliche zusätzliche Schutzmechanismen hängen vom jeweiligen Vertrag ab.

Die drei Funktionen des Lenders

maxFlashLoan(token) gibt an, welche Menge eines Tokens der Lender für einen Flash Loan bereitstellen kann. Für nicht unterstützte Token sieht der Standard die Rückgabe von null vor. flashFee(token, amount) liefert die Gebühr für einen konkreten Betrag und soll bei nicht unterstützten Token fehlschlagen. flashLoan(receiver, token, amount, data) startet den eigentlichen Vorgang. Diese Funktionen sind keine Preisgarantie: Liquidität und Gebühren können sich bis zur Ausführung ändern. Deshalb sollte eine Anwendung die erwarteten Bedingungen innerhalb ihrer Transaktion überprüfen, statt sich allein auf eine frühere Benutzeroberflächenanzeige zu verlassen.

Die Rolle von onFlashLoan

Der Receiver implementiert die Callback-Funktion onFlashLoan(initiator, token, amount, fee, data). Dort liegt die eigentliche Anwendungslogik, beispielsweise ein Austausch mehrerer Token oder die Umschichtung einer Kreditposition. Der initiator bezeichnet den ursprünglichen Aufrufer der Flash-Loan-Funktion; er ist nicht automatisch mit dem Receiver identisch. Nach der Arbeit muss der Receiver den festgelegten Hash keccak256 des Textes ERC3156FlashBorrower.onFlashLoan zurückgeben. Der Lender muss diesen Wert kontrollieren. Zudem muss die Rückzahlung von Betrag plus Gebühr ermöglicht werden. Das ist eine wichtige Abwehr gegen ungewollte oder falsch verarbeitete Callback-Aufrufe.

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

Relai Bitcoin kaufen – Code AUSWANDERNSCHWEIZ, Werbung

Gutscheincode: AUSWANDERNSCHWEIZ

Beispielrechnung: Wann lohnt sich ein Flash Loan?

Angenommen, ein Vertrag leiht sich 100'000 Einheiten eines Stablecoins. Eine hypothetische Gebühr von 0,09 Prozent entspräche 90 Einheiten. Der Vertrag tauscht die Token in mehreren Schritten und erhält am Ende 100'250 Einheiten desselben Stablecoins. Nach Rückzahlung von 100'090 Einheiten verbleiben rechnerisch 160 Einheiten vor Netzwerkgebühren, Preisabweichungen und sonstigen Kosten. Bei zusätzlichen Kosten von 200 Einheiten wäre das Ergebnis negativ. Alle Zahlen sind reine Rechenbeispiele und keine aktuellen Anbietergebühren oder erreichbaren Handelsrenditen. Die einfache Formel lautet: Nettoergebnis gleich realisierter Rückfluss minus Kreditbetrag minus Flash-Loan-Gebühr minus sämtliche Ausführungskosten.

Warum Gas und Slippage das Ergebnis verändern

Eine komplexe Transaktion benötigt Rechenleistung auf der Blockchain. Diese wird über Gas beziehungsweise die jeweilige Netzwerkgebühr bezahlt. Auch wenn die Handelsoperationen scheitern und die Zustandsänderungen zurückgesetzt werden, kann die verbrauchte Gebühr verloren sein. Hinzu kommt Slippage: Der tatsächlich erzielte Tauschpreis kann vom vorher berechneten Preis abweichen. Bei grossen Orders kann die eigene Transaktion den Poolpreis bewegen. Zwischen Simulation und Blockaufnahme können andere Transaktionen die Liquidität verändern. Ein scheinbarer Arbitragegewinn ist deshalb noch kein realisierter Gewinn. Technische Systeme müssen Kosten, Mindestbeträge, Ausführungsreihenfolge und Abbruchbedingungen berücksichtigen.

Typische legitime Anwendungen

Ein Anwendungsfall ist die atomare Arbitrage zwischen unterschiedlichen Liquiditätspools. Ein anderer ist die Umschuldung innerhalb dezentraler Kreditprotokolle, etwa wenn eine bestehende Position geschlossen und in einer anderen Struktur neu eröffnet wird. Auch ein Austausch hinterlegter Sicherheiten kann technisch in einer Transaktion erfolgen, sofern die beteiligten Verträge dies zulassen. Solche Prozesse setzen eine passende Integration, ausreichende Liquidität und zuverlässige Preisberechnung voraus. Sie sind nicht automatisch günstiger als eine gewöhnliche Transaktion. Bei kleinen Positionen können die technischen Kosten den Nutzen übersteigen.

Flash Loans sind keine kostenlose Geldmaschine

Die Möglichkeit, grosse Beträge kurzfristig zu bewegen, erzeugt leicht unrealistische Erwartungen. Tatsächlich konkurrieren spezialisierte Systeme um dieselben Marktineffizienzen. Sichtbare Preisunterschiede verschwinden häufig, bevor eine Transaktion bestätigt wird. Zudem können andere Akteure Transaktionen beobachten, vorziehen oder in einer anderen Reihenfolge ausführen lassen. Eine Anwendung kann trotz korrekter Rückzahlung Verluste machen. ERC-3156 ist eine technische Schnittstelle, kein Anlageprodukt und kein Renditeversprechen. Wer lediglich Kryptowährungen langfristig verwahren möchte, benötigt in der Regel keinen Flash Loan.

Welche Risiken bestehen für DeFi-Protokolle?

Flash Loans können Schwächen in anderen Protokollen ausnutzen, weil sie kurzfristig viel Kapital innerhalb einer Transaktion bereitstellen. Besonders anfällig sind Anwendungen, die einen leicht manipulierbaren Spotpreis als alleinige Bewertungsgrundlage verwenden. Ein Angreifer kann unter Umständen kurzfristig einen Poolpreis verschieben, einen davon abhängigen Vertrag aufrufen und die ursprüngliche Position wieder schliessen. Das Risiko entsteht aus der mangelhaften Konstruktion des betroffenen Protokolls, nicht aus der blossen Existenz eines Flash Loans. Robuste Preisorakel, geeignete Grenzen und unabhängige Sicherheitsprüfungen können Risiken verringern, aber nicht vollständig beseitigen.

Anzeige

Oracle-Manipulation und Liquidationen

Wenn ein Kreditprotokoll Sicherheiten zu einem manipulierten Preis bewertet, kann es falsche Kreditlimits oder Liquidationsbedingungen berechnen. Flash Loans können solche Preisbewegungen finanzieren, ohne dass der Angreifer das gesamte Kapital langfristig besitzen muss. Die kritische Frage ist, welche Daten ein Smart Contract für seine Entscheidungen verwendet und wie stark sie innerhalb einer einzigen Transaktion beeinflussbar sind. Zeitgewichtete Preise oder mehrere unabhängige Quellen können helfen, müssen jedoch auf Aktualität, Ausfälle und Manipulationskosten geprüft werden. Ein Sicherheitsmodell darf nie nur von der Höhe des geliehenen Kapitals ausgehen.

Callback-Authentifizierung und ungewollte Aufrufe

Der ERC-3156-Standard warnt ausdrücklich davor, die Argumente eines Callback-Aufrufs ungeprüft zu übernehmen. Ein Receiver muss kontrollieren, ob der aufrufende Lender vertrauenswürdig ist und ob der initiator für die konkrete Aktion autorisiert war. Auch das übergebene data-Feld kann unerwartete oder manipulierte Inhalte enthalten. Fehlen diese Prüfungen, könnte ein fremder Aufrufer interne Abläufe auslösen, die der Vertrag nicht beabsichtigt. Für Entwickler bedeutet das: Identität des Aufrufers, Token-Adresse, Betrag, Gebühr und zulässige Operationen gehören in ein explizites Bedrohungsmodell.

Token-Freigaben und Rückzahlung

Viele ERC-20-Token verwenden Allowances: Ein Vertrag gestattet einem anderen Vertrag, eine bestimmte Menge Token einzuziehen. Für den Flash Loan muss der Lender die Rückzahlung erhalten können. Eine dauerhaft unbegrenzte Freigabe kann aber zusätzliche Risiken schaffen, wenn der berechtigte Vertrag fehlerhaft oder kompromittiert ist. Die Spezifikation diskutiert deshalb ausdrücklich die Gefahr automatischer Freigaben und nicht vertrauenswürdiger Initiatoren. Entwickler sollten Freigaben auf den notwendigen Umfang beschränken, den richtigen Vertrag prüfen und unerwartete Callback-Aufrufe verhindern. Auch besondere Eigenschaften einzelner Token müssen in der Implementierung berücksichtigt werden.

Flash Minting ist nicht dasselbe wie ein gedeckter Pool

Manche Implementierungen erzeugen für die Dauer der Transaktion vorübergehend neue Einheiten eines eigenen Tokens und vernichten sie bei der Rückzahlung wieder. Dieses Flash Minting unterscheidet sich von einem Lender, der nur bereits vorhandene Poolliquidität ausleiht. Die ökonomischen Grenzen und Sicherheitsfragen können entsprechend anders aussehen. Sehr grosse temporäre Tokenmengen können fehlerhafte Berechnungen, Zinsmodelle oder Governance-Mechanismen beeinflussen. ERC-3156 beschreibt solche Gefahren in seinen Sicherheitsüberlegungen. Ob ein bestimmter Token Flash Minting unterstützt, muss anhand seines tatsächlich eingesetzten Vertrags geprüft werden.

Vergleich mit klassischen DeFi-Krediten

Ein klassischer DeFi-Kredit kann über mehrere Blöcke oder Tage offenbleiben und benötigt üblicherweise Sicherheiten sowie ein Liquidationsmodell. Ein Flash Loan muss innerhalb derselben Transaktion geschlossen werden und setzt daher keinen vergleichbaren langfristigen Kreditvertrag voraus. Dafür kann der Nutzer die Mittel nicht über Nacht halten oder ausserhalb des Smart Contracts frei ausgeben. Ein Flash Loan ist eine technische Komponente für atomare Operationen, während ein besicherter DeFi-Kredit eine längerfristige Finanzierung ermöglicht. Beide Modelle tragen Smart-Contract-, Liquiditäts- und Marktpreisrisiken, allerdings in unterschiedlicher Form.

Weiterlesen auf Auswandern Schweiz

Wie Entwickler die Sicherheit prüfen

Vor einer produktiven Integration sollten Entwickler die Originalimplementierung und die tatsächlich verwendeten Vertragsadressen kontrollieren. Tests müssen unter anderem falsche Callback-Absender, unerwartete Initiatoren, nicht unterstützte Token, veränderte Gebühren, unzureichende Rückzahlung und manipulierte Daten abdecken. Zusätzlich sind Reentrancy-Risiken, ungewöhnliches Tokenverhalten, Berechtigungen und mögliche Änderungen durch Upgrade-Verträge zu prüfen. Simulationen unter realistischen Liquiditätsbedingungen sind sinnvoll, ersetzen jedoch kein Audit. Ein Audit wiederum ist keine Garantie. Entscheidend bleibt, welche Version des Vertrags auf welcher Blockchain eingesetzt wird.

Worauf Nutzer von DeFi-Vaults achten sollten

Auch wenn Du selbst keine Flash Loans ausführst, kann ein von Dir genutzter Vault oder Kreditmarkt indirekt davon betroffen sein. Prüfe daher, welche Preisorakel verwendet werden, ob ein Protokoll grosse kurzfristige Preisbewegungen abfangen kann und wie Sicherheitsvorfälle kommuniziert werden. Besonders wichtig sind die Abhängigkeiten zu anderen Smart Contracts und Bridges. Eine hohe angezeigte Rendite entschädigt nicht automatisch für ein komplexes technisches Risiko. Bei unbekannten Projekten können fehlende Dokumentation, konzentrierte Administratorrechte und unklare Rücknahmebedingungen zusätzliche Warnzeichen sein.

Kosten und Gebühren richtig einordnen

Die tatsächlichen Kosten bestehen nicht nur aus einer möglichen Flash-Loan-Gebühr. Hinzu kommen Netzwerkgebühren, Gebühren der verwendeten DEX, Preisabweichungen und gegebenenfalls weitere Protokollkosten. Der ERC-3156-Standard legt keinen universellen festen Gebührensatz fest. Die Funktion flashFee liefert den Betrag der jeweiligen Implementierung. Daher wäre es irreführend, einen einzigen Prozentsatz als branchenweit gültig anzugeben. Vor jeder Ausführung sind die aktuellen Konditionen und die konkreten Token-Adressen zu prüfen. Selbst eine Transaktion ohne Flash-Loan-Gebühr kann wirtschaftlich unattraktiv sein.

Rechtliche und steuerliche Einordnung in der Schweiz

Die technische Bezeichnung Flash Loan sagt allein noch nichts über die steuerliche Behandlung einer konkreten Aktivität aus. Relevant können unter anderem die wirtschaftliche Ausgestaltung, die Art der Transaktionen, der Umfang einer Handelstätigkeit und die individuelle steuerliche Situation sein. In der Schweiz sollten steuerliche Fragen anhand der jeweils aktuellen Hinweise der Eidgenössischen Steuerverwaltung und gegebenenfalls der kantonalen Behörden geprüft werden. Bei gewerblichen Strukturen können zusätzliche Pflichten entstehen. Dieser Artikel ist weder eine steuerliche Einzelfallbeurteilung noch eine Empfehlung, mit fremdem Kapital zu spekulieren.

Anzeige

Regulierung und Gegenparteirisiken

Dezentrale Software bedeutet nicht automatisch, dass jeder beteiligte Dienst ausserhalb regulatorischer Anforderungen steht. Je nach Geschäftsmodell, Verwahrung, Organisation und angebotener Leistung können unterschiedliche Regeln einschlägig sein. Die FINMA veröffentlicht Informationen zu Finanzmarktregulierung und Risiken von Krypto-Dienstleistungen. Auch die technische Ausgestaltung verdient Aufmerksamkeit: Ein Protokoll kann formell dezentral wirken und trotzdem von einzelnen Upgrade-Schlüsseln, Administratoren oder externen Orakeln abhängig sein. Solche Abhängigkeiten können bei einem Fehler oder Angriff wesentlich werden.

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

Relai Bitcoin kaufen – Code AUSWANDERNSCHWEIZ, Werbung

Gutscheincode: AUSWANDERNSCHWEIZ

FAQ: Kann ich einen Flash Loan ohne eigenes Kapital nutzen?

Die Schnittstelle verlangt nicht zwingend eine klassische Besicherung für den geliehenen Betrag. Trotzdem benötigst Du eine technisch funktionsfähige Transaktion, einen geeigneten Receiver-Vertrag und normalerweise Mittel für Netzwerkgebühren. Ausserdem müssen sämtliche Operationen die Rückzahlung ermöglichen. Die Tatsache, dass kein langfristiges Pfand hinterlegt wird, macht einen Flash Loan weder einfach noch risikofrei.

FAQ: Was passiert, wenn die Rückzahlung scheitert?

Gemäss dem atomaren Ausführungsmodell werden die Zustandsänderungen der Transaktion zurückgenommen, wenn eine zwingende Rückzahlungsbedingung nicht erfüllt wird. Bereits verbrauchte Netzwerkgebühren können dennoch anfallen. Die genaue Fehlerbehandlung hängt von der Blockchain und der eingesetzten Implementierung ab. Ein fehlerhafter Receiver kann deshalb wiederholt Gebühren verbrauchen, ohne jemals einen erfolgreichen Handel auszuführen.

FAQ: Ist ERC-3156 auf jede Blockchain übertragbar?

Der Standard beschreibt Schnittstellen für entsprechende Smart Contracts im Ethereum-Ökosystem. Andere EVM-kompatible Netzwerke können ähnliche Implementierungen einsetzen. Das bedeutet jedoch nicht, dass auf jeder Chain dieselben Lender, Token, Gebühren oder Sicherheitsgarantien existieren. Vertragsadressen und Netzwerkunterstützung müssen separat geprüft werden. Ein Token mit identischem Symbol kann auf verschiedenen Netzwerken ein anderes Asset oder eine andere Vertragsadresse besitzen.

FAQ: Sind Flash Loans an DeFi-Hacks schuld?

Flash Loans können Angriffe beschleunigen oder finanzieren, sind aber nicht automatisch die zugrunde liegende Schwachstelle. Häufig ist die entscheidende Ursache eine fehlerhafte Preisannahme, unzureichende Zugriffskontrolle oder eine problematische Kombination mehrerer Protokolle. Eine sorgfältige Analyse unterscheidet daher das Finanzierungsinstrument von der ausgenutzten Sicherheitslücke. Pauschale Aussagen wie jeder Flash Loan sei ein Hack sind sachlich falsch.

Fazit

ERC-3156 standardisiert einen präzise definierten technischen Ablauf für kurzfristige, atomare Kredite. Sein Nutzen liegt in der Interoperabilität von Smart Contracts und in komplexen DeFi-Operationen, nicht in garantierten Gewinnen. Die wichtigsten Risiken liegen in fehlerhaften Implementierungen, manipulierten Preisen, unzureichend geprüften Callbacks, unpassenden Freigaben und wirtschaftlich unterschätzten Ausführungskosten. Wer einen solchen Standard verstehen will, sollte deshalb nicht nur den Ablauf der Rückzahlung kennen, sondern vor allem die Sicherheitsannahmen der beteiligten Protokolle prüfen. Dieser Beitrag dient der Information und ist keine individuelle Anlageberatung.

Quellen und weiterführende Literatur

Kommentare


bottom of page