Dentro del swap mas rapido de Stellar: evaluacion multi-ruta explicada

La mayoria de las interfaces DEX en Stellar eligen una sola ruta para tu swap. Revisan el orderbook, tal vez echan un vistazo a un pool de liquidez, y te dan un numero. Shadow Pocket hace algo fundamentalmente diferente: evalua todas las rutas posibles en paralelo y envia el 100% de tu operacion a traves de la que devuelve mayor cantidad de salida.

El problema con los swaps de ruta unica

Cuando intercambias el Activo A por el Activo B en Stellar, existen multiples vias de ejecucion posibles:

• El orderbook del SDEX — ordenes limite colocadas por traders y creadores de mercado.
• Pools de liquidez AMM — pools de producto constante donde el precio se determina algoritmicamente.
• Rutas cruzadas — caminos que van de A a C a B, usando activos intermedios como puentes.

Un enfoque de ruta unica elige una y espera que sea la mejor. Pero la liquidez cambia con cada cierre de ledger (aproximadamente cada 5 segundos). El orderbook puede tener un gran precio a poca profundidad, pero desmoronarse para cantidades mayores. Un pool podria ofrecer mejores tasas para swaps grandes gracias a su curva de liquidez continua. Y a veces una ruta cruzada a traves de XLM o USDC supera ambas opciones directas.

Elegir mal le cuesta dinero real al usuario.

Como funciona la evaluacion en paralelo

El backend de Shadow Pocket evalua todas las rutas disponibles de forma independiente para cada solicitud de cotizacion. Este es el flujo:

1. Descubrimiento — el sistema identifica todas las rutas viables: el orderbook directo, cada pool AMM relevante y rutas cruzadas a traves de los principales activos puente.
2. Simulacion en paralelo — cada ruta se simula independientemente con la cantidad exacta de entrada. La simulacion del orderbook recorre el libro, llenando ordenes en cada nivel de precio. Las simulaciones de pools usan la formula de producto constante. Las simulaciones de rutas encadenan multiples operaciones.
3. Comparacion de salida — cada ruta devuelve una cantidad de salida simulada, teniendo en cuenta el slippage para el tamano de entrada especifico.
4. Seleccion del ganador — la ruta con la mayor salida es seleccionada. Sin divisiones, sin ejecuciones parciales: el 100% de la operacion pasa por la mejor ruta.

El backend siempre devuelve el resultado del orderbook primero en la respuesta, seguido por las rutas de pools, para que el frontend pueda mostrar informacion de liquidez por ruta aunque solo la mejor ruta se ejecute.

Por que el 100% a una sola ruta (sin dividir)

El enrutamiento dividido suena inteligente en teoria: enviar parte de tu operacion por el orderbook y parte por un pool para minimizar el impacto en el precio. En la practica, en Stellar, introduce complejidad que rara vez compensa:

• Las comisiones de transaccion son insignificantes — no hay razon de optimizacion de gas para agrupar.
• Ejecucion atomica — las transacciones de Stellar tienen exito completo o fallan por completo. Dividir agrega operaciones que aumentan la probabilidad de fallo parcial.
• Sincronizacion con el ledger — los precios cambian cada 5 segundos. Para cuando una orden dividida se ejecuta, la proporcion optima de division puede haber cambiado.

Para la gran mayoria de los tamanos de operacion en Stellar, enviar el 100% por la mejor ruta unica supera cualquier estrategia de division. La matematica es directa: simular todas las opciones, elegir la ganadora.

Actualizacion activada por ledger via SSE

Las cotizaciones de swap se vuelven obsoletas rapido. Shadow Pocket las mantiene frescas usando Server-Sent Events (SSE) conectados al flujo de ledgers de Stellar:

1. El frontend abre una conexion SSE al endpoint /ledgers?cursor=now.
2. Cada vez que se cierra un nuevo ledger (~5 segundos), el evento se dispara.
3. El frontend aplica debounce y lanza una nueva solicitud de cotizacion.
4. El backend re-evalua todas las rutas con el estado actual del orderbook y los pools.
5. La interfaz actualiza la tasa mostrada, la cantidad de salida y el desglose por ruta.

Esto significa que el usuario siempre ve una cotizacion que refleja el estado actual del ledger, no algo de hace 30 segundos que puede haberse movido significativamente.

Detalles de implementacion

Algunas decisiones de ingenieria que hacen que esto funcione de manera confiable:

Gestion del temporizador de debounce — el temporizador de debounce para la actualizacion de cotizaciones debe ser correctamente anulado en el callback del setTimeout. Si la referencia del temporizador esta obsoleta, la interfaz puede quedarse atascada mostrando un estado de carga indefinidamente.

Independencia del estado de carga — el indicador de carga de la cotizacion del swap se restablece fuera de la verificacion de la senal de abort. Esto previene un deadlock donde una solicitud abortada deja la interfaz permanentemente en estado de carga.

Bypass del Service Worker — el tipo de contenido text/event-stream de SSE esta excluido de la logica de precache del Service Worker. Sin este bypass, el Service Worker interceptaria la conexion de streaming y romperia las actualizaciones en tiempo real.

Evaluacion independiente de rutas — el backend no usa un enfoque greedy (revisar el orderbook primero, luego llenar el resto desde los pools). Cada ruta se evalua por el monto completo de forma independiente, asegurando que la comparacion sea justa.

El resultado

El usuario ve una interfaz de swap que se actualiza en tiempo real, muestra exactamente que ruta tomara su operacion y garantiza la mejor tasa disponible en todas las vias de ejecucion de Stellar. Sin seleccion manual de rutas, sin cotizaciones obsoletas, sin conjeturas de division.

Los swaps rapidos no se tratan de velocidad bruta: se tratan de siempre tener la informacion mas fresca y precisa cuando presionas "Swap."