Zum Inhalt springen
Financial Context Wiki

Swap-Frist, Slippage und Calldata: Was vor dem Signieren zu prüfen ist

Erfahren Sie, wie Sie einen DEX-Swap-Aufruf dekodieren und Router, Funktion, Betragsgrenzen, Route, Empfänger und Frist vor dem Signieren prüfen.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Kurzantwort

Prüfen Sie vor der Signatur eines DEX-Swaps die Chain, den Zielvertrag, die dekodierte Funktion, Token-Adressen, Eingabe- oder Ausgabegrenze, Route, Empfänger und jede Frist. Der in einer Oberfläche angezeigte Slippage-Prozentsatz ist selbst keine On-Chain-Anweisung. Er dient meist zur Berechnung einer Grenze wie amountOutMin oder amountOutMinimum bei einem Exact-Input-Swap beziehungsweise amountInMax oder amountInMaximum bei einem Exact-Output-Swap.

Eine Frist ist eine zeitliche Schranke, keine Preisgarantie. Prüft der Router die Frist und wird die Transaktion danach ausgeführt, sollte der Aufruf revertieren. Vor der Frist kann sie dennoch zu jedem durch die Betragsgrenze erlaubten Preis ausgeführt werden. Eine lange Frist hält die Autorisierung länger nutzbar; eine sehr kurze erhöht das Risiko, dass sie vor der Aufnahme in einen Block abläuft.

Calldata ist nicht selbstbeschreibend. Dekodieren Sie sie mit der verifizierten ABI des exakten Vertrags auf der gewählten Chain, einschließlich verschachtelter Multicalls oder Universal-Router-Befehle. Zeigt die Wallet keine verlässlich dekodierten Felder, leiten Sie deren Bedeutung nicht allein aus Byte-Positionen oder einer Funktionsnamen-Datenbank ab.

Funktionsweise

Den tatsächlichen Aufruf dekodieren

Nach der Solidity-ABI bilden die ersten 4 bytes der Calldata den Funktionsselektor; die kodierten Argumente beginnen beim fünften Byte. Selektoren können kollidieren oder falsch bezeichnet sein, daher ist der Abgleich mit der ABI des verifizierten Zielvertrags nötig. Ein Proxy, Aggregator oder Router kann den Swap in multicall, execute oder eine andere Funktion einbetten. Dekodieren Sie jede verschachtelte Nutzlast, die Token übertragen oder den endgültigen Empfänger ändern kann.

Bei einem Exact-Input-Swap ist die Eingabe fest und das Schutzfeld legt die mindestens akzeptable Ausgabe fest. Bei einem Exact-Output-Swap ist die gewünschte Ausgabe fest und das Schutzfeld begrenzt die Eingabe. Eine Grenze von null oder eine unerwartet großzügige Grenze kann wirksamen Preisschutz beseitigen. Token-Dezimalstellen sind entscheidend: Ordnen Sie jede Token-Adresse den korrekten Dezimalstellen und dem Symbol zu, bevor Sie Rohwerte vergleichen.

Route, Empfänger und value prüfen

Bestätigen Sie, dass die Route mit dem ausgegebenen Token beginnt und mit dem erwarteten Token endet. Untersuchen Sie Zwischentoken, Pool-Gebühren sowie Befehle zum Wrappen, Entwrappen, Abschöpfen oder Übertragen von Guthaben. Empfänger sollte die vorgesehene Wallet oder ein Vertrag mit verstandenem Verhalten sein. Prüfen Sie auch den nativen value der Transaktion; er kann von den in Calldata kodierten ERC-20-Beträgen getrennt sein.

Die Frist finden

Die Position der Frist hängt von der Router-Version ab. Router-Funktionen nach Art von Uniswap V2 enthalten ein deadline-Argument, ebenso die ursprünglichen Uniswap-V3-ISwapRouter-Strukturen. Universal Router stellt sowohl execute(commands, inputs, deadline) als auch eine Überladung ohne Frist bereit. Nehmen Sie daher weder an, dass jeder Swap eine Frist hat, noch dass sie immer in denselben verschachtelten Parametern steht.

Üblicherweise wird die Frist mit dem bei der Ausführung verwendeten Blockzeitstempel verglichen. Sie storniert keine ausstehende Transaktion, garantiert keine schnelle Aufnahme und schützt nicht vor einem nachteiligen Preis innerhalb der Betragsgrenze. Zur Stornierung muss der Absender den Transaktionsersatz der Chain und Wallet nutzen; nach Aufnahme der ursprünglichen Transaktion ist ein Ersatz nicht garantiert.

Durchgerechnetes Beispiel

Ein Angebot erwartet bei einem Exact-Input-Swap 10,000 USDC, und der Nutzer wählt 1% Slippage. Bereits im Angebot enthaltene Gebühren ausgenommen, beträgt die erwartete Mindestausgabe 9,900 USDC. Da USDC 6 decimals verwendet, lautet der rohe Integerwert dieser Grenze 9900000000.

Der dekodierte Aufruf enthält jedoch amountOutMinimum = 9000000000, also 9,000 USDC. Damit sind bis zu 10% weniger als das Angebot erlaubt, nicht 1%. Außerdem ist der Empfänger unbekannt und die Frist liegt viele Stunden entfernt. Jede einzelne Abweichung genügt, um die Anfrage abzulehnen und über eine vertrauenswürdige Oberfläche neu aufzubauen. Simulieren Sie danach exakt die unsignierte Transaktion gegen einen aktuellen Zustand und prüfen Sie die dekodierte Nutzlast vor der Signatur erneut.

Prüfliste und Risiken

  • Gleichen Sie die gewählte Chain und die Router- oder Proxy-Adresse mit den offiziellen Deployment-Daten des Protokolls ab.
  • Dekodieren Sie mit der ABI des verifizierten Vertrags; entfalten Sie verschachtelte Aufrufe und Router-Befehle, statt nur die äußere Funktion zu prüfen.
  • Prüfen Sie Token-Adressen, Richtung, Dezimalstellen, festen Betrag, Schutzgrenze, Route, Gebührenstufen, Empfänger und nativen value.
  • Wandeln Sie die Frist in eine absolute Uhrzeit um und beurteilen Sie, ob das verbleibende Zeitfenster beabsichtigt ist. Eine fehlende Frist ist eine gesondert zu prüfende Designentscheidung.
  • Simulieren Sie die exakte Transaktion von der signierenden Adresse gegen einen aktuellen Zustand. Eine erfolgreiche Simulation ist nur ein Beleg für diesen Zustand, keine Garantie für Aufnahme oder endgültige Ausführung.
  • Prüfen Sie Freigaben oder Permit2-Berechtigungen separat. Gute Swap-Grenzen machen eine unbegrenzte oder bösartige Token-Autorisierung nicht sicher.
  • Enge Grenzen können bei normalen Preisbewegungen revertieren; weite Grenzen erhöhen Ausführungspreis- und Sandwich-Risiko. Eine revertierte On-Chain-Transaktion kann weiterhin Gas verbrauchen.

Häufige Irrtümer

Mythos: Der angezeigte Slippage-Prozentsatz wird signiert

Die signierte Nutzlast enthält gewöhnlich daraus abgeleitete Betragsgrenzen. Prüfen Sie tatsächliche Integerwerte und Token-Dezimalstellen; eine korrekt wirkende Anzeige beweist nicht, dass die Calldata dieselbe Toleranz nutzt.

Mythos: Jeder Swap nutzt amountOutMin und deadline

Bezeichnungen und Positionen unterscheiden sich je nach Router und Funktion. Exact-Output-Swaps schützen die Eingabeseite; manche Einstiegspunkte lassen die Frist weg oder platzieren sie im äußeren Aufruf.

Mythos: Eine Frist verhindert einen schlechten Preis

Sie begrenzt nur den Ausführungszeitraum, wenn der aufgerufene Code sie durchsetzt. Der Preisschutz kommt von der Betragsgrenze, die weiterhin jede Ausführung innerhalb der Grenze erlaubt.

Mythos: Die äußere Funktion zu dekodieren reicht aus

Aggregatoren und Universal Router können mehrere Aufrufe, Token-Genehmigungen, Transfers und Aufräumbefehle enthalten. Der sicherheitsrelevante Empfänger oder Betrag kann in einer verschachtelten Nutzlast liegen.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...