Por qué fallan las transacciones de Solana: 5 soluciones

Esta guía orientada a la acción se centra en cinco soluciones prácticas para transacciones fallidas de Solana y pasos que pueden prevenir fallos repetidos.

Las transacciones de Solana fallan por cinco razones:

1. Blockhash expirado antes de que la red confirmara la transacción
2. La comisión de prioridad fue demasiado baja para la demanda actual de la red
3. La tolerancia al Deslizamiento se incumplió en un intercambio DEX
4. El presupuesto de unidades de cómputo se agotó a mitad de ejecución
5. El nodo RPC que conecta tu billetera a la red estaba sobrecargado

✅ Tus fondos están seguros

Una transacción de Solana fallida no deduce tokens de tu billetera. Tu SOL y tokens permanecen exactamente donde estaban. Como mucho, puedes perder una pequeña comisión base de red, normalmente menos de 0,001 $. No se te cobró el importe de tu intercambio, transferencia o acuñación NFT.

En esta página:

• Por qué fallan las transacciones de Solana: ¿Qué está pasando
• Las 5 causas fundamentales de los fallos de transacciones de Solana
• Mensajes de Solana Error decodificados
• Cómo solucionar una transacción fallida de Solana
• Fallos específicos de la Plataforma
• ¿Está Solana caído? Cómo comprobar el estado de la red
• ¿Todavía pagas comisiones por una transacción fallida?
• Lista de verificación previa a la transacción
• Preguntas frecuentes
• Resumen: Empareja tu Error con la solución correcta

Por qué fallan las transacciones de Solana: ¿Qué está pasando

Ver cómo falla una transacción de Solana mientras se desarrolla un movimiento de precios es frustrante, especialmente cuando el mensaje de error no te dice nada útil. Si tu intercambio, acuñación o transferencia acaba de fallar en Jupiter, Raydium, Orca o Magic Eden, la causa es casi siempre una de cinco cosas, y cada una tiene una solución específica.

En todo el ecosistema de finanzas Descentralizadas (DeFi) de Solana, incluyendo intercambios de tokens, provisión de liquidez, protocolos de préstamos y acuñaciones de NFT, los fallos de transacciones conllevan consecuencias financieras reales porque los precios se mueven en milisegundos. La arquitectura de Solana la hace más rápida y barata que la mayoría de las blockchains, pero también crea modos de fallo que los usuarios familiarizados con Ethereum u otras cadenas no esperan. A diferencia de las redes donde las transacciones lentas esperan en una cola, Solana utiliza un protocolo de reenvío de transacciones llamado Gulf Stream que descarta las transacciones que no puede procesar inmediatamente. No hay cola. Las transacciones fallidas requieren una reenvío activo con la configuración correcta.

Esta guía cubre fallos en tu billetera de Criptomonedas (como Phantom o Backpack), Jupiter, Raydium, Orca y Magic Eden. Si sospechas que la propia Solana está experimentando problemas hoy, salta a la sección estado de la red antes de solucionar la configuración.

Las 5 causas fundamentales de los fallos de transacciones de Solana

Los fallos de transacciones de Solana se dividen en dos categorías: fallos a nivel de red (vencimiento del blockhash, congestión, nodos RPC sobrecargados) y rechazos a nivel de programa por el contrato inteligente, o programa, que ejecuta la aplicación que estás utilizando. Los errores de tolerancia al Deslizamiento y los errores de presupuesto de cómputo son rechazos a nivel de programa; el vencimiento del blockhash y la comisión de prioridad insuficiente son a nivel de red. La solución depende de qué tipo estés enfrentando.

Solana utiliza un sistema de cronometraje llamado Proof of History, que genera una secuencia criptográfica que los validadores utilizan para acordar la hora sin comunicarse marcas de tiempo entre sí. Cada bloque en esta secuencia produce un blockhash, un código similar a una marca de tiempo incrustado en cada transacción para probar que la transacción está actualizada. Esta arquitectura basada en bloques crea las ventanas de vencimiento únicas de Solana y es lo que distingue sus modos de fallo de otras blockchains.

Causa 1: Blockhash expirado

Cada transacción de Solana lleva un blockhash, que prueba que la transacción se creó recientemente. Si este blockhash expira antes de que la red confirme la transacción, Solana la descarta por completo.

Cada blockhash es válido durante aproximadamente 150 bloques, lo que equivale a unos 60 a 90 segundos en condiciones normales. Durante la congestión de la red, los validadores se retrasan en el procesamiento, lo que significa que las transacciones expiran más rápido en términos relativos. Los mensajes de error que verás son Blockhash not found (Blockhash no encontrado) o Transaction expired (Transacción expirada).

Solana utiliza Gulf Stream en lugar de una cola de transacciones tradicional, lo que significa que una transacción descartada no se vuelve a poner en cola ni espera. Desaparece. Debes reenviarla activamente iniciando la transacción de nuevo desde tu billetera o interfaz DEX. La billetera recupera automáticamente un blockhash fresco en el nuevo envío. Para el procedimiento de reenvío, consulta Solución 3: Reenviar con un Blockhash fresco.

⚠️ Nota para desarrolladores

Siempre recupera un blockhash fresco con connection.getLatestBlockhash('confirmed') en cada intento de reintento. Nunca reutilices un blockhash entre intentos de reintento. Utiliza niveles de compromiso confirmed o finalized en entornos de producción, no processed, para evitar estados obsoletos. Detecta si una transacción fue descartada o procesada llamando a getSignatureStatuses antes de cada reintento.

Durante la congestión de la red, los validadores de Solana, los ordenadores que procesan tus transacciones, eligen qué transacciones manejar primero basándose en los niveles de comisión de prioridad.

Una comisión de prioridad es una propina opcional pagada a los validadores, medida en micro-lamports por unidad de cómputo. Un lamport equivale a 0,000000001 SOL; un micro-lamport es una millonésima parte de un lamport. Durante períodos de alto tráfico, como lanzamientos de NFT populares o movimientos bruscos del mercado, los validadores procesan primero las transacciones con comisiones de prioridad más altas. Las transacciones con comisiones de prioridad cero o insuficientes se descartan en lugar de ponerse en cola.

Una causa relacionada de errores de SOL insuficientes: Solana requiere que cada cuenta mantenga un saldo mínimo llamado umbral exento de alquiler para permanecer activa en la red. Si el Balance de tu billetera cae por debajo de este umbral después de una comisión, o si una transacción creara una nueva cuenta de token sin suficiente SOL para financiarla, verás un error de Fondos insuficientes incluso cuando parezca que tienes suficiente SOL para la operación en sí. Mantén un margen de 0,05 SOL por encima de tu importe de transacción.

Esta es la razón por la que reenviar la misma transacción sin cambiar la configuración a menudo falla de nuevo. Para obtener orientación sobre cómo establecer el nivel de comisión correcto, consulta Solución 1: Aumenta tu comisión de prioridad.

⚠️ Nota para desarrolladores

Añade ComputeBudgetProgram.setComputeUnitPrice(microLamports) como la primera instrucción en tu transacción. Consulta getRecentPrioritizationFees() para una estimación dinámica en lugar de usar un multiplicador estático. Los niveles de comisión cambian con la demanda de la red, por lo que los valores estáticos se vuelven poco fiables durante los picos de congestión. Detecta los desencadenantes de conmutación por error supervisando los errores HTTP 429 (límite de tasa), 503 (servicio no disponible) y de tiempo de espera de conexión.

Cada transacción de Solana se ejecuta con un presupuesto de procesamiento llamado unidades de cómputo, que miden la cantidad de trabajo computacional que requiere la transacción. Las transferencias simples consumen muy poco de este presupuesto. Las operaciones complejas, como un intercambio DEX multi-salto enrutado a través de tres o cuatro pools de liquidez, consumen considerablemente más.

Si tu transacción agota su presupuesto de unidades de cómputo antes de finalizar, Solana la cancela. Los errores que verás son Presupuesto de cómputo excedido o El programa no pudo completarse.

Antes de enviar tu transacción, Phantom y otras carteras ejecutan una comprobación previa llamada simulación de transacción, que ejecuta la transacción contra el estado actual de la Blockchain sin enviarla realmente. Si la simulación detecta que las unidades de cómputo se agotarán, bloquea la transacción y muestra Simulación de transacción fallida. La mayoría de los fallos de simulación indican un problema real con la transacción, aunque ocasionalmente los datos de estado obsoletos provocan un fallo falso en una transacción que de otro modo tendría éxito.

Para la mayoría de los usuarios en las interfaces modernas de DEX, los límites de unidades de cómputo se establecen automáticamente. Si ves un error de presupuesto de cómputo, utiliza el botón de reintento integrado de DEX antes de intentar ajustes manuales. Para pasos detallados, consulta Solución 5: Ajustar el Presupuesto de Unidad de Cómputo.

⚠️ Nota para desarrolladores

Añade ComputeBudgetProgram.setComputeUnitLimit(units) como la primera instrucción en la transacción. Ejecuta primero simulateTransaction() para medir el consumo real de unidades de cómputo, luego establece el límite al consumo real multiplicado por 1,1 como un búfer del 10%. Establecer el límite demasiado bajo provoca fallos de InstructionError; establecerlo demasiado alto desperdicia presupuesto de tarifa pero no causa fallos.

Causa 4: Deslizamiento de Tolerancia Excedido

La tolerancia de deslizamiento es una salvaguarda que tu exchange descentralizado (DEX, una Plataforma donde puedes intercambiar tokens directamente desde tu cartera) establece en tu nombre. Si el precio de un token se mueve más allá de tu umbral establecido entre el momento en que solicitas un intercambio y el momento en que se ejecuta, el Contrato inteligente cancela la transacción para protegerte de un precio peor del esperado.

Este es un fallo protector, no una pérdida. Tu capital está seguro; el intercambio no se ejecutó. El error que verás es Deslizamiento de tolerancia excedido.

Los fallos de deslizamiento ocurren con mayor frecuencia en tokens volátiles, pares de trading con baja Liquidez y durante períodos de alta congestión cuando hay un retraso más largo entre tu cotización de precio y la ejecución. Si un grupo de Liquidez tiene reservas muy bajas, incluso una tolerancia de deslizamiento del 5% puede no ser suficiente porque el grupo no puede acomodar el tamaño de tu operación a ningún precio razonable. En ese caso, intenta reducir tu cantidad de intercambio o cambia a un par de trading diferente.

Jupiter, Raydium y Orca son los DEX donde este fallo se encuentra con mayor frecuencia. Para instrucciones de ajuste paso a paso, consulta Solución 2: Ajustar tu Tolerancia de Deslizamiento.

Causa 5: Nodo RPC Sobrecargado

Tu cartera de Solana se conecta a un servidor llamado nodo RPC para enviar transacciones. Piénsalo como la oficina de correos que pasa tu transacción a la red de validadores. Cada vez que haces clic en confirmar en Phantom o Backpack, la cartera envía tu transacción a un nodo RPC, que la reenvía a los validadores.

El endpoint RPC público y gratuito de Solana tiene límites de velocidad y a menudo se sobrecarga durante períodos de alta demanda. Durante el lanzamiento de un NFT Popular o un movimiento brusco del mercado, los nodos RPC públicos reciben muchas más solicitudes de las que pueden manejar y descartan transacciones antes de que lleguen siquiera a los validadores. Cuando esto sucede, puedes ver No se pudo confirmar la transacción o experimentar fallos silenciosos sin ningún mensaje de error.

Cambiar a un proveedor RPC dedicado, como Helius o QuickNode, ambos con niveles gratuitos, le da a tus transacciones un camino más fiable hacia la red. Para ver los pasos para cambiar tu RPC, consulta Solución 4: Cambiar a un mejor Endpoint RPC.

⚠️ Nota para desarrolladores

Mantén una lista de endpoints RPC de respaldo en la configuración de tu aplicación. Implementa lógica de failover automático cuando el endpoint principal devuelva errores o tiempos de espera. Usa WebSocket signatureSubscribe para el monitoreo de confirmación de transacciones en lugar de sondeos HTTP con getSignatureStatuses, ya que las suscripciones WebSocket son más rápidas y fiables bajo carga.

Mensajes de Error de Solana Decodificados: Qué Significa Cada Uno

Los mensajes de Error de transacciones fallidas de Solana aparecen en el registro de actividad de tu cartera (Phantom o Solflare), en Solana Explorer (explorer.solana.com) o en Solana FM (solana.fm). Para buscar una transacción fallida específica, Copiar la firma de la transacción del historial de transacciones de tu cartera y pégala en cualquiera de los exploradores. Una transacción fallida muestra un estado de error rojo con el código de error específico.

Antes de enviar cualquier transacción, Phantom ejecuta una simulación para predecir si tendrá éxito. Si esta comprobación previa falla, Phantom muestra Simulación de transacción fallida y bloquea el envío. La mayoría de los fallos de simulación indican un problema real con tu configuración, pero ocasionalmente los datos obsoletos causan un fallo falso. En ese caso, refrescar la página y reenviar una vez es apropiado.

Cómo Solucionar una Transacción Fallida de Solana

Lista de verificación de soluciones rápidas (empieza por la Solución 1 si no estás seguro de cuál aplicar):

1. Aumenta tu tarifa de prioridad a Rápida o Turbo y reenvía
2. Ajusta la tolerancia de deslizamiento al alza en un 0,5% - 1% y reenvía
3. Reenvía con un bloque fresco (espera 5 segundos, luego inicia de nuevo desde el DEX)
4. Cambia a un endpoint RPC dedicado en la configuración de tu cartera
5. Comprueba el estado de la red Solana en status.solana.com antes de intentar de nuevo si sospechas de congestión

Una tarifa de prioridad insuficiente causa la mayoría de las transacciones fallidas durante períodos de negociación activos, por lo que la Solución 1 es el punto de partida correcto cuando no estás seguro.

Solución 1: Aumenta tu Tarifa de Prioridad

Aumentar tu tarifa de prioridad es la solución más efectiva para transacciones fallidas durante periodos de congestión. Señala a los validadores que procesen tu transacción antes que las presentaciones de menor tarifa.

Los niveles de tarifa varían con la demanda de la red. Utiliza la función de autoestimación de tu billetera o consulta Solana Beach para conocer las condiciones actuales de la red. No te fíes de valores específicos de lamport, ya que cambian rápidamente.

Referencia de Niveles de Tarifa de Prioridad:

Para aumentar la tarifa de prioridad en Jupiter (la interfaz puede variar según la versión):

1. Abre Jupiter en jup.ag
2. Haz clic en el icono del engranaje de configuración en el panel de intercambio
3. Selecciona Tarifa de prioridad
4. Elige Rápido o Turbo, o introduce un valor Personalizado
5. Vuelve a enviar tu intercambio

Para aumentar la tarifa de prioridad en Phantom:

1. Abre la billetera Phantom
2. Ve a Configuración
3. Selecciona Transacciones
4. Ajusta la Velocidad de Transacción a Alta o Personalizada
5. Vuelve a tu DEX y vuelve a enviar

Para Raydium, haz clic en el engranaje de configuración en la interfaz de intercambio, selecciona Tarifa de prioridad, elige un nivel más alto y vuelve a enviar. La tabla de fallos específicos de la Plataforma muestra la ruta de navegación exacta para cada Plataforma.

⚠️ Nota para desarrolladores

Añade ComputeBudgetProgram.setComputeUnitPrice(microLamports) como la primera instrucción en tu transacción. Llama a getRecentPrioritizationFees() para obtener los percentiles de tarifa de red actuales en lugar de usar un multiplicador estático. Pagar en exceso desperdicia SOL pero no causa fallos en la transacción.

Solución 2: Ajusta tu Tolerancia al Deslizamiento

Si tu intercambio falló con un error de tolerancia al deslizamiento, la solución es ampliar el rango de precio aceptable, pero la cantidad en la que lo amplías importa.

⚠️ Advertencia importante

Establecer el deslizamiento por encima del 3% al 5% en pares de tokens con baja liquidez te expone a ataques de sándwich MEV, donde los bots detectan tu transacción pendiente y se adelantan a ella para extraer valor. Aumenta el deslizamiento incrementalmente, no todo de una vez.

Para ajustar el deslizamiento en Jupiter (la interfaz puede variar según la versión):

1. Abre Jupiter y haz clic en el icono del engranaje de configuración
2. Selecciona Tolerancia al Deslizamiento
3. Aumenta tu configuración actual en un 0.5% a 1% (por ejemplo, de 0.5% a 1.5%)
4. Vuelve a enviar tu intercambio

Para Raydium: haz clic en el engranaje de configuración, selecciona Deslizamiento, introduce tu porcentaje ajustado y vuelve a enviar. Para Orca: haz clic en Configuración, ajusta la Tolerancia al Deslizamiento y vuelve a enviar. La tabla de fallos específicos de la Plataforma muestra la ruta de navegación exacta para cada DEX.

Si estás utilizando Jupiter, comprueba si la función de Deslizamiento Dinámico está disponible en tu interfaz. Esta función calcula automáticamente el deslizamiento óptimo para cada trade según las condiciones actuales del mercado.

Si un token sigue fallando incluso con un deslizamiento del 5%, el problema es probablemente una liquidez insuficiente en el pool en lugar de un movimiento de precios. Intenta reducir la cantidad de tu intercambio o dividir el trade en transacciones más pequeñas.

Solución 3: Vuelve a enviar con un Blockhash nuevo

Un vencimiento de blockhash se soluciona volviendo a enviar, pero no puedes reenviar el mismo objeto de transacción. Solana requiere un blockhash nuevo en cada envío.

Dado que Solana utiliza Gulf Stream en lugar de una cola de transacciones tradicional, una transacción descartada no puede "desatascarse". La transacción se ha perdido. Debe crearse una nueva transacción desde cero.

Para usuarios consumidores (Phantom, Jupiter, Raydium):

1. Espera de 5 a 10 segundos después del fallo
2. No hagas clic en enviar de nuevo en la misma pantalla de confirmación
3. Vuelve a la interfaz de intercambio e inicia la transacción de nuevo desde el principio
4. Tu billetera obtiene automáticamente un blockhash nuevo cuando vuelves a enviar

Antes de volver a enviar: comprueba Solana Explorer (explorer.solana.com) para confirmar que la transacción no se realizó correctamente. Pega tu firma de transacción en la barra de búsqueda. Si la transacción aparece como confirmada, no vuelvas a enviarla.

⚠️ Nota para desarrolladores

Obtén un blockhash nuevo con connection.getLatestBlockhash('confirmed') antes de cada intento de reintento. Implementa un backoff exponencial: espera 1 segundo antes del primer reintento, 2 segundos antes del segundo, 4 segundos antes del tercero. Establece un número máximo de reintentos de 5 intentos antes de mostrar un error al usuario. Utiliza los niveles de compromiso confirmed o finalized, no processed, al obtener blockhashes en entornos de producción.

El endpoint RPC público gratuito de Solana (api.mainnet-beta.solana.com) está limitado en cuanto a la tasa y a menudo sobrecargado durante periodos de alta demanda, lo que hace que las transacciones enviadas tengan más probabilidades de ser descartadas antes de llegar a los validadores.

Proveedores de RPC dedicados como Helius y QuickNode generalmente ofrecen mayor fiabilidad que el RPC principal de Solana durante la congestión. Ambos proveedores ofrecen niveles gratuitos adecuados para usuarios individuales.

Para cambiar el RPC en Phantom (la interfaz puede variar según la versión):

1. Abre la billetera Phantom
2. Ve a Configuración
3. Selecciona Configuración del desarrollador
4. Elige Cambiar Endpoint RPC
5. Introduce la URL de tu endpoint de Helius o QuickNode
6. Confirma y vuelve a enviar tu transacción

Para cambiar el RPC en Solflare:

1. Abre la billetera Solflare
2. Ve a Configuración
3. Selecciona Red
4. Elige RPC Personalizado e introduce la URL de tu endpoint
5. Guarda y vuelve a enviar tu transacción

⚠️ Nota para desarrolladores

Mantén una lista de endpoints RPC de respaldo en la configuración de tu aplicación. Implementa lógica de failover automático para que tu aplicación cambie a una copia de seguridad cuando la principal devuelva errores o se agote el tiempo de espera. Utiliza signatureSubscribe de WebSocket para el seguimiento de confirmación de transacciones en lugar de encuestar con getSignatureStatuses, ya que las conexiones WebSocket son más rápidas bajo carga pesada.

Para usuarios consumidores, la mayoría de las interfaces de DEX modernas, incluidas Jupiter y Raydium, establecen los límites de unidades de cómputo automáticamente. Si ves un error de Presupuesto de cómputo excedido, utiliza la función de reintento o actualización integrada de DEX en lugar de ajustar manualmente la configuración.

Si el error persiste, intenta simplificar tu ruta de intercambio. Una ruta directa a través de un solo pool utiliza menos unidades de cómputo que una ruta compleja de varios saltos a través de cuatro o cinco pools. En Jupiter, busca una opción de Solo Ruta Directa en la configuración de enrutamiento.

Si tu intercambio falla constantemente en un par específico, puede ser una ruta de alta demanda temporal. Esperar unos minutos y volver a enviar a menudo resuelve el problema sin cambios en la configuración.

⚠️ Nota para desarrolladores

Añade ComputeBudgetProgram.setComputeUnitLimit(units) como la primera instrucción en la transacción. Ejecuta simulateTransaction() primero para medir el consumo real de unidades de cómputo, luego establece el límite al consumo real multiplicado por 1.1 como un buffer de seguridad del 10%. Establecer el límite demasiado bajo causa fallos en la Instrucción Error; establecerlo demasiado alto desperdicia el presupuesto de tarifa sin causar fallos.

Fallos específicos de la Plataforma: Phantom, Jupiter, Raydium y Magic Eden

Los escenarios de fallo más comunes de Solana se desarrollan de manera diferente según la Plataforma que estés utilizando. Consulta la tabla comparativa a continuación para encontrar tu Plataforma, luego lee la subsección correspondiente para obtener detalles.

Fallos en Intercambios de Jupiter

El enrutamiento multi-salto de Jupiter envía tu intercambio a través de varios pools de liquidez para encontrar el mejor precio. Cada salto adicional aumenta el consumo de unidades de cómputo y crea otro punto donde el movimiento de precios puede superar la tolerancia al Deslizamiento.

Los dos fallos más comunes específicos de Jupiter son el Deslizamiento excedido en pares de tokens volátiles y el Error de simulación de transacción debido a una tarifa prioritaria insuficiente. Ambos se solucionan ajustando la configuración en el menú del icono de engranaje de Jupiter antes de volver a enviar.

El selector de tarifa prioritaria integrado de Jupiter ofrece opciones Normal, Rápida, Turbo y Personalizada. Durante cualquier sesión de trading activa, Rápida es la configuración mínima recomendada. Durante un lanzamiento de NFT o un movimiento brusco del mercado, usa Turbo.

Algunas billeteras más antiguas no admiten el formato de transacciones versionadas de Jupiter. Si ves un Error en el formato de la transacción en lugar de un Error de Deslizamiento o Tarifa, asegúrate de que el software de tu billetera esté actualizado.

Fallos en Intercambios de Raydium y Orca

Los fallos de AMM en Raydium y Orca provienen con mayor frecuencia de un alto impacto en el precio en pools con Liquidez limitada. El pool no puede acomodar el tamaño de tu Trade a un precio razonable, incluso con generosas configuraciones de Deslizamiento.

Antes de confirmar cualquier intercambio en Raydium u Orca, verifica el porcentaje de impacto en el precio que se muestra en la interfaz. Si el impacto en el precio excede del 2% al 3%, el tamaño del Trade es demasiado grande para la Liquidez disponible en ese pool. Reduce tu monto de intercambio o divídelo en dos o tres intercambios más pequeños enviados secuencialmente.

Para las posiciones de liquidez concentrada de Whirlpool de Orca, el Deslizamiento puede ser especialmente sensible. Si un pool concentrado se ha salido de su rango de precios activo, las transacciones fallarán independientemente de tu configuración de Deslizamiento. En ese caso, prueba un pool diferente o enruta a través del agregador de Jupiter, que encuentra automáticamente rutas alternativas.

Fallos en Acuñaciones de Magic Eden y NFT

Los fallos en las acuñaciones de NFT en Magic Eden difieren de los fallos de acuñación de DEX rutinarios porque el problema no son tus configuraciones. El problema es la presentación simultánea de miles de transacciones durante una ventana de lanzamiento estrecha, lo que satura la red y hace que los validadores descarten las transacciones de tarifa prioritaria baja antes de que puedan procesarse.

Las acuñaciones de alta demanda que utilizan programas Candy Machine crean una competencia extrema. Los bots envían cientos de transacciones por segundo, saturando tanto la RPC pública como la cola de validadores.

Protocolo de tres pasos para una acuñación exitosa durante un lanzamiento de alta demanda:

1. Antes de que se abra la ventana de acuñación, establece tu tarifa prioritaria en Turbo o en la configuración máxima disponible en tu billetera
2. Cambia de la RPC pública de Solana a un proveedor dedicado como Helius o QuickNode (los niveles gratuitos son suficientes)
3. Ten la página de acuñación completamente cargada y tu conexión a la billetera preaprobada; envía la transacción inmediatamente cuando se abra la acuñación, no después de que se actualice la página

Tu capital de SOL se devuelve automáticamente si una transacción de acuñación falla. Solo se consume la pequeña tarifa de red, aproximadamente 0.000005 SOL. Algunos proyectos también utilizan mecanismos de lista de permitidos (allow-list) y Candy Guards, por lo que si las transacciones fallan consistentemente incluso con configuraciones correctas, confirma que cumples los requisitos para la fase de acuñación actual.

¿Está Solana Caída? Cómo Comprobar el Estado de la Red

La mayoría de los fallos de transacciones de Solana no son causados por una interrupción de la red. Son el resultado de configuraciones del lado del usuario o de congestión temporal de la red. Las interrupciones reales, donde la red se detiene por completo, son raras y se anuncian oficialmente.

Comprobación de estado en tres pasos:

1. Ve a status.solana.com, la página oficial de estado de la red de Solana, y verifica si hay informes de incidentes activos de la Solana Foundation.
2. Ve a Solana Beach y verifica la cifra de transacciones por segundo (TPS) en tiempo real y el tiempo promedio de confirmación. Las altas tasas de fallo durante el TPS activo indican congestión de la red, no una interrupción.
3. Consulta r/solana o el Discord de Solana. Si muchos usuarios informan de fallos simultáneamente, la red está congestionada. Si solo unos pocos lo hacen, el problema probablemente sea tuyo.

¿Sigues pagando tarifas por una transacción fallida de Solana?

Sí, Solana cobra una pequeña Tarifa base de transacción incluso cuando una transacción falla, pero tus tokens y el monto principal de tu intercambio, transferencia o acuñación no se deducen de tu billetera.

Tus tokens están seguros. La transacción falló antes de que se ejecutara cualquier intercambio o transferencia.

La Tarifa base es de aproximadamente 0.000005 SOL por firma, lo que equivale a una fracción de céntimo en la mayoría de los precios de SOL. Esta tarifa compensa a los validadores por procesar el intento de transacción, incluso cuando no tiene éxito. Si incluiste una tarifa prioritaria, esa cantidad también se consume. El monto del token que intentabas intercambiar, el SOL que intentabas enviar o el precio de NFT que intentabas pagar nunca se dedujeron.

Una transacción descartada silenciosamente por un nodo RPC sobrecargado antes de llegar a los validadores no cobra ninguna tarifa, porque no hay registro On-Chain de ella.

Para verificar exactamente cuánta tarifa se cobró en cualquier transacción fallida:

1. Copiar la firma de la transacción del historial de transacciones de tu billetera
2. Pegarla en Solana Explorer o Solana FM
3. Localizar la transacción fallida, que muestra un estado de Error rojo
4. Consultar el campo Tarifa para ver la cantidad exacta de SOL cobrada

Lista de verificación previa a la transacción: Cómo prevenir fallos en las transacciones de Solana

Repasar esta lista de verificación antes de cualquier transacción sensible al tiempo lleva menos de 60 segundos y elimina las causas más comunes de fallo.

1. Consulta status.solana.com para ver incidentes activos antes de cualquier transacción durante condiciones de mercado volátiles
2. Establece tu tarifa prioritaria en al menos Rápida para cualquier transacción durante las horas de operación activa; usa Turbo para Trades sensibles al tiempo o acuñaciones NFT
3. Verifica que tu tolerancia al Deslizamiento coincida con la volatilidad del par de tokens: 0.5% para pares estables como USDC/USDT, 1% a 2% para tokens de capitalización media, hasta 3% para small-caps volátiles
4. Confirma que tu Balance de SOL cubre el monto de la transacción más las tarifas más un búfer de 0.05 SOL para umbrales exentos de alquiler
5. Para transacciones sensibles al tiempo o de alto valor, cambia de la RPC pública de Solana a un proveedor dedicado como Helius o QuickNode (ambos ofrecen niveles gratuitos)
6. Para acuñaciones NFT: configura tu tarifa prioritaria y RPC antes de que se abra la ventana de acuñación, no durante ella
7. Para intercambios DEX grandes: verifica el porcentaje de impacto en el precio antes de confirmar; si el impacto en el precio excede del 2% al 3%, reduce el monto del intercambio o divídelo en transacciones más pequeñas
8. Confía en el optimizador de tarifas integrado de tu Plataforma cuando esté disponible; Jupiter, Raydium y Orca ofrecen recomendaciones automáticas de tarifas que se ajustan a las condiciones actuales de la red

⚠️ Nota para desarrolladores

En las dApps en producción, implementa una estimación de unidades de cómputo basada en simulaciones en lugar de límites estáticos. Consulta getRecentPrioritizationFees() de forma dinámica y actualiza tu recomendación de tarifas en cada envío de transacción. Implementa una conmutación por error (failover) de RPC para que tu aplicación cambie a un endpoint de respaldo automáticamente. Nunca reutilices blockhashes en los intentos de reintento.

Preguntas frecuentes: Cinco soluciones para transacciones fallidas en Solana

Cada respuesta a continuación es independiente. No es necesario leer el resto de esta guía para utilizar las preguntas frecuentes.

¿Qué causa que una transacción en Solana falle?

Las transacciones en Solana fallan por cinco razones: vencimiento del blockhash, tarifa de prioridad insuficiente, agotamiento del presupuesto de unidades de cómputo, incumplimiento de la tolerancia al deslizamiento o sobrecarga del nodo RPC. Los fallos a nivel de red requieren aumentar la tarifa de prioridad y volver a enviarla. Los rechazos a nivel de programa requieren ajustar los parámetros de la transacción, como la tolerancia al deslizamiento o el importe del intercambio. Consulta Las 5 causas raíz para obtener una explicación completa de cada una.

Sí. Solana cobra una pequeña Tarifa base por transacción, de aproximadamente 0,000005 SOL, incluso cuando una transacción falla, pero tus tokens y el capital del intercambio no se deducen. Las transacciones descartadas silenciosamente por un nodo RPC sobrecargado antes de llegar a la red no cobran ninguna tarifa, ya que no dejan registro On-Chain. Consulta ¿Sigues pagando tarifas? para obtener instrucciones de verificación.

Una transacción de Solana caduca después de aproximadamente 150 slots, lo que equivale a unos 60 o 90 segundos en condiciones normales de red. Durante periodos de congestión, el tiempo efectivo de vencimiento puede parecer más corto porque los validadores se retrasan en el procesamiento. Después del vencimiento, la transacción se descarta permanentemente y debe volver a enviarse desde cero.

Un blockhash es un código similar a una marca de tiempo incrustado en cada transacción de Solana que demuestra que la transacción se creó recientemente. Los validadores lo utilizan para verificar que la transacción es actual y no ha sido repetida desde una sesión anterior. Los blockhashes caducan después de aproximadamente 150 slots; después de eso, la transacción se rechaza con un error de Blockhash not found o Transaction expired.

Las unidades de cómputo son la medida de Solana de los recursos de procesamiento que consume una transacción. Las transferencias simples utilizan una cantidad pequeña; los intercambios complejos DEX de múltiples saltos utilizan significativamente más. Si una transacción agota su presupuesto de unidades de cómputo antes de completarse, Solana la cancela y devuelve el error Compute budget exceeded. Las interfaces DEX modernas establecen límites de unidades de cómputo automáticamente para la mayoría de los usuarios.

Una tarifa de prioridad es una propina opcional pagada a los validadores en micro-lamports por unidad de cómputo para adelantar tu transacción frente a envíos con tarifas más bajas durante la congestión. La Tarifa base de transacción de Solana es fija y pequeña; la tarifa de prioridad es el componente variable que determina qué tan rápido se procesa tu transacción. Los niveles de tarifas varían según la demanda de la red, por lo que debes usar la función de estimación automática de tu wallet o la API de tarifas de prioridad de Helius para conocer los valores actuales.

Copia la firma de la transacción del historial de transacciones de tu wallet y pégala en Solana Explorer o Solana FM. Las transacciones fallidas muestran un estado de error rojo con el código de error específico. Las transacciones confirmadas muestran un estado de éxito verde. Siempre verifica antes de volver a enviarla para evitar enviar una transacción duplicada.

Tus fondos no necesitan ser recuperados porque nunca fueron enviados. Una transacción fallida de Solana no deduce tus tokens ni el importe del intercambio de tu wallet. La transacción falló antes de la ejecución, por lo que el Balance de tu wallet no cambia, excepto por la pequeña Tarifa base. Tu capital está a salvo.

Solana utiliza un protocolo de reenvío de transacciones llamado Gulf Stream en lugar de una cola de transacciones tradicional. Gulf Stream reenvía las transacciones directamente al siguiente validador esperado antes de que termine el bloque actual. Las transacciones que no pueden procesarse inmediatamente se descartan en lugar de mantenerse en una línea de espera. Este diseño permite el alto rendimiento de Solana, pero significa que las transacciones fallidas requieren un reenvío activo en lugar de una espera pasiva.

El fallo en la simulación de la transacción significa que Phantom realizó una prueba previa al envío de tu transacción y predijo que no tendría éxito. Phantom bloquea el envío para evitar que desperdicies una tarifa en una transacción que fallará. La mayoría de los fallos de simulación indican un problema real con tu configuración, como un deslizamiento insuficiente, un Balance de SOL bajo o un rechazo del programa. Ocasionalmente, los datos de estado desactualizados causan un fallo falso; en ese caso, es apropiado actualizar la página y volver a enviarla una vez.

Añade SOL a tu wallet y asegúrate de que tu Balance supere el importe de la transacción más las tarifas, además de un margen de 0,05 SOL. El error de fondos insuficientes en Solana no siempre significa que no tengas SOL solo para la tarifa. A veces significa que te falta suficiente SOL para cubrir el umbral de exención de alquiler requerido para crear una nueva cuenta de token al recibir un token por primera vez.

Tu capital está a salvo. Los tokens o el SOL que intentabas enviar o intercambiar permanecen en tu wallet exactamente como estaban. Una transacción fallida de Solana no ejecuta la transferencia, el intercambio ni el acuñamiento (mint), por lo que tu Balance no cambia. Solo se puede haber cobrado una pequeña Tarifa base de transacción, normalmente inferior a 0,001 $.

Las transacciones que fallan repetidamente suelen indicar que se está volviendo a enviar la misma configuración incorrecta sin ajustes. Identifica tu error: si es Slippage tolerance exceeded, aumenta el deslizamiento y vuelve a enviarla. Si las transacciones se descartan silenciosamente sin un mensaje de error, tu tarifa de prioridad es demasiado baja. Si status.solana.com muestra un incidente activo, espera a que la red se recupere antes de volver a enviarla.

Los fallos en el acuñamiento (mint) de NFT ocurren porque miles de usuarios y bots envían transacciones simultáneamente durante una ventana de lanzamiento estrecha, saturando tanto los Endpoints de RPC públicos como la cola de validadores. Los validadores descartan las transacciones con tarifas de prioridad bajas para gestionar la carga. Establecer tu tarifa de prioridad en Turbo y cambiar a un proveedor de RPC dedicado antes de que se abra la ventana de acuñamiento mejora significativamente las tasas de éxito. Consulta Fallos de acuñamiento en Magic Eden y NFT para ver el protocolo de preparación completo.

La tolerancia al deslizamiento es el movimiento máximo de precio que aceptarás entre el momento en que solicitas un intercambio y el momento en que se ejecuta. Si el precio del token se mueve más allá de ese umbral, el Contrato inteligente cancela el intercambio automáticamente para protegerte de recibir un precio significativamente peor que el cotizado. Los ajustes típicos oscilan entre el 0,5% para pares de tokens estables y el 2% o 3% para activos volátiles. Establecerlo por encima del 3% al 5% en pares con baja Liquidez aumenta la exposición a ataques de sándwich MEV.

Explora SOL en Bybit

Usa la página de precios de Solana para revisar los datos actuales del mercado de SOL, o accede al mercado de trading spot SOL/USDT si el trading spot coincide con tus objetivos. La actividad de trading en Bybit no es lo mismo que enviar una transacción On-Chain de Solana; es posible que se sigan aplicando tarifas de red al depositar o retirar SOL en la red de Solana.

Cada fallo de transacción en Solana se debe a una de las cinco causas raíz, y cada una tiene una solución específica.

Tu principal está seguro en cualquiera de estos escenarios. Las transacciones fallidas de Solana no pierden tokens permanentemente; solo se consume una tarifa base mínima. Para evitar fallos repetidos, repasa la Lista de verificación previa a la transacción antes de tu próximo intercambio o acuñación sensible al tiempo.

Las rutas de configuración mencionadas en esta guía son precisas a partir de la fecha de publicación y pueden variar según la versión de la billetera o del DEX. Los niveles de tarifa varían con la demanda de la red; utiliza la función de estimación automática de tu billetera o la API de tarifa de prioridad de Helius para los valores actuales. Las referencias de herramientas (Helius, QuickNode, Solana Beach) se presentan como opciones, no como avales.