Jupiter: cómo resolver los errores 6001 y 6024 en un swap

En la referencia del programa de swaps de Jupiter, 6001 corresponde a SlippageToleranceExceeded y 6024 a InsufficientFunds. Esa referencia está dentro de Metis Swap V1, que ha sido sustituido. Los códigos siguen siendo útiles cuando los logs identifican ese programa, pero no son los códigos universales de respuesta de Swap V2. Otro programa invocado en la ruta puede utilizar la misma numeración con significado distinto.

Guarda la firma o TXID si existe, el texto completo, la hora, los tokens y sus mint addresses, el importe y la wallet utilizada. Consulta en el explorador si la transacción terminó correctamente, falló o no llegó a la cadena. Un rechazo de simulación antes de enviar no equivale a una transacción confirmada con error. Si no hay firma, conserva el mensaje de la interfaz o la respuesta de la API en lugar de inventar un identificador.

SlippageToleranceExceeded indica que la ejecución no cumple la tolerancia configurada para ese swap. Puede cambiar el precio mientras revisas o firmas, reducirse la liquidez de una ruta o resultar demasiado grande el importe para las condiciones actuales. Actualiza la cotización y compara salida esperada, mínimo recibido e impacto de precio antes de decidir. La tolerancia de slippage y el impacto estimado no son conceptos intercambiables.

Ejemplo hipotético: una cotización espera 100 unidades y aceptas como mínimo 99,50. Si la ruta solo puede entregar 99,20, rechazarla preserva tu límite; subirlo a ciegas permitiría un resultado que antes habías descartado. Reducir el tamaño o esperar puede ofrecer otra cotización, pero no garantiza un precio mejor. Si decides ampliar la tolerancia, hazlo porque entiendes el nuevo mínimo y lo aceptas, no para silenciar el código.

• Comprueba si el intento anterior falló antes de crear otro.
• Actualiza la ruta y vuelve a leer el mínimo recibido.
• Verifica que el mint de cada token sea el previsto.
• Valora importe e impacto, especialmente en pools pequeños.
• Firma una cotización vigente, sin dejarla esperando indefinidamente.

InsufficientFunds puede referirse al token vendido, a las comisiones de transacción o a la financiación de una cuenta de tokens. Verifica el saldo utilizable del mint exacto en la wallet que firma. Tener USDC no paga automáticamente una salida en USDT; tener SOL en otra cuenta o en otra red tampoco financia la wallet de Solana que está realizando el swap. Una pantalla con varios saldos agregados puede ocultar esa diferencia.

Rent no es una comisión maker/taker: puede implicar saldo inmovilizado para mantener una cuenta de tokens. No des por hecho que siempre se crea una cuenta nueva ni que su coste es fijo para cualquier operación. Conserva el margen de SOL que indique la transacción cuando tú seas el pagador. La guía de Phantom explica cómo comprobar red, dirección y saldo disponible antes de enviar.

En Swap V2, /order obtiene la cotización y prepara la transacción. Si devuelve transaction vacío junto con errorCode, puede existir un precio válido sin que haya una operación lista para firmar. Hay que interpretar router y errorCode conjuntamente: el código 2 en rutas agregadoras identifica falta de SOL para gas, mientras en JupiterZ puede indicar que falta una cuenta asociada de tokens. Un código leído sin router conduce a un diagnóstico equivocado.

La ruta gestionada utiliza RTSE para estimar slippage al solicitar la orden y /execute para su entrega. /build proporciona instrucciones para flujos personalizados con parámetros propios. No copies la antigua recomendación dynamicSlippage de V1 como arreglo universal de V2. Tampoco todos los fallos de /execute son slippage: existen órdenes expiradas, firmas incompletas y problemas de entrega. La interfaz puede encargarse de estos pasos; no necesitas programar una integración para comprobar el historial de tu wallet.

V2 contempla patrocinio de gas en operaciones elegibles, incluidas ciertas rutas de JupiterZ o un pagador distinto. No deduzcas que cualquier swap es gratuito o que puedes vaciar todo el SOL sin revisar la operación. La identidad del pagador, el router y la elegibilidad concretos determinan el caso. Los cargos de plataforma y el importe final siguen siendo otra parte del presupuesto.

• Abre la transacción del intento anterior y comprueba su estado final.
• Si está confirmada con éxito, revisa cambios de saldo y no repitas la compra por un aviso atrasado.
• Si falló, identifica programa, instrucción y mensaje; separa slippage de falta de fondos.
• Obtén una cotización nueva y corrige solo el problema identificado.
• Después de firmar, guarda la nueva referencia y verifica el resultado.

Las transacciones enviadas y procesadas pueden consumir una comisión de red aunque la operación falle; un rechazo anterior al envío es otro caso. Para un ejemplo de saldo, si intentas vender 100 USDC y solo tienes 99,80 del mint correcto, añadir SOL no resuelve la falta del token vendido. Si sí tienes los 100 USDC pero falta gas y no hay patrocinio aplicable, reducir USDC sin aportar el pagador necesario tampoco garantiza que funcione.

Conserva firma, red Solana, mint de entrada y salida, cantidad, hora y mensaje completo. Si usas una integración, añade router, endpoint y código, eliminando API keys o datos privados antes de compartirlos. No entregues frase de recuperación, clave privada ni firmas solicitadas por una persona que prometa reparar la wallet. Un TXID permite examinar el intento; no autoriza a nadie a mover tus fondos.

La reseña de Jupiter distingue agregación de swaps y Perps, que no comparten necesariamente el mismo recorrido. Para practicar con los conceptos de ruta y financiación, continúa con cómo utilizar un DEX y cómo calcular costes. Si el problema es que los fondos nunca llegaron a la wallet, utiliza retiradas hacia una wallet antes de diagnosticar un swap que aún no puede financiarse.