Inside the Fastest Stellar Swap: Multi-Route Evaluation Explained

Most DEX interfaces on Stellar pick one route for your swap. They check the orderbook, maybe glance at a liquidity pool, and give you a number. Shadow Pocket does something fundamentally different — it evaluates every possible route in parallel and sends 100% of your trade through whichever one returns the most output.

The Problem with Single-Route Swaps

When you swap Asset A for Asset B on Stellar, there are multiple possible execution venues:

• The SDEX orderbook — limit orders placed by traders and market makers.
• AMM liquidity pools — constant-product pools where price is determined algorithmically.
• Cross-pair paths — routes that go A to C to B, using intermediate assets as bridges.

A single-route approach picks one and hopes it is the best. But liquidity shifts with every ledger close (roughly every 5 seconds). The orderbook might have a great price at shallow depth but fall apart for larger amounts. A pool might offer better rates for big swaps due to its continuous liquidity curve. And sometimes a cross-pair path through XLM or USDC beats both direct options.

Guessing wrong costs the user real money.

How Parallel Evaluation Works

Shadow Pocket's backend evaluates all available routes independently for every quote request. Here is the flow:

1. Discovery — the system identifies all viable routes: the direct orderbook, every relevant AMM pool, and cross-pair paths through major bridge assets.
2. Parallel simulation — each route gets simulated independently with the exact input amount. The orderbook simulation walks the book, filling orders at each price level. Pool simulations use the constant-product formula. Path simulations chain multiple operations.
3. Output comparison — each route returns a simulated output amount, accounting for slippage at the specific input size.
4. Winner selection — the route with the highest output gets selected. No splitting, no partial fills — 100% of the trade goes through the best path.

The backend always returns the orderbook result first in the response, followed by pool routes, so the frontend can display per-route liquidity information even though only the best route executes.

Why 100% to One Route (Not Split)

Split routing sounds smart in theory — send part of your trade through the orderbook and part through a pool to minimize price impact. In practice, on Stellar, it introduces complexity that rarely pays off:

• Transaction fees are negligible — there is no gas optimization reason to batch.
• Atomic execution — Stellar transactions either fully succeed or fully fail. Splitting adds operations that increase the chance of partial failure.
• Ledger timing — prices change every 5 seconds. By the time a split order executes, the optimal split ratio may have shifted.

For the vast majority of trade sizes on Stellar, sending 100% through the single best route outperforms any splitting strategy. The math is straightforward: simulate all options, pick the winner.

Ledger-Triggered Refresh via SSE

Swap quotes go stale fast. Shadow Pocket keeps them fresh using Server-Sent Events (SSE) connected to Stellar's ledger stream:

1. The frontend opens an SSE connection to the /ledgers?cursor=now endpoint.
2. Every time a new ledger closes (~5 seconds), the event fires.
3. The frontend debounces and triggers a fresh quote request.
4. The backend re-evaluates all routes with current orderbook and pool state.
5. The UI updates the displayed rate, output amount, and per-route breakdown.

This means the user always sees a quote that reflects the current ledger state — not something from 30 seconds ago that may have moved significantly.

Implementation Details

A few engineering decisions that make this work reliably:

Debounce timer management — the quote refresh debounce timer must be properly nullified in the setTimeout callback. If the timer reference is stale, the UI can get stuck showing a loading state indefinitely.

Loading state independence — the swap quote loading indicator is reset outside the abort signal check. This prevents a deadlock where an aborted request leaves the UI permanently in a loading state.

Service Worker bypass — the SSE text/event-stream content type is excluded from the Service Worker's precache logic. Without this bypass, the Service Worker would intercept the streaming connection and break real-time updates.

Independent route evaluation — the backend does not use a greedy approach (check orderbook first, then fill remainder from pools). Every route is evaluated for the full amount independently, ensuring the comparison is fair.

The Result

The user sees a swap interface that updates in real time, shows exactly which route their trade will take, and guarantees the best available rate across all execution venues on Stellar. No manual route selection, no stale quotes, no splitting guesswork.

Fast swaps are not about raw speed — they are about always having the freshest, most accurate information when you hit "Swap."