Documentation Index
Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
Use this file to discover all available pages before exploring further.
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 →
Resumen en un párrafo
El programa de enrutamiento de AMM agrupa intercambios multi-salto en una única transacción en cadena que encadena liquidez entre pools. Tú proporcionas una ruta (una lista de pools y mints intermedios) e instrucciones de parámetros de slippage; el enrutador ejecuta todos los N saltos en orden, moviendo la salida de un pool a la entrada del siguiente. No se necesita lógica de enrutador separada en cadena para el cálculo de precios —la tarifa de cada salto y su curva se manejan mediante el programa del pool mediante CPI— pero el enrutador orquesta el paso de cuentas y el movimiento de tokens.¿Por qué un programa de enrutador separado?
Los clientes de Raydium y agregadores siempre pueden coser intercambios multi-salto juntos en el cliente sin usar el enrutador: construir N instrucciones de intercambio (una por pool) y enviarlas en una única transacción. ¿Por qué, entonces, tener un programa de enrutador dedicado?Razones para usar el enrutador
- CPI desde otros programas. Si tu propio programa necesita invocar una ruta como parte de una transacción más grande (por ejemplo, un gestor de liquidez que intercambia tarifas por un token objetivo), hacer CPI al enrutador es más limpio que agrupar N CPIs secundarios y gestionar todas sus cuentas en tu contrato.
- Estado de cuenta atómico. La lista de cuentas de cada salto se valida en un contexto de instrucción único. Si el estado de un pool intermedio está corrompido o una afirmación de precio límite falla, toda la ruta falla atómicamente sin liquidación parcial.
- Composición de instrucción única. Los SDKs e interfaces pueden representar una ruta multi-salto como una única operación lógica, no como N instrucciones separadas que suceden consecutivamente.
La costura del lado del cliente sigue siendo la predeterminada
Para la mayoría de aplicaciones, construir instruccionesSwap separadas para cada pool y enviarlas en orden es más simple, más componible e igualmente válido. El flujo Trade.makeSwapTransaction del SDK de Raydium y similares hacen exactamente esto para la mayoría de rutas.
El enrutador es una alternativa, no un reemplazo. Úsalo cuando:
- Estés implementando un programa que necesita enrutamiento como parte de una operación atómica más grande.
- Estés construyendo un agregador que quiera una única operación “envía esta ruta”.
Cómo funciona
Una instrucción de enrutador lleva:- Argumentos de intercambio: entrada exacta (
amount_in,minimum_amount_out) o salida exacta (maximum_amount_in,amount_out). - Especificación de ruta: una lista de
program_id+ cuentas del programa secundario para cada salto, en orden. El enrutador lee la primera cuenta en cada grupo de salto para determinar qué programa invocar. - Precios límite (para CLMM): una
VecDeque<u128>de límitessqrt_price_x64. Solo se usa para saltos a pools CLMM; una deque vacía es un error para variantes de instrucción más antiguas.
- Ejecuta el primer salto: transfiere
amount_in(o calcula la entrada requerida para salida exacta) a la bóveda de entrada del primer pool, invoca el intercambio de ese pool y recopila la salida. - Encadena saltos posteriores: para cada salto N, usa la salida del salto N−1 como entrada al salto N.
- Aplica slippage: en cada salto CLMM, verifica
sqrt_pricecontra ellimit_pricecorrespondiente; en el salto final, verifica la salida total contra elminimum_amount_outglobal.
Delegación de precios y tarifas
El enrutador no calcula precios por sí mismo. Cada salto delega a la curva del programa secundario:- AMM v4: usa la fórmula de producto constante con precios híbridos de OpenBook.
- CPMM: usa la fórmula de producto constante con el nivel de tarifa configurado.
- CLMM: usa las matemáticas de liquidez concentrada con precios basados en ticks.
- Stable: usa la curva de intercambio estable para tokens de tipo similar.
Cuándo evitar el enrutador
- Recuento bajo de saltos (1–2 saltos). La sobrecarga de paso de cuentas es mínima; simplemente usa dos instrucciones de intercambio separadas.
- Pools que no son de Raydium. El enrutador solo conoce los cuatro tipos de pools de Raydium. Para rutas que cruzan programas externos, cose instrucciones en tu cliente.
- Enrutamiento condicional. Si necesitas ramificarte en precios o estados de pool a mitad de ruta, el enrutamiento en cadena es menos flexible que la composición del lado del cliente.
Modelo mental
Piensa en el enrutador como una utilidad de empaque de transacciones. Toma tu especificación de ruta y la empaca en una instrucción, una transacción, un presupuesto de cálculo. Cada salto internamente hace CPI a su programa de pool y maneja la matemática de la curva allí. El trabajo del enrutador es pasar cuentas correctamente, mover tokens entre saltos y verificar slippage.Hacia dónde ir a continuación
products/routing/accounts— el PDA de autoridad de ruta y el patrón de cuenta compartida.products/routing/instructions— la API de instrucción completa (todas las 10 variantes).products/routing/code-demos— ejemplos de construcción de rutas en TypeScript y Rust puro.integration-guides/routing-and-mev— estrategia más amplia para enrutamiento multi-salto.