Hinter dem schnellsten Stellar Swap: Multi-Route-Auswertung erklaert

Die meisten DEX-Interfaces auf Stellar waehlen eine Route fuer deinen Swap. Sie pruefen das Orderbuch, werfen vielleicht einen Blick auf einen Liquiditaetspool und geben dir eine Zahl. Shadow Pocket macht etwas grundlegend anderes -- es wertet jede moegliche Route parallel aus und sendet 100 % deines Trades ueber diejenige, die den hoechsten Output liefert.

Das Problem mit Single-Route-Swaps

Wenn du Asset A gegen Asset B auf Stellar tauschst, gibt es mehrere moegliche Ausfuehrungsorte:

• Das SDEX-Orderbuch -- Limit-Orders, die von Tradern und Market Makern platziert werden.
• AMM-Liquiditaetspools -- Constant-Product-Pools, bei denen der Preis algorithmisch bestimmt wird.
• Cross-Pair-Pfade -- Routen, die von A ueber C nach B fuehren und Zwischenwerte als Bruecken nutzen.

Ein Single-Route-Ansatz waehlt einen aus und hofft, dass er der beste ist. Aber die Liquiditaet verschiebt sich mit jedem Ledger-Close (ungefaehr alle 5 Sekunden). Das Orderbuch hat vielleicht einen guten Preis bei geringer Tiefe, bricht aber bei groesseren Betraegen zusammen. Ein Pool bietet moeglicherweise bessere Kurse fuer grosse Swaps dank seiner kontinuierlichen Liquiditaetskurve. Und manchmal schlaegt ein Cross-Pair-Pfad ueber XLM oder USDC beide direkten Optionen.

Falsch zu raten kostet den Nutzer echtes Geld.

Wie die parallele Auswertung funktioniert

Das Backend von Shadow Pocket wertet alle verfuegbaren Routen unabhaengig fuer jede Kursanfrage aus. So sieht der Ablauf aus:

1. Discovery -- das System identifiziert alle gangbaren Routen: das direkte Orderbuch, jeden relevanten AMM-Pool und Cross-Pair-Pfade ueber wichtige Bridge-Assets.
2. Parallele Simulation -- jede Route wird unabhaengig mit dem exakten Eingabebetrag simuliert. Die Orderbuch-Simulation durchlaeuft das Buch und fuellt Orders auf jeder Preisstufe. Pool-Simulationen verwenden die Constant-Product-Formel. Pfad-Simulationen verketten mehrere Operationen.
3. Output-Vergleich -- jede Route liefert einen simulierten Output-Betrag zurueck, unter Beruecksichtigung des Slippage bei der spezifischen Eingangsgroesse.
4. Gewinner-Auswahl -- die Route mit dem hoechsten Output wird ausgewaehlt. Kein Splitting, keine Teilausfuehrungen -- 100 % des Trades gehen ueber den besten Pfad.

Das Backend gibt immer zuerst das Orderbuch-Ergebnis in der Antwort zurueck, gefolgt von Pool-Routen, damit das Frontend die Liquiditaetsinformationen pro Route anzeigen kann, obwohl nur die beste Route ausgefuehrt wird.

Warum 100 % auf eine Route (kein Split)

Split-Routing klingt in der Theorie klug -- sende einen Teil deines Trades ueber das Orderbuch und einen Teil ueber einen Pool, um den Preiseinfluss zu minimieren. In der Praxis fuehrt es auf Stellar zu Komplexitaet, die sich selten auszahlt:

• Transaktionsgebuehren sind vernachlaessigbar -- es gibt keinen Gas-Optimierungsgrund zum Batchieren.
• Atomare Ausfuehrung -- Stellar-Transaktionen sind entweder vollstaendig erfolgreich oder schlagen vollstaendig fehl. Splitting fuegt Operationen hinzu, die die Chance auf Teilfehlschlaege erhoehen.
• Ledger-Timing -- Preise aendern sich alle 5 Sekunden. Bis eine Split-Order ausgefuehrt wird, hat sich das optimale Split-Verhaeltnis moeglicherweise verschoben.

Fuer die grosse Mehrheit der Handelsgroessen auf Stellar uebertrifft das Senden von 100 % ueber die einzelne beste Route jede Split-Strategie. Die Mathematik ist einfach: alle Optionen simulieren, den Gewinner waehlen.

Ledger-getriggerter Refresh via SSE

Swap-Kurse veralten schnell. Shadow Pocket haelt sie aktuell durch Server-Sent Events (SSE), die mit dem Stellar Ledger-Stream verbunden sind:

1. Das Frontend oeffnet eine SSE-Verbindung zum /ledgers?cursor=now-Endpunkt.
2. Jedes Mal, wenn ein neuer Ledger geschlossen wird (ca. 5 Sekunden), wird das Event ausgeloest.
3. Das Frontend entprellt und loest eine neue Kursanfrage aus.
4. Das Backend wertet alle Routen mit dem aktuellen Orderbuch- und Pool-Status neu aus.
5. Die Benutzeroberflaeche aktualisiert den angezeigten Kurs, den Output-Betrag und die Aufschluesselung pro Route.

Das bedeutet, dass der Nutzer immer einen Kurs sieht, der den aktuellen Ledger-Status widerspiegelt -- nicht etwas von vor 30 Sekunden, das sich moeglicherweise erheblich bewegt hat.

Implementierungsdetails

Einige Engineering-Entscheidungen, die das Ganze zuverlaessig machen:

Debounce-Timer-Management -- der Debounce-Timer fuer die Kurs-Aktualisierung muss im setTimeout-Callback korrekt auf null gesetzt werden. Wenn die Timer-Referenz veraltet ist, kann die Benutzeroberflaeche in einem Ladezustand haengen bleiben.

Unabhaengigkeit des Ladezustands -- der Swap-Quote-Ladeindikator wird ausserhalb der Abort-Signal-Pruefung zurueckgesetzt. Dies verhindert einen Deadlock, bei dem eine abgebrochene Anfrage die Benutzeroberflaeche dauerhaft im Ladezustand belassen wuerde.

Service Worker Bypass -- der SSE-Content-Type text/event-stream wird von der Precache-Logik des Service Workers ausgeschlossen. Ohne diesen Bypass wuerde der Service Worker die Streaming-Verbindung abfangen und Echtzeit-Updates unterbrechen.

Unabhaengige Routenbewertung -- das Backend verwendet keinen Greedy-Ansatz (zuerst Orderbuch pruefen, dann Rest aus Pools fuellen). Jede Route wird fuer den vollen Betrag unabhaengig bewertet, um einen fairen Vergleich zu gewaehrleisten.

Das Ergebnis

Der Nutzer sieht eine Swap-Oberflaeche, die sich in Echtzeit aktualisiert, genau zeigt, welche Route sein Trade nehmen wird, und den besten verfuegbaren Kurs ueber alle Ausfuehrungsorte auf Stellar garantiert. Keine manuelle Routenwahl, keine veralteten Kurse, kein Splitting-Ratespiel.

Schnelle Swaps handeln nicht von roher Geschwindigkeit -- sie handeln davon, immer die aktuellsten und genauesten Informationen zu haben, wenn du auf "Swap" drueckst.