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 →
Cada transacción en Solana establece (implícita o explícitamente) dos parámetros: un límite de unidades de computación (CUs máximas que la transacción puede consumir; por defecto 200.000 × número de instrucciones hasta un límite por transacción) y una tarifa de prioridad en micro-lamports por CU. Subestimar cualquiera de los dos mata la transacción: límites de CU demasiado bajos causan
ProgramFailedToComplete; tarifas de prioridad demasiado bajas hacen que la transacción permanezca sin confirmar hasta expirar.Los dos parámetros
setComputeUnitLimit(units)— limita la computación; la transacción paga como máximounitsCUs.setComputeUnitPrice(microLamports)— oferta de tarifa de prioridad, en micro-lamports por CU. Tarifa de prioridad total =units × microLamports × 1e-6lamports.
250_000 × 50_000 / 1e6 = 12.500 lamports ≈ 0,0000125 SOL ≈ $0,003 a $200 SOL. Las tarifas de prioridad en esta escala son insignificantes para la mayoría de swaps de usuarios, pero relevantes para bots que realizan 1000 transacciones/día.
Puntos de referencia de CU por instrucción
Puntos de referencia de registros de ejecución en mainnet, promediados en ejecuciones recientes. Los números son aproximados (±15%); remide para tus flujos específicos.| Instrucción | SPL Token | Token-2022 (simple) | Token-2022 (tarifa de transferencia) |
|---|---|---|---|
| CPMM initialize_pool | 180.000 | 200.000 | — |
| CPMM swap_base_input | 140.000 | 180.000 | 200.000 |
| CPMM swap_base_output | 150.000 | 185.000 | 205.000 |
| CPMM deposit | 130.000 | 160.000 | 180.000 |
| CPMM withdraw | 120.000 | 150.000 | 170.000 |
| CLMM create_pool | 70.000 | 85.000 | — |
| CLMM open_position_v2 | 120.000 | 140.000 | 160.000 |
| CLMM increase_liquidity_v2 | 150.000 | 175.000 | 195.000 |
| CLMM decrease_liquidity_v2 | 140.000 | 165.000 | 185.000 |
| CLMM swap_v2 (0 cruces de tick) | 170.000 | 205.000 | 225.000 |
| CLMM swap_v2 (1 cruce de tick) | 220.000 | 255.000 | 275.000 |
| CLMM swap_v2 (3 cruces de tick) | 320.000 | 355.000 | 375.000 |
| CLMM collect_fee | 80.000 | 95.000 | 105.000 |
| AMM v4 swap_base_in | 140.000 | — | — |
| AMM v4 deposit | 120.000 | — | — |
| AMM v4 withdraw | 110.000 | — | — |
| Farm v6 create_farm | 70.000 | 85.000 | — |
| Farm v6 deposit (1 ranura de recompensa) | 130.000 | 155.000 | 175.000 |
| Farm v6 deposit (3 ranuras de recompensa) | 220.000 | 255.000 | 275.000 |
| Farm v6 withdraw | coincide con deposit | ||
| Farm v6 harvest | coincide con deposit | ||
| Farm v3/v5 deposit | 100.000 | — | — |
| LaunchLab initialize | 100.000 | — | — |
| LaunchLab buy_exact_in | 140.000 | — | — |
| LaunchLab graduate | 250.000 | — | — |
Transacciones compuestas
Suma los presupuestos individuales y agrega:- +1.500 CU por marco de CPI — sobrecarga fija del tiempo de ejecución para cada llamada entre programas.
- +20.000 CU por creación de ATA —
create_associated_token_accountno es gratis. - +5.000 CU por
setComputeUnitLimit/setComputeUnitPricecada uno.
units × microLamports, así que aproximadamente un 25% por encima del presupuesto cuesta 25% extra en tarifa de prioridad).
Estimación de tarifa de prioridad
El mercado de tarifas local de Solana significa que las tarifas de prioridad son por cuenta escribible. Una transacción que escribe en una cuenta caliente (estado de pool popular) paga más que una que escribe en una cuenta fría. El nivel de tarifa global no es la métrica correcta para swaps de Raydium; quieres tarifas en los pools específicos que estás tocando.Estrategia 1: Estimador del proveedor RPC
Cada proveedor RPC importante publica un estimador de tarifa de prioridad que consulta tarifas recientes en cuentas específicas:Min / Low / Medium / High / VeryHigh / UnsafeMax. Mapéalos a percentiles:
| Nivel | Percentil | Caso de uso |
|---|---|---|
| Min | 25º | Tráfico de bot en segundo plano, no urgente |
| Low | 50º | Swaps normales de usuario |
| Medium | 60º | Valor por defecto para UIs de billetera |
| High | 75º | Arbitraje sensible al tiempo |
| VeryHigh | 95º | Liquidaciones, salidas de última oportunidad |
getPriorityFeeEstimate), Triton (getRecentPrioritizationFees con lista de cuentas), QuickNode (similar).
Estrategia 2: Consulta RPC directa
Usa el RPC estándargetRecentPrioritizationFees:
Estrategia 3: Auto-ajuste histórico
Para bots con flujo constante, rastrea tus propias tasas aterrizadas vs. expiradas:Manejo de fallos por agotamiento de CU
Síntoma: la transacción falla conexceeded maximum number of instructions allowed (200000) o ProgramFailedToComplete.
Diagnóstico:
- Aumenta el límite de CU. Si tu transacción usaba 195k de un presupuesto de 200k, aumenta a 300k.
- Divide la transacción. Si golpeas el límite de 1,4M por transacción, divide en dos transacciones. Farm
harvest then stakees un clásico para dividir cuando hay muchas recompensas. - Recorta cuentas. Cada cuenta adicional escribible agrega ~2.000 CU. Recortar cuentas no utilizadas ayuda en casos marginales.
- Usa tablas de búsqueda. Las búsquedas de LUT son ~50 CU por dirección resuelta, ahorrando los 5.000 CU de una referencia de cuenta completa por entrada.
Manejo de transacciones atascadas
Síntoma: transacción enviada, nunca confirma, eventualmente expira conBlockhashNotFound.
Diagnóstico:
getSignatureStatuses([sig])retornanull→ el líder nunca la vio.- Retorna
{ confirmationStatus: null }→ el líder la vio pero no la incluyó.
- Aumenta la tarifa de prioridad. Reenvía con 2× la tarifa actual.
- Reconstruye con blockhash fresco. La vida útil del blockhash es ~60 segundos; después de eso la transacción es inválida independientemente de las tarifas.
- Transmisión RPC múltiple. Algunos RPCs tienen mejor conectividad de líder que otros. Envía a 3–5 en paralelo.
- Cambia a bundles de Jito. Ver
integration-guides/routing-and-mev. Los bundles evitan las colas de paquetes públicas.
Bajo congestión
Cuando la red está congestionada (los dashboards de Jupiter / Jito bundle muestran acumulación, la latencia de RPC aumenta, las tasas de expiración de transacciones suben), ajusta:| Parámetro | Condiciones normales | Condiciones congestionadas |
|---|---|---|
| Límite de CU | +25% por encima de la estimación | +25% por encima de la estimación (sin cambios) |
| Percentil de tarifa de prioridad | 50º | 75º–95º |
| Cantidad de reintentos | 3 | 5–7 |
| Retroceso de reintento | 500ms | 1000ms |
| Usar bundles de Jito | Opcional | Altamente recomendado |
| Actualización de blockhash en reintento | Sí | Sí, obligatorio |
- Percentil 75º de tarifa de prioridad > 500k micro-lamports: congestión.
- Propina de 50º percentil de Jito > 0,001 SOL: congestión.
- RPC response p99 > 2s: problema específico de RPC o congestión.
Presupuesto de tarifas para bots
Un bot de trading que ejecuta ~1000 transacciones/día necesita un presupuesto de tarifa de prioridad. Estimación rápida:Trampas
1. Olvidar el límite de CU
El valor por defecto es 200k CUs × (instrucciones en transacción). Un swap de una sola instrucción por defecto es 200k; eso es suficiente para CPMM en SPL Token pero no para CLMM con cruces de tick o cualquier cosa Token-2022. Siempre establécelo explícitamente.2. Tarifa de prioridad en la cuenta equivocada
Si estimas la tarifa de prioridad contra el mint del token pero la cuenta caliente es el estado del pool, tu estimación es demasiado baja. El estado del pool es la cuenta escribible correcta para apuntar en Raydium.3. Las tarifas escalan con el límite de CU
total_priority_fee = units × microLamports. Aumentar units de 200k a 1M a 50k micro-lamports/CU multiplica la tarifa de prioridad 5×. No sobre-presupuestes CU solo por si acaso; mide.
4. Versión de transacción por defecto
Las transacciones heredadas tienen límites de cuenta más bajos; las transacciones V0 con tablas de búsqueda de direcciones desbloquean rutas más grandes. El SDK usa V0 por defecto entxVersion: TxVersion.V0. No cambies a heredado a menos que necesites compatibilidad con billetera.
5. skipPreflight oculta errores de CU
skipPreflight: true envía la transacción sin simulación local. Ahorras ~100ms pero pierdes la retroalimentación temprana sobre agotamiento de CU. Úsalo solo en reintentos, no en el primer intento.
Referencias
integration-guides/routing-and-mev— estrategias de bundles de Jito.integration-guides/aggregator— ensamblaje de transacciones.integration-guides/cpi-integration— apilamiento de CU en CPIs compuestos.- Documentación del programa de presupuesto de computación de Solana
- RPC
getRecentPrioritizationFeesde Solana - API de tarifa de prioridad de Helius
- Puntos de referencia: registros de ejecución en mainnet (pruebas de integración del SDK de Raydium, abril de 2026).


