Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.
Kurzantwort
On-Chain-Front-Running liegt vor, wenn jemand von einer ausstehenden Transaktion erfährt und eine andere Transaktion davor ausführen lässt, um einen Wert abzuschöpfen. Der Akteur kann einen profitablen Aufruf kopieren, vor einem bekannten Auftrag kaufen oder um eine knappe On-Chain-Chance konkurrieren. Front-Running ist eine Form des maximal extrahierbaren Werts (MEV), aber kein Synonym für jede MEV-Strategie.
Die Möglichkeit entsteht, weil eine eingereichte Ethereum-Transaktion normalerweise an das Netzwerk übertragen und in Transaktionspools gehalten wird, bevor ein Validator sie in einen Block aufnimmt. Searcher können ausstehende Transaktionen prüfen, Ergebnisse simulieren und eigene Transaktionen oder Bundles senden. Die endgültige Reihenfolge ergibt sich beim Blockbau; eine höhere Prioritätsgebühr kann die Aufnahme beeinflussen, garantiert aber keinen bestimmten Platz.
Für Nutzer zählt, ob eine Transaktion vor der Ausführung eine wertvolle Absicht offenlegt, ob ihre Grenzen Raum zur Abschöpfung lassen und wer die Reihenfolge beeinflussen kann. DEX-Swaps mit großzügiger Slippage, öffentliche Ansprüche mit wiederverwendbaren Geheimnissen, Liquidationen, Auktionen und begrenzte Mints können Konkurrenz anziehen.
Funktionsweise
Bei einem Sandwich-Trade sieht ein Searcher einen ausstehenden DEX-Kauf, kauft denselben Vermögenswert unmittelbar davor und verkauft ihn unmittelbar danach. Der Kauf des Nutzers treibt den Poolpreis zwischen den beiden Transaktionen des Searchers nach oben. Die Strategie gelingt nur, wenn der Mindestbetrag des Nutzers trotz der zusätzlichen Preisbewegung noch erfüllt wird und der Erlös alle Gebühren deckt.
Generalisierte Front-Runner zielen auf Aufrufe, deren Wert kopiert werden kann. Legt eine Transaktion eine Antwort oder Berechtigung offen, die nicht an den vorgesehenen Empfänger gebunden ist, kann ein anderes Konto den Aufruf nachbilden und eine frühere Ausführung anstreben. Verträge können Commit-Reveal-Verfahren und eine Bindung des Anspruchs an einen Empfänger nutzen; höhere Gebühren allein schützen offengelegte Informationen nicht.
Ethereum-Gebührenfelder wie maxPriorityFeePerGas und maxFeePerGas beeinflussen die Zahlungsbereitschaft des Absenders. Sie machen den Transaktionsinhalt nicht privat, und Builder können Bundles bewerten, statt jede Transaktion nach einem einzelnen Gebührenfeld zu sortieren. Front-Running ist daher ein Informations- und Reihenfolgeproblem, nicht nur ein Gaspreis-Wettlauf.
Beispiel
Angenommen, ein AMM-Pool enthält 100 ETH und 200,000 USDC. Ein Nutzer sendet öffentlich eine Transaktion, um für 10,000 USDC ETH mit einer Slippage-Toleranz von 5% zu kaufen. Die ausstehende Transaktion verrät Richtung, Umfang und akzeptierte Mindestausgabe.
Ein Searcher simuliert den Swap und sendet einen Kauf, der davor ausgeführt werden soll, sowie einen Verkauf für danach. Werden beide um die Nutzertransaktion herum angeordnet, erhält der Nutzer weniger ETH als ohne Sandwich, bleibt aber innerhalb der Grenze von 5%; der Searcher behält nach Gebühren die Differenz.
Das Ergebnis ist nicht garantiert. Konkurrierende Searcher, Poolgebühren, Preisänderungen, eine fehlende Aufnahme oder die Mindestmengenprüfung können die Strategie unrentabel machen oder die Abfolge scheitern lassen. Auch ein normaler Großauftrag erzeugt Preiseinfluss; deshalb müssen Transaktionsspuren und Poolzustand geprüft werden, bevor jede Slippage einem Angriff zugerechnet wird.
Risiken und Gegenmaßnahmen
Keine Einstellung beseitigt jedes Reihenfolgerisiko. Das sinnvolle Ziel ist, unnötige Informationslecks zu verringern und den akzeptierten Verlust einer Transaktion zu begrenzen.
- Eine vertretbare Mindestausgabe oder Preisgrenze anhand von Pooltiefe und Marktbedingungen setzen; Slippage nicht nur zur erzwungenen Ausführung ausweiten.
- Vor dem Signieren Preiseinfluss, Liquidität, Token-Transferregeln und Route prüfen, besonders bei großen Trades in flachen Pools.
- Geeignete, seriöse private Übermittlungs- oder MEV-Schutzdienste nutzen und dabei Builder-Abdeckung, Fehlerverhalten, Datenschutzregeln und Vertrauensannahmen prüfen.
- Beim Protokolldesign keine Geheimnisse nach dem Windhundprinzip in Transaktionsdaten ablegen; Empfängerbindung, Commit-Reveal, Batch-Auktionen oder passende Alternativen einsetzen.
Private Übermittlung kann eine Transaktion vor dem öffentlichen Pool verbergen, ist aber keine allgemeine Garantie. Nutzer vertrauen darauf, dass Dienst und beteiligte Builder die Transaktion weder verraten noch missbrauchen; ein RPC-Wechsel vor der Bestätigung kann sie öffentlich machen. Außerdem kann sie verzögert oder gar nicht aufgenommen werden.
Häufige Irrtümer
Irrtum 1: Mehr Gas verhindert Front-Running
Eine höhere Prioritätsgebühr kann die Aufnahmechance verbessern, verbirgt den Trade aber nicht. Searcher und Builder können eine wertvollere Reihenfolge oder ein Bundle einreichen; reines Gebührenbieten ist daher kein Schutz.
Irrtum 2: Jede ungünstige Ausführung ist ein Sandwich-Angriff
Große Aufträge bewegen AMM-Preise selbst, und der Markt kann sich während der Wartezeit ändern. Routinggebühren, Transfersteuern und normaler Wettbewerb können die Ausführung ebenfalls verschlechtern.
Irrtum 3: Null Slippage ist immer am sichersten
Eine extrem enge Grenze kann normale Preisbewegungen ablehnen und bei einer zurückgesetzten öffentlichen Transaktion trotzdem Gas verbrauchen. Die passende Grenze hängt von Liquidität, Handelsgröße, Dringlichkeit und maximal akzeptiertem Verlust ab.
Verwandte Themen
Quellen
- Transactions - ethereum.org (abgerufen: 2026-08-20)
- Maximal extractable value (MEV) - ethereum.org (abgerufen: 2026-08-20)
- Flashbots Protect Quick Start - Flashbots (abgerufen: 2026-08-20)