Flash Swap — Token zuerst erhalten, dann bezahlen

Ein Flash Swap ist ein von Uniswap eingeführtes Feature, das es ermöglicht, Token aus einem Liquiditätspool zu entnehmen, bevor die Bezahlung erfolgt. Im Gegensatz zu einem normalen Swap, bei dem du zuerst bezahlst und dann erhältst, funktioniert ein Flash Swap "optimistisch": Du bekommst die Token zuerst, führst deine Strategie aus und bezahlst am Ende. Wie bei einem Flash Loan gilt das Atomiziätsprinzip: Wenn die Bezahlung am Ende der Transaktion ausbleibt, wird alles rückgängig gemacht. Flash Swaps sind weniger bekannt als Flash Loans, werden aber von MEV-Bots und professionellen Arbitrageuren intensiv genutzt.

Der Callback-Mechanismus: Token zuerst, Bezahlung danach

Uniswap V2 führte Flash Swaps im Mai 2020 ein. Der technische Ablauf: Dein Smart Contract ruft die swap()-Funktion auf einem Uniswap-Pair auf und fordert Token an. Uniswap sendet die Token sofort an deinen Contract. Dann ruft Uniswap eine Callback-Funktion (uniswapV2Call()) auf deinem Contract auf, in der du deine Logik ausführst, etwa Arbitrage auf einer anderen DEX. Am Ende prüft Uniswap die Pool-Invariante: Das Produkt der Reserven muss mindestens so groß sein wie vor dem Swap (x * y >= k). Ist es das nicht, wird die gesamte Transaktion verworfen.

Der entscheidende Unterschied zu einem Flash Loan: Bei Uniswap V2 kannst du die Bezahlung mit dem anderen Token des Paares leisten. Du leihst dir ETH und bezahlst mit USDC, oder du leihst dir ETH und gibst ETH plus Gebühr zurück. Diese Flexibilität macht Flash Swaps besonders nützlich für Cross-DEX-Arbitrage.

Uniswap V2 vs. V3: Unterschiede bei Flash-Funktionen

Feature	Uniswap V2 (Flash Swap)	Uniswap V3 (Flash)
Callback-Funktion	uniswapV2Call()	uniswapV3FlashCallback()
Leihbare Token	Einer der beiden Pool-Token	Beide Pool-Token gleichzeitig
Gebühr	0,3 %	Pool-abhängig (0,01 %, 0,05 %, 0,3 % oder 1 %)
Bezahlung	Mit dem anderen Token ODER dem gleichen + Fee	Gleicher Token + Fee (weniger flexibel)

Uniswap V3 hat die Flash-Funktion stärker einem klassischen Flash Loan angenähert: Du leihst und gibst den gleichen Token plus Gebühr zurück. Die V2-Variante war flexibler, weil die Bezahlung mit dem Gegen-Token möglich war. Uniswap V4 (2024/2025) erweitert die Möglichkeiten durch das Hooks-System, das Custom-Logik vor und nach Swaps erlaubt.

Anwendungsfälle: Wofür Flash Swaps genutzt werden

Der häufigste Einsatz ist kapitallose Arbitrage: Du holst dir per Flash Swap Token A von Uniswap, verkaufst sie teurer auf SushiSwap, und bezahlst Uniswap mit dem Erlös, die Differenz ist dein Gewinn, ohne je eigenes Kapital eingesetzt zu haben. Just-in-Time (JIT) Liquidity ist ein weiterer Anwendungsfall: Kurz vor einem großen Trade Liquidität bereitstellen, Handelsgebühren kassieren und die Liquidität sofort wieder abziehen. Flash Swaps werden auch für Liquidierungen in Lending-Protokollen genutzt: Schulden-Token per Flash Swap leihen, die unterbesicherte Position liquidieren, die Sicherheiten erhalten und damit den Flash Swap bezahlen.

Flash Swap vs. Flash Loan: Wann was?

In der Praxis nutzen professionelle Akteure oft beides in Kombination. Geschätzt laufen 70 bis 80 % aller Flash-Operationen über Aave (Flash Loans), etwa 15 bis 20 % über Uniswap Flash Swaps. Flash Loans bieten mehr Flexibilität (jeder Token aus dem Lending Pool), niedrigere Gebühren (0 bis 0,05 %) und sind durch den EIP-3156-Standard besser standardisiert. Flash Swaps punkten bei DEX-Arbitrage, weil die Token direkt aus dem AMM-Pool kommen und mit dem Gegen-Token bezahlt werden können. Viele MEV-Bots kombinieren: Flash Loan von Aave für das Kapital, Swaps auf mehreren DEXs für die Strategie.

Sicherheitsrisiken bei Flash Swaps

Der Callback-Mechanismus öffnet spezifische Angriffsvektoren. Das größte Risiko ist Reentrancy: Ein bösartiger Contract könnte die Callback-Funktion nutzen, um den Pool mehrfach aufzurufen, bevor die ursprüngliche Transaktion abgeschlossen ist. Deshalb müssen Smart Contracts, die Flash Swaps implementieren, Reentrancy Guards verwenden. Ebenso wichtig ist die Callback-Validierung: Der empfangende Contract muss prüfen, dass der Callback tatsächlich vom legitimen Uniswap-Pair kommt (msg.sender == pair address). Ohne diese Prüfung könnte jeder beliebige Contract die Callback-Funktion triggern. Zusätzlich sind Flash-Swap-Transaktionen im Mempool sichtbar und können von MEV-Bots per Front-Running abgefangen werden.