Skip to main content
Esta página fue traducida automáticamente por IA. La versión en inglés es la fuente autorizada.Ver versión en inglés →
La función de un agregador es ofrecer al usuario el mejor precio posible en muchos pools, posiblemente dividiendo una única entrada en múltiples rutas de pool, y ejecutarlo de forma atómica. Esta página documenta las partes específicas de Raydium en esa tarea: descubrimiento, cotización y ensamblaje de transacciones.

Descubrimiento

Inventario de pools

Necesitas la lista completa de pools activos de Raydium para cada producto. Tres opciones:
  1. API REST (más simple): GET https://api-v3.raydium.io/pools/info/list?poolType=all&pageSize=1000&page=1 devuelve pools en lotes de 1000. Pagina hasta obtenerlos todos. Cachea durante 1–5 minutos.
  2. Escaneo en cadena: getProgramAccounts en los IDs de programa CPMM, CLMM y AMM v4, filtrado por el discriminador de cuenta de estado. Produce ~cada pool activo con ~10s de tiempo de RPC. Útil cuando la API está caída o limitada por velocidad.
  3. Híbrido: usa la API como fuente principal; ejecuta un escaneo en cadena diario como verificación de cordura. El equipo se compromete a mantener la API completa, pero los pools creados mediante CPI directo (sin interfaz) ocasionalmente pueden retrasarse.

Búsqueda de pares de mint

Para un par específico (mintA, mintB), usa GET /pools/info/mint?mint1=...&mint2=...&poolType=all&sort=liquidity. Devuelve cada pool en cualquier nivel de comisión y tipo de producto. Hasta ~10 resultados por par es común en mints con mucho tráfico; ordena por TVL y toma los principales para enrutamiento.

Cotización

Las matemáticas de cotización difieren por producto. Usa las funciones de matemática pura del SDK para no reimplementar:
Los tres productos no comparten una firma. computeAmountOut existe solo en raydium.liquidity (AMM v4) y como PoolUtils.computeAmountOut(Format) para CLMM; el equivalente de CPMM se llama computeSwapAmount y toma parámetros diferentes. Escribe las tres llamadas explícitamente en lugar de parametrizar sobre el producto.
Para comparación de agregador usa amountOut (pre-slippage) de cada uno.

Frescura del caché

El estado del pool se vuelve obsoleto rápidamente. Objetivos de frescura recomendados: Para un agregador que toma cotizaciones con latencia interactiva, suscríbete a actualizaciones de cuenta de WebSocket (accountSubscribe) en cada estado de pool relevante. Eso invierte el modelo de polling a push.

Ajustes de Token-2022

Si algún mint en la ruta tiene una comisión de transferencia de Token-2022, las matemáticas de cotización deben ajustar entradas y salidas según algorithms/token-2022-transfer-fees. El SDK maneja esto si poolInfo.mintA.extensions.transferFeeConfig está poblado. Confirma mirando el campo .extensions antes de confiar en la cotización.

Enrutamiento

Rutas de un solo pool

La mayoría de rutas son de un solo pool. Elige el pool cuyo amountOut sea más alto. Si varios están cerca, desempata por nivel de comisión (menor es mejor), luego por TVL (más es más seguro).

Enrutamiento dividido

Para trades grandes donde un solo pool tiene >5% de impacto de precio, divide entre pools. Un algoritmo codicioso simple:
Esto produce un vector de enrutamiento [(pool_A, 0.6), (pool_B, 0.3), (pool_C, 0.1)] que minimiza el impacto agregado. Una solución de optimización convexa adecuada (p. ej., igualar precios marginales entre pools) está dentro del ~1% del resultado codicioso en la práctica.

Rutas multi-salto

USDC → RAY → SOL a través de dos pools separados es común cuando ningún pool directo USDC-SOL da una buena cotización (raro). Aplica límites de slippage por salto; cada salto impone su propio minAmountOut. Ver algorithms/slippage-and-price-impact. Multi-salto en el mismo pool (p. ej., dos saltos CLMM en SOL-USDC) siempre es subóptimo vs un solo salto — no generes tales rutas.

Ensamblaje de transacciones

Un solo salto, un solo pool

Para un solo pool, llama al constructor de swap del tipo de pool — raydium.liquidity.swap, raydium.cpmm.swap o raydium.clmm.swap. raydium.tradeV2.swap es el ejecutor de rutas multi-salto y toma una forma completamente diferente ({ swapInfo, swapPoolKeys, routeProgram, ownerInfo, txVersion }); no hay raydium.trade.

Dividido y multi-salto

Compone ATAs + instrucciones manualmente. Patrón:
Todo dentro de una transacción para atomicidad. Para una división de 3 pools en V0 con tablas de búsqueda de direcciones, esto típicamente cabe en ~1100 bytes. Para 4+ pools, el límite de tamaño de transacción fuerza multi-tx o consolidación en un mint hub.

Atomicidad

Los agregadores deben garantizar atomicidad: o la ruta completa se ejecuta o ninguna. Las instrucciones de swap de Raydium revierten en ExceededSlippage, así que una ruta multi-pool donde un salto falla causa que toda la transacción revierta. Gratis. La única excepción: si tu ruta va a través de Raydium + un DEX de terceros, asegúrate de que ese DEX también tenga un modelo de revert-on-slippage. Algunos programas ignoran límites de slippage (raro).

Trampas

1. Cotizaciones obsoletas

Entre que el usuario ve “Recibirás 125.43 RAY” y la transacción se ejecuta, las reservas pueden cambiar. Re-obtén el estado del pool inmediatamente antes de la presentación; re-cotiza; si la nueva cotización es >1% peor, pausa y re-confirma con el usuario.

2. Listas negras de pools

Algunos pools de Raydium son tokens scam con comisiones de transferencia establecidas en 99% o con extensiones no transferibles. La API REST los etiqueta (ver el campo tags); salta cualquier pool etiquetado como scam o honeypot. Ejecutar tus propias verificaciones de seguridad además de las etiquetas de Raydium es prudente.

3. Requisito de estado de observación en CLMM

CLMM SwapV2 toma una cuenta observation_state. El SDK la rellena por ti; las instrucciones construidas manualmente a menudo la olvidan, lo que causa que el programa revierta con AccountNotFound. Siempre inclúyela.

4. Tablas de búsqueda de direcciones

Raydium mantiene tablas de búsqueda públicas para sus cuentas más utilizadas (mints principales, IDs de programa, AmmConfigs). Los agregadores deben consumirlas — ahorra ~100 bytes por transacción y permite que rutas más grandes quepan en V0. Extrayendo las direcciones de LUT:

5. Manejo de congestión

Durante ventanas de alto volumen, las transacciones pueden quedarse en el mempool durante múltiples bloques. Se recomienda reintento agresivo en expiración de TX (no en revert — los reverts son determinísticos). La opción sendAndConfirm del SDK hace reintentos básicos; los agregadores de producción superponen su propia lógica (bundles de Jito, broadcast multi-RPC) encima.

Lista de verificación

Antes de ir en vivo, verifica:
  • El descubrimiento de pools cubre CPMM + CLMM + AMM v4 de forma exhaustiva.
  • Las cotizaciones coinciden con la cotización de la propia interfaz de Raydium dentro de 1 punto base en un puñado de trades de prueba.
  • El enrutamiento dividido se activa para trades >5% de impacto en cualquier pool único.
  • Las comisiones de prioridad se dimensionan contra las comisiones recientes del programa de pool (ver integration-guides/priority-fee-tuning).
  • Las comisiones de transferencia de Token-2022 se calculan y se muestran al usuario.
  • Las transacciones revierten limpiamente cuando se excede el slippage.
  • La lógica de reintento distingue expiración de tx (reintentar) de revert (no reintentar).

Referencias

Fuentes: