Ver que un swap se vuelve rojo es una de las experiencias más frustrantes en Solana, en particular en una red anunciada como rápida y casi gratuita de usar. El mensaje de error que aparece rara vez explica qué salió mal en términos que alguien ajeno a la ingeniería de protocolos pueda comprender para actuar.

Lo alentador es que estos fallos siguen patrones muy predecibles. Una vez que puedes distinguir una transacción que la red rechazó de una que nunca llegó, la solución correcta es casi siempre un único ajuste específico en lugar de volver a hacer clic y esperar. 👇

¿Qué es una transacción fallida en Solana?

Una transacción fallida en Solana es aquella que llegó con éxito a un validor, se incluyó en un bloque y luego fue rechazada durante su ejecución porque alguna condición de la que dependía dejó de cumplirse. Aun así, queda registrada de forma permanente onchain, con un código de error y registros del programa adjuntos.

Las wallets suelen mostrar esto como una pancarta roja o una etiqueta simple de "fallido" sin más detalles. Para encontrar la causa subyacente, pega la firma de la transacción en un explorador como Solscan y lee los registros del programa, los cuales indican la instrucción exacta que se revirtió y el motivo.

De manera crucial, la ejecución en Solana es atómica. Si cualquier instrucción individual dentro de la transacción genera un error, todos los cambios de estado que esa transacción habría realizado se descartan por completo, por lo que tus saldos de tokens se mantendrán exactamente igual que antes. Lo único que pierdes es la pequeña comisión pagada por el intento.

Dicha atomicidad es una característica de seguridad deliberada y no un defecto de diseño. Garantiza que nunca termines con un swap a medias, con tokens descontados de un lado pero sin recibir nada en el otro, lo cual sería un resultado considerablemente peor que un rechazo limpio y totalmente revertido.

Transacciones de Solana descartadas frente a fallidas

Estos dos resultados parecen prácticamente idénticos desde el interior de la interfaz de una wallet, pero tienen causas opuestas y requieren soluciones contrarias. Aprender a distinguirlos es el paso de diagnóstico más útil disponible para cualquier usuario de Solana, y no cuesta nada más que atención.

Una transacción fallida logró entrar en un bloque y luego fue rechazada por la lógica del programa, dejando un registro permanente. Una transacción descartada nunca llegó al líder de bloque, por lo general porque expiró en tránsito o el nodo RPC receptor estaba saturado, y no te cuesta nada.

El mecanismo detrás de la mayoría de las caídas es la expiración del blockhash. Cada transacción de Solana hace referencia a un blockhash reciente que permanece válido durante aproximadamente 150 bloques, o cerca de 60 a 90 segundos en tiempo real. Si te pierdes esa estrecha ventana, los validores la rechazan de inmediato, una regla que existe para prevenir ataques de repetición.

Ejemplo A (Fallida): Haces un swap de USDC por SOL en Meteora, pero el precio supera tu tolerancia al slippage configurada mientras la transacción está a mitad de ejecución, por lo que el programa la revierte. El intento aparece onchain con un error explícito de slippage adjunto y solo te cuesta la comisión de la red.

Ejemplo B (Descartada): Compras un token en pump.fun durante un frenesí de lanzamiento, pero tu endpoint RPC se retrasa varios slots con respecto a la punta de la cadena y el blockhash expira antes de que cualquier líder vea la transacción. No aparece nada en ningún explorador y no se cobra ninguna comisión.

¿Cuántas transacciones de Solana fallan realmente?

Las cifras principales que sugieren que la mitad de todas las transacciones de Solana fallan son, al mismo tiempo, precisas y casi totalmente carentes de significado en la práctica, ya que agrupan enormes volúmenes de spam de arbitraje automatizado junto con la actividad común de las wallets que las personas reales generan todos los días.

La investigación académica publicada en 2025 finalmente zanjó la cuestión con números concretos en lugar de estimaciones. Un estudio revisado por pares sobre 1.500 millones de transacciones fallidas en 72 millones de bloques descubrió que las cuentas de bots fallaban en un 58,43 %, mientras que las cuentas operadas por humanos fallaban en un porcentaje mucho más modesto del 6,22 %.

Esa cifra humana importa enormemente para poner en contexto la situación. Se sitúa bastante cerca del rango típico de Ethereum, que va del 1 % al 3 %, y cómodamente por debajo de las tasas de fallo del 21 % y el 15,4 % observadas en Base y Arbitrum, lo cual replantea la reputación de falta de fiabilidad de Solana como un artefacto estadístico impulsado principalmente por bots en lugar de un problema de experiencia de usuario.

La concentración refuerza el mismo argumento. Los diez programas que generan más fallos representan el 77,95 % del volumen total, y solo el Raydium Liquidity Pool V4 es responsable del 21,69 % mientras los bots de francotirador compiten por comerciar en pools recién creados antes de que siquiera se complete la inicialización.

Sin embargo, la congestión sigue afectando con fuerza durante los periodos de mayor actividad. Cuando la volatilidad de las memecoins se dispara, las tasas de éxito medidas sin contar los votos han bajado alrededor del 76 %, lo que significa que aproximadamente una de cada cuatro transacciones genuinas de usuarios falla a pesar de los alentadores promedios a largo plazo que arrojan los datos académicos.

Qué muestran los datos sobre por qué fallan las transacciones

Los registros de errores son considerablemente más informativos de lo que la mayoría de los usuarios cree, y el mismo conjunto de investigación clasificó cada fallo observado en diez categorías distintas. La distribución resultante está muy sesgada, lo cual es una buena noticia, ya que significa que un pequeño puñado de correcciones específicas soluciona la gran mayoría de los problemas.

Los tipos de errores detrás de los fallos en las transacciones de Solana se desglosan de la siguiente manera:

• Precio o beneficio no alcanzado (47,99 %): Se superó la tolerancia de slippage o una ruta de arbitraje dejó de ser rentable entre el envío y la ejecución, lo que activó la reversión protectora que integran los DEX aggregators.
• Estado no válido (19,19 %): La transacción se dirigió a una cuenta o liquidity pool en un estado que no permitía la operación, a menudo un pool no inicializado o una cuenta de tokens congelada.
• Caducidad de validez (17,72 %): El blockhash de referencia envejeció antes de que un validador lo procesara, la huella onchain de la congestión, endpoints de RPC lentos o una firma lenta en el lado del cliente.
• Cuenta de entrada no válida (3,27 %): Faltaban direcciones de cuenta requeridas, estaban ordenadas incorrectamente o no estaban autorizadas, un problema frecuente en rutas complejas que interactúan con muchos programas a la vez.
• Parámetros de entrada no válidos (2,55 %): Un argumento quedó fuera del rango que acepta un programa, como un importe mínimo de salida establecido en cero en una instrucción de swap de Raydium.
• Fondos insuficientes (2,16 %): A la wallet le faltaba el SOL necesario para cubrir la transferencia más las comisiones y el rent, el error que afecta de forma más desproporcionada a los usuarios humanos en lugar de a los bots.
• Sin recursos (0,49 %): La transacción agotó su presupuesto de cómputo o superó los límites de tiempo de ejecución en la memoria dinámica (heap memory), algo típico de rutas de múltiples saltos que interactúan con docenas de cuentas.

Un hallazgo merece especial atención por parte de cualquiera que tenga la tentación de simplemente pagar más. Las transacciones fallidas en realidad pagan tarifas más altas que las exitosas a la vez que consumen menos compute units, y aun así terminan más profundo en los bloques. Tirar dinero al problema sin dimensionar el cómputo correctamente demostrablemente no funciona.

Razones comunes de los fallos en las transacciones de Solana

Traduciendo esas categorías de error a términos prácticos, los fallos se agrupan en torno a un puñado de errores de configuración y sincronización que están casi en su totalidad bajo tu control como usuario.

Estas son las causas más frecuentes detrás de las transacciones fallidas en Solana:

• Slippage ajustado: Configurar la tolerancia por debajo de lo que exige la volatilidad actual garantiza reversiones en tokens de baja liquidez, donde los precios pueden moverse varios por ciento entre la firma y la ejecución.
• Priority fees bajas: Los validadores ordenan las transacciones por el precio de las compute units, por lo que una transacción con una oferta baja es desplazada por la competencia y empujada profundamente en los bloques durante períodos de alta demanda.
• Blockhash caducado: Una firma lenta, un RPC con retraso o simplemente dudar ante el aviso de confirmación pueden consumir la ventana de validez antes de que la transacción llegue siquiera a un líder.
• Excesos de cómputo: Las rutas de múltiples saltos a través de varios fondos de decentralized exchange pueden superar la asignación predeterminada de 200 000 compute units por instrucción y abortarse.
• RPC sobrecargado: Los puntos de conexión públicos son compartidos por un número enorme de usuarios y se degradan drásticamente durante los lanzamientos, descartando transacciones antes de que sean transmitidas a los validadores.
• Saldo insuficiente: Las tarifas, el rent para nuevas cuentas de tokens y las pujas de prioridad se deducen de SOL, por lo que las wallets que solo contienen el token que se está intercambiando fallan de inmediato.
• Liquidez escasa: Las órdenes grandes en fondos poco profundos no pueden ejecutarse a ningún precio aceptable, produciendo las mismas reversiones por insufficient liquidity conocidas en otras cadenas.
• Cuentas congeladas: Los desarrolladores de tokens maliciosos pueden congelar las transferencias después de atraer compradores, un patrón de honeypot que surge como un error de estado inválido cuando intentas vender.

Cómo solucionar los fallos en las transacciones de Solana

Una vez que hayas identificado si el problema es la lógica de ejecución o la entrega en la red, el remedio suele ser una configuración específica en lugar de una instrucción general para volver a intentarlo.

Estos ajustes resuelven la mayoría de los fallos en las transacciones de Solana:

• Aumenta el slippage sensatamente: Lleva la tolerancia del 1 % al 3 % para tokens volátiles, aceptando un precio ligeramente peor a cambio de la ejecución en lugar de otra tarifa desperdiciada.
• Puja priority fees de forma dinámica: Las condiciones normales se liquidan entre 1000 y 5000 micro-lamports por compute unit, mientras que los lanzamientos y las liquidation pueden exigir 100 000 o más.
• Dimensiona las compute units con precisión: Simula primero, luego establece el límite cerca del consumo real, ya que el precio compra prioridad mientras que un límite inflado solo desperdicia margen.
• Cambia de proveedor de RPC: Los puntos de conexión dedicados de Helius, Triton o QuickNode se transmiten de manera confiable durante la congestión cuando los nodos públicos predeterminados ya están saturados y descartando solicitudes.
• Actualiza antes de volver a intentarlo: Obtén un nuevo blockhash para cada intento en lugar de reenviar el original, que probablemente haya caducado y volverá a fallar silenciosamente.
• Conserva SOL de reserva: Solflare aconseja dejar al menos 0,05 SOL intactos, lo suficiente como para absorber cómodamente los base fees, las priority bids y cualquier depósito por rent.
• Vista previa antes de firmar: La simulación en el wallet detecta transacciones condenadas al fracaso de forma gratuita, mientras que un fallo onchain sigue costando el base fee y cualquier priority bid adjunta.

¿Cuánto cuesta una transacción fallida en Solana?

El perjuicio financiero de una transacción fallida es mínimo, lo cual constituye una de las verdaderas ventajas estructurales de Solana frente a las cadenas con mayores comisiones. Cada transacción conlleva un base fee de 0,000005 SOL por firma, y dicho cargo se aplica tanto si la ejecución termina teniendo éxito como si se revierte a mitad de camino.

Los costes adicionales se aplican de forma circunstancial y no universal. Abrir una nueva cuenta de token requiere un depósito por rent único de aproximadamente 0,002 SOL, mientras que cualquier priority fee que adjuntes se calcula como el precio por compute unit multiplicado por el límite de compute unit y dividido entre un millón.

Desde febrero de 2025, el 100 % de los priority fees va directamente a los validadores en lugar de quemarse la mitad, tras la activación del cambio de gobernanza SIMD-0096. El base fee en sí sigue dividiéndose a partes iguales entre la quema y el productor del bloque que te incluya.

Ejemplo: Abres una posición de SOL con leverage a través de una plataforma de perps, el precio se mueve más allá de tu tolerancia mientras la transacción está en curso y esta se revierte. Tu colateral permanece intacto y pierdes una fracción de centavo. Para ver un análisis más detallado, consulta nuestra guía sobre gas fees de Solana.

Cómo Firedancer y Alpenglow cambian el panorama

La propia red está cambiando de formas que abordan directamente la congestión responsable de las transacciones descartadas, lo que convierte a 2026 en una experiencia de trading considerablemente distinta al caos de memecoins de principios de 2024 que forjó la reputación de falta de fiabilidad de Solana en un primer momento.

1. Firedancer

Firedancer, el cliente de validación independiente escrito desde cero en C y C++ por Jump Crypto, llegó a mainnet en diciembre de 2025 tras exhaustivas pruebas. A mediados de 2026, aproximadamente el 14 % del stake de la red ejecutaba Firedancer completo, y otro 26 % utilizaba la variante híbrida Frankendancer.

La diversidad de clientes importa directamente para la fiabilidad. Hasta hace muy poco, absolutamente todos los validadores ejecutaban software derivado de Agave, lo que significaba que un solo error por descubrir podía detener toda la cadena de golpe. Dos implementaciones genuinamente independientes eliminan ese punto único de fallo y añaden un valioso margen de rendimiento durante los picos de tráfico.

2. Alpenglow

Alpenglow es el cambio considerablemente mayor que todavía está pendiente. Aprobado por los validadores en septiembre de 2025 con un 98,27 % de apoyo, reemplaza por completo tanto a Tower BFT como a Proof of History, apuntando a una finalidad de transacción cercana a los 150 milisegundos en comparación con los aproximadamente 12,8 segundos del diseño actual.

En lo que respecta específicamente a las tasas de fallo, un detalle destaca por encima de las cifras principales de latencia. Alpenglow elimina por completo las transacciones de votación de los validadores del espacio de bloques y, dado que los votos consumen la gran mayoría del rendimiento bruto de la red, liberar esa capacidad debería reducir de manera significativa la contención que provoca las caídas durante los momentos de máxima demanda.

Sin embargo, el diseño de las comisiones sigue sin estar zanjado. El base fee fijo por firma de Solana no responde a la demanda de ninguna manera, y un rediseño basado en recursos que tarificaría individualmente el cómputo y el acceso a las cuentas ha estado bajo debate activo a lo largo de 2026 sin producir una especificación finalizada.

Mejores prácticas para evitar fallos en las transacciones de Solana

La prevención supera sistemáticamente al diagnóstico en Solana, porque los ajustes que causan los fallos se eligen mucho antes de que algo llegue a un validador. Unos cuantos hábitos establecidos antes de empezar a hacer trading eliminarán la mayoría de los fallos que, de otro modo, te interrumpirían a mitad de sesión y arruinarían tus precios de entrada.

1. Mantén tu configuración actualizada

El software obsoleto y la infraestructura pública compartida provocan fallos que no tienen absolutamente nada que ver con los parámetros de tus operaciones elegidas. Soluciona esa base antes que nada:

• Actualiza los wallets con frecuencia: Phantom, Solflare y Backpack implementan mejoras en la estimación de comisiones de manera constante, y las versiones desactualizadas se pierden correcciones de compatibilidad para cambios en el entorno de ejecución y en los validadores.
• Utiliza un endpoint privado: El acceso RPC dedicado cuesta poco y elimina la mayor fuente individual de transacciones descartadas durante lanzamientos y otros eventos de alto tráfico.
• Limpia las sesiones bloqueadas: Reiniciar la extensión o el navegador resuelve los estados de conexión en caché que provocan silenciosamente fallos repetidos mucho después de que las condiciones de la red se hayan recuperado.

2. Configura antes de confirmar

La mayoría de las reversiones se deciden por la configuración que eliges antes de firmar, más que por cualquier cosa que ocurra en la red en ese momento:

• Ajusta el slippage a la volatilidad: Los tokens de lanzamiento reciente necesitan una tolerancia considerablemente mayor que los pares establecidos, donde una configuración estricta te protege sin arriesgar de forma significativa la ejecución.
• Simula rutas complejas: Previsualiza swaps que involucren múltiples pools, ya que la simulación revela problemas de consumo de cómputo y del estado de la cuenta sin costo alguno.
• Financia el búfer de comisiones: Mantén SOL separado de tu posición de trading para que los depósitos de rent y las pujas de priority fee nunca compitan con los activos que pretendes operar.

3. Calcula bien el momento de tus transacciones

El momento en el que envías una transacción importa casi tanto como la forma en que la configuras, porque la congestión de la red se concentra fuertemente en unas pocas ventanas predecibles:

• Evita las ventanas de lanzamiento: Los lanzamientos de meme coin, los reclamos de airdrop y las cascadas de liquidation generan el spam de bots que deja fuera a los usuarios comunes de la forma más severa.
• Divide las operaciones grandes: Fragmentar acciones de DeFi de varios pasos en transacciones separadas mantiene cada una dentro de los límites de cómputo y aísla cualquier fallo en un solo componente.

Conclusión

Los fallos en las transacciones de Solana son económicos, totalmente reversibles y en gran medida prevenibles una vez que los entiendes. Nada se mueve, nada se pierde más allá de una fracción de centavo, y los registros de errores adjuntos a cada intento te indican con precisión qué condición no se cumplió y por qué.

La distinción que vale la pena internalizar es entre el rechazo y la no entrega. Una transacción fallida significa que tus parámetros eran incorrectos, mientras que una descartada significa que nunca llegó, y confundir ambas lleva a la gente a subir las comisiones cuando deberían estar actualizando un blockhash.

Con Firedancer ya activo en mainnet y Alpenglow acercándose a su activación, las causas de fallo a nivel de red se reducen constantemente año tras año. Lo que queda es la configuración, y esa siempre ha sido la parte de la ecuación que está enteramente bajo tu propio control.