Technische Überarbeitung vom 6. September 2026. Dieser Beitrag dient der Information. Alle Zahlenbeispiele sind hypothetisch und weder aktuelle Kursangebote noch Anlageempfehlungen.
MEV bei Swaps erklärt, warum ein Tausch auf einer dezentralen Börse schlechter ausfallen kann als erwartet, obwohl die Wallet eine erfolgreiche Transaktion meldet. Nicht jede Abweichung ist jedoch ein Angriff. Liquidität, Gebühren, Marktbewegungen und die Reihenfolge der Transaktionen haben unterschiedliche Auswirkungen. Diese Unterschiede zu verstehen ist hilfreicher, als allein auf eine Schutzbezeichnung zu vertrauen.
Dieser Leitfaden behandelt vor allem Swaps und deren Ausführung auf Ethereum. Die Grundlagen des Handelsplatzes erläutert unser Beitrag zu dezentralen Kryptobörsen. Andere Netzwerke können Transaktionen anders übermitteln und ordnen. Eine RPC-Einstellung, ein Werbeversprechen oder ein auf Ethereum beobachtetes Verhalten lässt sich deshalb nicht automatisch auf jede Blockchain übertragen.
Was bedeutet MEV bei Swaps?
MEV steht für Maximal Extractable Value. Gemeint ist Wert, der durch die Aufnahme, den Ausschluss oder die Reihenfolge von Transaktionen zusätzlich zu den üblichen Blockbelohnungen und Gebühren gewonnen werden kann. Die Ethereum-Dokumentation zu MEV behandelt unter anderem Arbitrage, Liquidationen und Sandwich-Angriffe.
Der wirtschaftliche Kern: Zwei Abläufe mit ähnlichen Geschäften können den entstehenden Wert unterschiedlich verteilen. Vor einem Auftrag zu kaufen, der den Preis eines Pools bewegt, ist nicht dasselbe wie danach zu kaufen. Wer lediglich Token tauschen möchte, muss vor allem wissen, wie viel ankommt und welche Bedingungen er dafür freigegeben hat.
Ein ungünstiges Ergebnis benennt aber noch keinen Verantwortlichen. Ein anderer Swap in der Nähe der eigenen Transaktion innerhalb eines Blocks beweist allein keinen Sandwich-Angriff. Eine belastbare Untersuchung betrachtet Handelsrichtung, verwendete Pools, tatsächliche Reihenfolge, Reserveänderungen und die Verbindung zwischen den verdächtigen Vorgängen.
Wer verarbeitet die Transaktion vor ihrer Bestätigung?
Die Wallet bereitet eine Operation vor und signiert sie. Ein Übermittlungskanal leitet sie anschließend an die Infrastruktur des Netzwerks weiter. Im Ethereum-Ökosystem suchen Searcher nach Gelegenheiten, Builder können Blöcke zusammenstellen und Proposer wirken nach den Konsensregeln an deren Vorschlag mit. Diese Rollen sind nicht einfach andere Namen für die verwendete Börse und müssen nicht zu einem einzigen Unternehmen gehören.
Für Nutzer ergeben sich daraus drei praktische Fragen: Wer sieht den Auftrag vor der Bestätigung? Wer leitet ihn weiter? Welcher Weg wird verwendet, wenn der erste Versuch nicht zum Ziel führt? Der Name eines Aggregators auf dem Bildschirm beantwortet diese Fragen nicht unbedingt vollständig.
Die Unterscheidung hilft auch bei einer wartenden Transaktion. Ursachen können Gebühren, Nonce, Verfügbarkeit des Übermittlungswegs oder die Bedingungen des Auftrags sein. Die Slippage-Toleranz ohne Diagnose zu erhöhen verändert den Preisschutz, behebt aber möglicherweise nicht den Grund, aus dem die Transaktion noch nicht aufgenommen wurde.
Slippage, Preiseinfluss und Gebühren sind verschiedene Größen
Price Impact bezeichnet den Einfluss des eigenen Geschäfts auf den Preis innerhalb der verwendeten Liquidität. Ein großer Auftrag im Verhältnis zu einem Pool kann einen schlechteren Durchschnittskurs erhalten, ohne dass jemand anderes eingreift. Die Uniswap-Erklärung zum Preiseinfluss stellt diesen Zusammenhang zwischen Handelsgröße und Liquiditätstiefe in den Mittelpunkt.
Slippage beschreibt dagegen die Abweichung zwischen dem erwarteten und dem tatsächlich ausgeführten Ergebnis anhand des gewählten Bezugspunkts. Die Toleranz ist eine erlaubte Grenze, keine automatisch erhobene Gebühr. Ein großzügiger Wert erzwingt keine schlechte Ausführung, kann aber ein deutlich schlechteres Ergebnis als das ursprüngliche Angebot zulassen.
Gebühren verlangen einen eigenen Vergleich. Ethereum-Gasgebühren, Poolgebühren und mögliche Servicekosten werden nicht überall gleich dargestellt. Eine Route mit höherem Token-Ausgang kann nach zusätzlichen Kosten weniger attraktiv sein. Umgekehrt kann die Route mit der niedrigsten Gas-Schätzung einen ungünstigeren Wechselkurs bieten.
| Größe | Prüffrage | Typischer Fehler |
|---|---|---|
| Preiseinfluss | Wie groß ist der Auftrag im Verhältnis zur verfügbaren Liquidität? | Jede Abweichung einem Angreifer zuschreiben |
| Slippage-Toleranz | Welches Mindestergebnis erlaube ich? | Die Grenze für eine feste Gebühr halten |
| Gebühren | Welche Kosten enthält diese Schätzung? | Angebote mit verschiedenen Kostenannahmen vergleichen |
| Aufnahme in einen Block | Was geschieht, wenn der Auftrag wartet? | Preisgrenzen ohne Diagnose lockern |
Zahlenbeispiel: den Mindestbetrag statt nur den Prozentsatz lesen
Angenommen, eine Oberfläche schätzt einen Ausgang von 1.000 Einheiten des Ziel-Tokens. Für dieses Lehrbeispiel definieren wir ausdrücklich eine einfache Regel: Mindestbetrag gleich geschätzter Ausgang multipliziert mit eins minus Toleranz. Bei 1 Prozent ergeben sich 990, bei 5 Prozent 950 Einheiten. Das ist keine allgemeingültige Formel für jeden SDK oder Auftragstyp. Bei einer echten Transaktion zählt der tatsächlich angezeigte und signierte Mindestbetrag.
Werden 992 Einheiten geliefert, beträgt die Abweichung zur Schätzung acht Einheiten oder 0,8 Prozent. In unserem Modell werden damit beide Grenzen eingehalten. Eine Einstellung von 5 Prozent bedeutet also nicht, automatisch 50 Einheiten bezahlt zu haben. Erlaubte Verschlechterung und tatsächlich eingetretene Verschlechterung sind unterschiedliche Werte.
Sinkt der verfügbare Ausgang auf 975, wird ein Minimum von 990 nicht mehr erreicht, eines von 950 dagegen schon. Unter der Annahme eines atomaren Swaps und eines Vertrags, der den Mindestbetrag korrekt durchsetzt, dürfte der erste Auftrag zu diesem Ergebnis nicht ausgeführt werden. Das macht jedoch nicht jeden Fehlschlag kostenlos: Eine aufgenommene Transaktion, die anschließend revertiert, kann Gas verbrauchen.
Das Beispiel belegt weder einen Angriff noch den Gewinn eines Angreifers. Es trennt lediglich Schätzung, Minimum und Ergebnis. Für eine Schadensberechnung müssten zusätzlich die Ausführung ohne den vermuteten Eingriff, die Gebühren und andere relevante Transaktionen nachvollziehbar rekonstruiert werden. Die Prozentzahl in der Wallet reicht dafür nicht aus.
Für die Auswertung des Beispiels kann ein einfacher Datensatz genügen: ursprüngliche Schätzung 1.000, signiertes Minimum 950, tatsächlicher Ausgang 975. Das Geschäft liegt 25 Einheiten beziehungsweise 2,5 Prozent unter der Schätzung und zugleich 25 Einheiten über dem Minimum. Beide Aussagen sind richtig, beantworten aber verschiedene Fragen. Die erste misst die Abweichung zur Erwartung, die zweite die Einhaltung der Freigabe. Wer nur auf den Abstand zum Minimum blickt, könnte ein enttäuschendes Ergebnis als Verbesserung darstellen. Deshalb sollte jeder Vergleich seinen Bezugspunkt ausdrücklich nennen und nicht zwischen Schätzung und Mindestbetrag wechseln.
Zweites Beispiel: Preisbewegung ohne fremden Eingriff
Betrachten wir einen hypothetischen Liquiditätspool mit 100 Einheiten von Token A und 200.000 Einheiten von Token B. Wir unterstellen eine Kurve mit konstantem Produkt, keine Gebühren, keine weiteren Geschäfte und gewöhnliche Token ohne besondere Transfermechanismen. Das anfängliche Verhältnis beträgt 2.000 B je A, ist aber kein garantierter Durchschnittskurs für jede beliebige Handelsgröße.
Durch die Einzahlung einer Einheit A steigt deren Reserve auf 101. Damit das ursprüngliche Produkt von 20.000.000 konstant bleibt, sinkt die B-Reserve auf ungefähr 198.019,802. Der Swap liefert daher rund 1.980,198 B statt 2.000. Die Abweichung von etwa 0,99 Prozent zum anfänglichen Verhältnis entsteht in diesem Modell durch die Kurve und nicht durch einen Sandwich-Angriff.
Das ist eine vereinfachte Rechnung und kein aktuelles Uniswap-Angebot. Reale Pools können Gebühren verlangen, konzentrierte Liquidität oder andere Preisfunktionen nutzen und zwischen Angebot und Ausführung weitere Transaktionen erhalten. Die Dokumentation zur Preisberechnung in Uniswap v2 unterscheidet die Ausgangsberechnung von den Sicherheitsprüfungen, die vor einer Annahme eines fairen Poolpreises nötig sind.
Die praktische Aussage: Eine niedrigere Toleranz entfernt keinen Preiseinfluss, der bereits im ursprünglichen Angebot enthalten ist. Zunächst muss dessen Qualität beurteilt werden, danach die zulässige zusätzliche Abweichung. Wer beide Schritte verwechselt, kann einen Auftrag für vorsichtig halten, obwohl schon seine Ausgangsbedingungen ungünstig sind.
Wie ein Sandwich die Ausführung beeinflusst
Bei einem typischen Sandwich setzt ein Akteur ein Geschäft vor den anvisierten Swap und ein weiteres danach. Er versucht, von der dadurch entstehenden Preisbewegung in der Liquidität zu profitieren. Der Nutzer kann weniger erhalten als zunächst erwartet, obwohl der freigegebene Mindestbetrag eingehalten wird. Wie viel Spielraum besteht, hängt von den konkreten Bedingungen ab, nicht nur vom nominellen Auftragswert.
Geringe Liquidität und großzügige Preisgrenzen können die Exposition erhöhen. Viel Liquidität ist aber keine Versicherung, und eine enge Grenze löst nicht jedes Problem. Strengere Bedingungen können auch mehr nicht ausgeführte Versuche verursachen, wenn sich der Markt bewegt. Schutz, Route und Kosten weiterer Versuche müssen deshalb zusammen betrachtet werden.
Für eine spätere Prüfung sollten Angebot und Zeitpunkt, signierter Mindestbetrag sowie Transaktionshash aufbewahrt werden. Verglichen wird mit diesem damaligen Angebot, nicht mit einem viel später abgelesenen Kurs. Fehlt der frühere Zustand des Pools, sollte eine Schadensschätzung diese Einschränkung benennen, statt eine scheinbar exakte Zahl zu liefern.
Arbitrage und Liquidationen sind nicht dasselbe wie Sandwiching
Arbitrage nutzt Preisunterschiede zwischen Märkten. Eine Liquidation kann die Regeln eines Kreditprotokolls umsetzen, wenn Sicherheiten nicht ausreichen. Diese Vorgänge unterscheiden sich von der gezielten Verschlechterung eines Swaps zwischen zwei fremden Geschäften. Ihre gemeinsame Einordnung unter MEV bedeutet nicht, dass sie dieselben Folgen für jeden Nutzer haben.
Entscheidend ist nicht allein, ob jemand Gewinn erzielt hat, sondern wie und zu wessen Lasten. Ein beobachteter Gewinn beweist nicht automatisch einen gleich hohen Verlust einer bestimmten Wallet. Auch zusammengefasste MEV-Zahlen benötigen eine klare Methodik, bevor daraus ein individueller Schaden abgeleitet werden kann.
Privates Routing verändert Sichtbarkeit, nicht den Vertrauensbedarf
Ein privater Übermittlungskanal kann die übliche Verteilung im öffentlichen Mempool vermeiden. Dadurch ändert sich, wer die Transaktion vor ihrer Aufnahme sehen kann. Es bedeutet jedoch nicht, dass niemand Zugriff auf die Informationen hat. Der Dienst und die zugelassenen Empfänger gehören zu den Beteiligten, denen vertraut werden muss.
Der Schnellstart von Flashbots Protect benennt ausdrücklich das Vertrauen in Builder, Transaktionen nicht vorwegzunehmen oder an Dritte weiterzugeben. Er warnt außerdem davor, dass ein RPC-Wechsel in MetaMask vor Bestätigung eine erneute Übermittlung an den öffentlichen Mempool auslösen kann. Das betrifft die Ausführung und ist nicht nur eine Frage der Benutzeroberfläche.
Vor der Nutzung sind unterstütztes Netzwerk, Weiterleitung, Empfänger und Behandlung wartender Anfragen zu prüfen. Endpunkte sollten mit offizieller Dokumentation abgeglichen werden, nicht mit privaten Nachrichten oder Werbeanzeigen. Die Einrichtung eines Übermittlungswegs verlangt nicht, einem Anbieter die Wiederherstellungsphrase der Wallet zu geben.
Einstellungen, Erstattungen und Ausweichrouten prüfen
Die für diese Überarbeitung gelesene Protect-Dokumentation zu Einstellungen unterscheidet Standardkonfiguration, Fast-Modus und Optionen zur Informationsweitergabe. Zusätzliche Empfänger können die Aufnahme begünstigen, erweitern aber den Kreis der Vertrauenspartner. Verschiedene Freigaben sind keine identischen Zusagen zur Vertraulichkeit.
Die Dokumentation erlaubt ebenfalls Einstellungen für revertierende Transaktionen und die Zahl der Blöcke, über die eine Aufnahme versucht wird. Ein Standardverhalten darf deshalb nicht als bedingungsloses Versprechen für jede Konfiguration dargestellt werden. Mögliche Erstattungen sind auch keine sicheren Erträge und kein Beleg, dass der zugrunde liegende Swap günstig war.
Vor einem Vergleich sollten die Bedingungen festgehalten werden. Ändert eine Wallet oder ein Dienst automatisch den Modus, ist zu prüfen, ob sich auch die Sichtbarkeit der Transaktion verändert. Der Produktname kann gleich bleiben, während Übermittlungsweg oder Empfängerkreis tatsächlich andere sind.
Intents und Auktionen: Die unterschriebenen Bedingungen bleiben wichtig
Ein Intent beschreibt Handelsbedingungen, statt jeden Ausführungsschritt unmittelbar vorzugeben. Die CoW-Dokumentation zu Intents erläutert einen signierten Auftrag als Bündel von Bedingungen, das von einer direkt ausführbaren Nutzertransaktion zu unterscheiden ist.
Diese Trennung ermöglicht spezialisierten Teilnehmern, eine passende Ausführung zu suchen. Die Signatur wird dadurch nicht bedeutungslos: Token, Beträge, Empfänger, Ablaufzeit und Berechtigungen müssen stimmen. Eine Nachrichtenunterschrift ohne sofortige Gaszahlung beweist nicht, dass eine Aktion keine finanziellen Folgen haben kann.
Produkte mit den Bezeichnungen Intent oder Auktion können unterschiedlichen Regeln folgen. Zu prüfen sind das konkrete Stornierungsverfahren und, falls unterstützt, die Regeln für Teilausführungen. Ein abgelaufener Auftrag ist nicht automatisch dasselbe wie ein teilweise ausgeführter. Eine technische Kategorie garantiert nicht bei jedem Anbieter und jedem Handel einen besseren Preis.
Große Aufträge aufteilen: Abwägung statt allgemeiner Schutzregel
Die frühere Fassung empfahl die Aufteilung großer Aufträge als allgemeine Gegenmaßnahme. Das war zu pauschal: Mehrere Teile garantieren weder weniger MEV noch ein besseres Gesamtergebnis. Bleibt die Liquidität unverändert und folgen die Geschäfte derselben Kurve, erzeugen zusätzliche Klicks keine neue Markttiefe.
Ein reines Kostenbeispiel: Vier Transaktionen mit hypothetisch jeweils drei Euro Netzwerkgebühr kosten zwölf Euro. Eine einzige Transaktion zum gleichen Stückpreis kostet drei Euro. Die zusätzlichen neun Euro müssten durch einen tatsächlichen Ausführungsvorteil gerechtfertigt sein. Diese Beträge dienen nur der Veranschaulichung und sind keine Schätzung aktueller Ethereum-Gebühren.
Eine zeitliche Verteilung setzt den noch offenen Betrag außerdem Marktbewegungen zwischen den Teilaufträgen aus. Ein sinnvoller Vergleich umfasst den gesamten Betrag, kumulierte Kosten und verstrichene Zeit. Nur den besten Teilauftrag zu zeigen wählt ein günstiges Ergebnis aus und blendet die übrigen Ausführungen aus.
Checkliste für die konkrete Transaktion vor der Signatur
- Netzwerk und Token-Adressen prüfen. Ähnliche Kürzel stehen nicht notwendigerweise für denselben Vermögenswert.
- Empfänger der Berechtigung und freigegebenen Betrag kontrollieren. Keine unverständlichen Zugriffsrechte erteilen.
- Eingangsbetrag, geschätzten Ausgang und tatsächliches Minimum lesen, nicht nur den Toleranzwert.
- Netzwerkgebühren, Poolgebühren und mögliche Servicekosten voneinander trennen.
- Übermittlungsweg und Schutzbedingungen prüfen, insbesondere bei einem wartenden Auftrag.
- Ablaufzeit, Teilausführungen und Stornierung kontrollieren, soweit das Produkt diese Funktionen vorsieht.
- Die letzte Bestätigung erneut lesen: Ein aktualisiertes Angebot kann Route und erwarteten Ausgang verändern.
Diese Liste zertifiziert weder Token noch Vertrag als sicher. Sie macht die Bedingungen eines einzelnen Vorgangs sichtbar. Ein angesehener Router macht nicht jeden darüber gehandelten Token zu einer sicheren Anlage, und eine Preisgrenze schützt nicht vor jeder schädlichen Berechtigung.
Für einen fairen Angebotsvergleich sind derselbe Eingangsbetrag, Ziel-Token, Zeitpunkt und dieselben Gebührenannahmen erforderlich. Ein mehrere Minuten altes Angebot ist kein verlässlicher Maßstab, wenn sich der Markt inzwischen bewegt hat. Geschätzte Kosten müssen von tatsächlich bezahlten getrennt werden. Ebenso ist festzuhalten, ob Tokenbeträge vor oder nach Servicegebühren angegeben sind. Das macht den Vergleich nachvollziehbar, sagt aber nicht voraus, welche Route beim nächsten Versuch gewinnt.
Was nach dem Swap zu kontrollieren ist
Zunächst sind Transaktionsstatus und tatsächlich erhaltene Mengen zu prüfen. Technischer Erfolg bedeutet, dass die Ausführung den maßgeblichen Regeln entsprach, nicht dass weltweit der bestmögliche Preis erzielt wurde. Die aufbewahrten Signaturdaten helfen, das Ergebnis mit den damals akzeptierten Bedingungen zu vergleichen.
Wartet der Vorgang noch, sollte er nicht blind wiederholt werden. Eine nicht aufgenommene Transaktion, ein abgelaufener Auftrag, ein Revert und eine verzögerte Anzeige sind verschiedene Zustände. Die Hinweise der verwendeten Wallet und Route sind maßgeblich: Ein erneuter Versuch oder Ersatz kann Kosten und Sichtbarkeit verändern.
Bei Verdacht auf einen Sandwich-Angriff sollten Hashes, Zeitpunkte und ursprüngliches Angebot gesammelt werden, bevor eine Schlussfolgerung gezogen wird. Wiederherstellungsphrase, Schlüssel oder sensible Exporte gehören nicht in öffentliche Hilfegesuche. Öffentliche Transaktionsdaten und die Bedingungen des Swaps sind nützliche Belege; die Kontrolle über die Wallet wird für eine gewöhnliche technische Untersuchung nicht benötigt.
Häufige Fragen zum Schutz vor MEV
Löst eine Toleranz von null das Problem?
Nein. Sie kann bestimmte Ausführungen unter dem Angebot verhindern, aber bei geänderten Bedingungen auch den Handel selbst. Ein ungünstiger Ausgangspreis wird dadurch nicht besser, Gebühren verschwinden nicht und Vertragsrisiken bleiben bestehen.
Beweist ein fehlgeschlagener Swap einen Angriff?
Nein. Verschiedene technische Bedingungen können einen Fehlschlag auslösen. Für eine Zuordnung braucht es Belege. Eine allgemeine Wallet-Meldung zusammen mit einem ungünstigen Kursverlauf reicht allein nicht aus.
Macht private Übermittlung das Geschäft anonym?
Eine begrenzte Verteilung vor der Aufnahme ist keine Anonymität. Sie entfernt keine später veröffentlichten On-Chain-Daten und bedeutet nicht, dass der Anbieter keine Informationen erhält. Die Sichtbarkeitsregeln des konkreten Dienstes sind zu prüfen.
Welche Route ist bei jedem Swap am besten?
Eine allgemeingültige Antwort gibt es nicht. Betrag, Liquidität, Kosten, Dringlichkeit und Produktbedingungen verändern den Vergleich. Eine nachvollziehbare Entscheidung nennt diese Annahmen, statt sie durch das Etikett MEV-Schutz zu ersetzen.
Fazit: Ausführung prüfen statt absolute Sicherheit suchen
MEV bei Swaps zu verstehen heißt, einen Tausch als Bündel von Bedingungen zu lesen: Angebot, Mindestbetrag, Route, Berechtigungen und Kosten. Gute Prüfungen halten diese Elemente auseinander und ermöglichen den Vergleich zwischen der Signatur und dem tatsächlichen Ergebnis.
Schutzmaßnahmen können bestimmte Expositionen verringern, behalten aber Grenzen und Abhängigkeiten. Vor der Unterschrift sollten Mindestbetrag und Übermittlungsweg geprüft werden; anschließend sollte das Ergebnis für einen konsistenten Vergleich aufbewahrt werden. Das Ziel ist kein Versprechen völliger Risikofreiheit, sondern Klarheit über das verbleibende Risiko.
