Ver cómo un swap se pone en rojo es una de las experiencias más frustrantes en Solana, sobre todo en una red que se anuncia como rápida y casi gratuita. El mensaje de error que aparece rara vez explica lo ocurrido en términos con los que alguien ajeno a la ingeniería de protocolos pueda actuar.

Lo alentador es que estos fallos siguen patrones muy predecibles. Cuando sabes distinguir una transacción que la red ha rechazado de una que nunca llegó, la solución correcta casi siempre es un ajuste concreto, y no volver a hacer clic y esperar suerte. 👇

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

Una transacción fallida de Solana es aquella que llegó correctamente a un validador, se incluyó en un bloque y después fue rechazada durante la ejecución porque ya no se cumplía alguna condición de la que dependía. Aun así queda registrada de forma permanente on-chain, con un código de error y registros del programa asociados.

Los wallets suelen mostrar esto como un banner rojo o una simple etiqueta de «fallido» sin más detalles. Para averiguar el motivo de fondo, pega la firma de la transacción en un explorador como Solscan y lee los registros del programa, que indican la instrucción exacta que se revirtió y por qué.

Es fundamental que la ejecución en Solana es atómica. Si cualquier instrucción de la transacción genera un error, se descarta por completo todo cambio de estado que esa transacción habría hecho, de modo que los saldos de tus tokens permanecen exactamente como estaban. Lo único que pierdes es la pequeña comisión pagada por el intento.

Esa atomicidad es una medida de seguridad deliberada y no un defecto del diseño. Garantiza que nunca te quedes a medio intercambio, con tokens deducidos de un lado pero nada recibido en el otro, lo que 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 la interfaz de un wallet, pero tienen causas opuestas y requieren soluciones opuestas. Aprender a distinguirlos es el paso de diagnóstico más útil que tiene a su alcance cualquier usuario de Solana, y solo cuesta atención.

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

El mecanismo detrás de la mayoría de las transacciones fallidas es la caducidad del blockhash. Cada transacción de Solana hace referencia a un blockhash reciente que sigue siendo válido durante aproximadamente 150 bloques, o unos 60 a 90 segundos en tiempo real. Si no la envías dentro de esa estrecha ventana, los validadores la rechazan sin más, una regla que existe para evitar ataques de repetición.

Ejemplo A (fallido): Haces un swap de USDC por SOL en Meteora, pero el precio se mueve más allá de la tolerancia de slippage que configuraste mientras la transacción se está ejecutando, de modo que el programa la revierte. El intento aparece on-chain con un error explícito de slippage y solo te cuesta la comisión de red.

Ejemplo B (descartada): compras un token en Pump.fun durante la fiebre de un lanzamiento, pero tu endpoint RPC va varios slots por detrás de la punta de la cadena y el blockhash caduca antes de que ningún 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 de titular que sugieren que la mitad de las transacciones de Solana fallan son a la vez exactas y casi totalmente irrelevantes en la práctica, porque agrupan enormes volúmenes de spam de arbitraje automatizado con la actividad normal de wallet que generan a diario las personas reales.

Una investigación académica publicada en 2025 zanjó por fin la cuestión con cifras concretas en lugar de estimaciones. Un estudio revisado por pares sobre 1.500 millones de transacciones fallidas en 72 millones de bloques concluyó 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 muchísimo para el contexto. Se sitúa bastante cerca del rango habitual de Ethereum, de 1 a 3 %, y muy por debajo de las tasas de fallos del 21 % y el 15,4 % observadas en Base y Arbitrum, lo que replantea la fama de falta de fiabilidad de Solana como un artefacto estadístico debido sobre todo a bots y no como un problema de experiencia de usuario.

La concentración refuerza la misma idea. Los diez programas que generan más fallos suponen el 77,95 % del volumen total, y solo Raydium Liquidity Pool V4 es responsable del 21,69 %, ya que los bots francotiradores compiten por operar en pools recién creados antes de que se complete su inicialización.

Aun así, la congestión sigue golpeando con fuerza en los periodos de máxima actividad. Cuando se dispara la volatilidad de las memecoin, las tasas de éxito medidas de las transacciones que no son de voto han caído hasta en torno al 76 %, es decir, aproximadamente una de cada cuatro transacciones reales de usuarios falla pese a 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 bastante más informativos de lo que la mayoría de los usuarios cree, y ese mismo conjunto de investigaciones clasificó todos los fallos observados en diez categorías distintas. La distribución resultante está muy sesgada, lo cual es una buena noticia, porque significa que un puñado reducido de soluciones específicas resuelve la gran mayoría de los problemas.

Los tipos de error detrás de los fallos de las transacciones de Solana se desglosan así:

• 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 de protección que incorporan los agregadores de DEX.
• Estado no válido (19,19 %): la transacción se dirigió a una cuenta o a un liquidity pool en un estado que no permitía la operación, a menudo un pool sin inicializar o una cuenta de token congelada.
• Caducidad de validez (17,72 %): el blockhash referenciado caducó antes de que un validador lo procesara, la huella onchain de la congestión, de endpoints RPC retrasados o de una firma lenta en el cliente.
• Cuenta de entrada no válida (3,27 %): Faltaban direcciones de cuenta obligatorias, estaban mal ordenadas o no estaban autorizadas, un problema frecuente en rutas complejas que afectan a 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 fijado en cero en una instrucción de swap de Raydium.
• Sin fondos (2,16 %): el wallet no tenía suficientes SOL para cubrir la transferencia, las comisiones y la renta, el error que afectó de forma más desproporcionada a los usuarios humanos que a los bots.
• Sin recursos (0,49 %): la transacción agotó su presupuesto de cómputo o superó los límites de ejecución de la memoria heap, algo típico de rutas de varios saltos que tocan decenas de cuentas.

Una conclusión merece especial atención de quien se sienta tentado a pagar más sin más. Las transacciones fallidas pagan en realidad comisiones más altas que las exitosas mientras consumen menos unidades de cómputo, y aun así quedan más abajo en los bloques. Gastar dinero para resolver el problema sin dimensionar correctamente el cómputo demuestra no funcionar.

Motivos habituales de fallos en las transacciones de Solana

Traducidas a términos prácticos, esas categorías de error se concentran en un puñado de fallos de configuración y de tiempos que dependen casi por completo de ti como usuario.

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

• Slippage demasiado ajustado: Fijar una tolerancia inferior a la que exige la volatilidad actual garantiza reversiones en tokens de poca liquidez, donde los precios pueden moverse varios puntos porcentuales entre la firma y la ejecución.
• Comisiones de prioridad bajas: Los validadores ordenan las transacciones según el precio por unidad de computación, por lo que una transacción con una oferta insuficiente es superada y queda relegada al fondo de los bloques en periodos de mucha demanda.
• Blockhash caducado: una firma lenta, un RPC con retraso o simplemente dudar ante el aviso de confirmación puede agotar la ventana de validez antes de que la transacción llegue a un líder.
• Excesos de cómputo: las rutas de varios saltos a través de varios pools de exchange descentralizado pueden superar la asignación predeterminada de 200.000 unidades de cómputo por instrucción y abortarse.
• RPC sobrecargado: los endpoints públicos los comparte un enorme número de usuarios y se degradan notablemente durante los lanzamientos, de modo que se pierden transacciones antes de difundirse a los validadores.
• Saldo insuficiente: las comisiones, el alquiler (rent) de las nuevas cuentas de token y las ofertas de prioridad se pagan con SOL, por lo que las wallets que solo tienen el token que se va a intercambiar fallan de inmediato.
• Poca liquidez: las órdenes grandes contra pools poco profundos no se pueden ejecutar a ningún precio aceptable, lo que genera los mismos reversiones de liquidez insuficiente que ya conoces de otras cadenas.
• Cuentas congeladas: los creadores maliciosos de tokens pueden congelar las transferencias después de atraer compradores, un patrón de honeypot que aparece como un error de estado no válido cuando intentas vender.

Cómo solucionar los fallos de transacción en Solana

Una vez que hayas identificado si el problema está en la lógica de ejecución o en la entrega por la red, la solución suele ser un ajuste concreto y no una instrucción general de volver a intentarlo.

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

• Sube el slippage con criterio: Lleva la tolerancia a 1 a 3 % en tokens volátiles, aceptando un precio algo peor a cambio de que se ejecute la operación en lugar de perder otra comisión.
• Ofrece comisiones de prioridad de forma dinámica: en condiciones normales se despejan entre 1.000 y 5.000 micro-lamports por unidad de cómputo, mientras que los lanzamientos y las liquidaciones pueden exigir 100.000 o más.
• Dimensiona con precisión las unidades de cómputo: Simula primero y fija después 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 endpoints dedicados de Helius, Triton o QuickNode transmiten de forma fiable durante la congestión, cuando los nodos públicos por defecto ya están saturados y descartan solicitudes.
• Actualiza antes de reintentar: obtén un nuevo blockhash para cada intento en lugar de reenviar el original, que probablemente haya caducado y volverá a fallar sin avisar.
• Conserva SOL de reserva: Solflare aconseja dejar sin tocar al menos 0,05 SOL, suficiente para cubrir cómodamente las comisiones base, las ofertas de prioridad y cualquier depósito de renta.
• Vista previa antes de firmar: La simulación de la wallet detecta transacciones condenadas al fracaso sin coste, mientras que un fallo onchain sigue costando la comisión base y cualquier oferta de prioridad añadida.

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

El daño económico de una transacción fallida es mínimo, una de las ventajas estructurales reales de Solana frente a cadenas con comisiones más altas. Cada transacción lleva una comisión base de 0,000005 SOL por firma, y ese cargo se aplica tanto si la ejecución termina con éxito como si se revierte a medias.

Los costes adicionales se aplican según la situación, no de forma general. Abrir una nueva cuenta de token requiere un depósito único de renta de unos 0,002 SOL, mientras que cualquier comisión de prioridad que añadas se calcula como el precio de la unidad de cómputo multiplicado por el límite de unidades de cómputo, y dividido después entre un millón.

Desde febrero de 2025, el 100 % de las comisiones de prioridad va directamente a los validadores en lugar de quemarse la mitad, tras la activación del cambio de gobernanza SIMD-0096. La comisión base sigue repartiéndose a partes iguales entre la quema y el productor de bloques que te incluye.

Ejemplo: abres una posición con apalancamiento en SOL a través de una plataforma de contratos perpetuos, el precio se mueve más allá de tu tolerancia mientras la transacción está en curso y esta se revierte. Tu colateral no se toca y pierdes una fracción de céntimo. Para un desglose más completo, consulta nuestra guía sobre las comisiones de gas de Solana.

Cómo cambian el panorama Firedancer y Alpenglow

La propia red está cambiando de formas que atacan directamente la congestión responsable de las transacciones fallidas, lo que hace que operar en 2026 sea una experiencia notablemente distinta del caos de memecoin de principios de 2024 que, en primer lugar, forjó la reputación de Solana como red poco fiable.

1. Firedancer

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

La diversidad de clientes influye directamente en la fiabilidad. Hasta hace muy poco, todos los validadores ejecutaban software derivado de Agave, lo que significaba que un solo error sin descubrir podía detener toda la cadena a la vez. Dos implementaciones realmente independientes eliminan ese punto único de fallo y aportan un valioso margen de rendimiento durante los picos de tráfico.

2. Alpenglow

Alpenglow es el cambio mucho mayor que sigue pendiente. Aprobado por los validadores en septiembre de 2025 con un apoyo del 98,27 %, sustituye por completo tanto a Tower BFT como a Proof of History y busca una finalidad de las transacciones de unos 150 milisegundos, frente a aproximadamente 12,8 segundos con el diseño actual.

En cuanto a las tasas de fallos, hay un detalle que destaca por encima de las cifras de latencia. Alpenglow elimina por completo las transacciones de voto de los validadores del espacio de bloque y, como los votos consumen la gran mayoría del rendimiento bruto de la red, liberar esa capacidad debería reducir de forma notable la congestión que provoca caídas en los picos de demanda.

Sin embargo, el diseño de las comisiones sigue sin resolverse. La comisión base fija por firma de Solana no responde a la demanda de ninguna manera, y un rediseño basado en recursos que fijaría el precio del cómputo y del acceso a cuentas por separado se ha debatido activamente durante 2026 sin producir una especificación definitiva.

Buenas prácticas para evitar fallos en las transacciones en Solana

En Solana, la prevención supera sistemáticamente al diagnóstico, porque los ajustes que provocan los fallos se eligen mucho antes de que algo llegue a un validador. Unos cuantos hábitos adoptados antes de empezar a operar eliminarán la mayoría de los fallos que, de otro modo, te interrumpirían a mitad de sesión y te costarían precios de entrada.

1. Mantén tu configuración al día

Tanto el software desactualizado como la infraestructura pública compartida provocan fallos que no tienen nada que ver con los parámetros de operación que hayas elegido. Resuelve primero esa base:

• Actualiza las wallets con regularidad: Phantom, Solflare y Backpack publican con frecuencia mejoras en la estimación de comisiones, y las versiones antiguas no incluyen las correcciones de compatibilidad para los cambios en el runtime y en los validadores.
• Usa un endpoint privado: El acceso RPC dedicado cuesta poco y elimina la mayor fuente de transacciones fallidas durante lanzamientos y otros eventos de mucho tráfico.
• Borra las sesiones bloqueadas: reiniciar la extensión o el navegador resuelve los estados de conexión almacenados en caché que, sin que lo notes, provocan fallos repetidos mucho después de que la red se haya recuperado.

2. Configura antes de confirmar

La mayoría de las reversiones dependen de los ajustes que eliges antes de firmar, y no de lo que ocurra en la propia red en ese momento:

• Ajusta el slippage a la volatilidad: Los tokens recién lanzados necesitan una tolerancia notablemente más amplia que los pares consolidados, en los que una configuración ajustada te protege sin poner en riesgo de forma significativa la ejecución.
• Simula rutas complejas: Previsualiza swaps que pasan por varios pools, ya que la simulación revela el consumo de cómputo y los problemas de estado de la cuenta sin ningún coste.
• Dota el colchón para comisiones: mantén SOL aparte de tu posición de trading para que los depósitos de alquiler (rent) y las pujas de prioridad nunca compitan con los activos que tienes previsto operar.

3. Elige bien el momento de tus transacciones

El momento en que envías una transacción importa casi tanto como cómo la configuras, porque la congestión de la red se concentra en gran medida en unas pocas franjas predecibles:

• Evita las ventanas de lanzamiento: los lanzamientos de meme coins, los airdrop y las cascadas de liquidación generan el spam de bots que más perjudica a los usuarios corrientes.
• Divide las operaciones grandes: separar las acciones DeFi de varios pasos en transacciones distintas mantiene cada una dentro de los límites de cómputo y aísla cualquier fallo en un solo componente.

Conclusiones

Los fallos de transacción en Solana son baratos, totalmente reversibles y en gran medida evitables una vez que los entiendes. No se mueve nada, no se pierde nada más allá de una fracción de céntimo, y los registros de error asociados a cada intento te indican con precisión qué condición no se cumplió y por qué.

La distinción que conviene interiorizar es la que existe entre rechazo y 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 subir las comisiones cuando lo que hay que hacer es actualizar un blockhash.

Con Firedancer ya activo en mainnet y Alpenglow cerca de su activación, las causas de fallo a nivel de red se reducen de forma constante año tras año. Lo que queda es la configuración, y esa ha sido siempre la parte de la ecuación que depende por completo de ti.