Transacción de Solana fallida: cómo saber si tu swap ha pasado de verdad

Si tu swap en Solana aparece en rojo en el explorador, la respuesta corta es esta: la transacción se incluyó en un bloque, pero su instrucción no se ejecutó. Tu saldo sigue igual, la comisión se ha cobrado de todos modos y un segundo intento está permitido. Con qué frecuencia ocurre lo midió cryptoticker.io por su cuenta el 14 de septiembre de 2026: en 36 bloques consecutivos de la cadena principal de Solana falló entre una de cada ocho y una de cada dos transacciones, según el bloque.

No es un estado de excepción ni una caída de la red. Es el funcionamiento normal de una cadena en la que buena parte del tráfico procede de programas de negociación automatizados que pierden a propósito más veces de las que ganan. Para ti como inversor eso tiene una consecuencia práctica: una línea roja en el explorador casi nunca significa que algo vaya mal en tu cartera digital.

Transacción de Solana fallida: qué significa realmente el estado

Una transacción de Solana salva dos obstáculos separados. El primero es la inclusión en un bloque: un validador recibe tu transacción, comprueba la firma y la escribe en la siguiente ranura de la que se encarga. El segundo obstáculo es la ejecución: el programa al que se dirige procesa la instrucción y decide si es válida.

Fallida significa en Solana siempre que el primer obstáculo se superó y el segundo no. La transacción queda de forma permanente en la cadena, con marca temporal, firma y objeto de error. Es, por tanto, algo distinto de una transacción que nunca llegó: esa no aparece en absoluto en el explorador, porque se descartó antes de que ningún validador la escribiera en un bloque.

Esa diferencia importa más de lo que parece. En Bitcoin una transacción se queda atascada en la mempool y espera confirmación, a veces durante horas. En Solana ese estado de suspensión apenas existe: en pocos segundos queda decidido si tu transacción tuvo éxito, falló o ni siquiera llegó a incluirse.

Por qué tu saldo sigue igual tras un fallo

Solana ejecuta cada transacción de forma atómica. O pasan todas las instrucciones que contiene, o no pasa ninguna. Si una instrucción se interrumpe con un error, el entorno de ejecución deshace todos los cambios de cuenta de la transacción. El intercambio no se produce, los tokens se quedan donde estaban.

Lo que no se deshace es la comisión. Es el precio de que los validadores hayan comprobado tu transacción y dedicado tiempo de cálculo, y ese esfuerzo se ha producido con independencia de que la instrucción resultara válida al final.

Nuestra propia medición: cuántas transacciones de Solana fallaron en la ventana analizada

Para este artículo analizamos el 14 de septiembre de 2026 tres ventanas temporales separadas de la cadena principal de Solana, todas en la época 1034 en torno a la ranura 446.981.000. Consultamos el punto de acceso RPC público de la red y examinamos el objeto de error de cada una de las transacciones de esos bloques.

Las transacciones de voto de los validadores quedaron fuera del cómputo. Suponen en Solana buena parte del volumen, funcionan de forma totalmente automática y no fallan prácticamente nunca. En nuestra primera ventana eran 9.390, de las cuales fallaron 36, una tasa del 0,38 %. Quien las incluye obtiene una cifra que carece de sentido para los usuarios.

Quedan las transacciones que personas y programas de negociación envían de verdad. De esas analizamos 17.987 repartidas en 36 bloques:

• Ventana 1, 14 bloques, 7.905 transacciones: 41,9 % fallidas
• Ventana 2, 10 bloques, 4.133 transacciones: 22,0 % fallidas
• Ventana 3, 12 bloques, 5.949 transacciones: 29,6 % fallidas

Sumando las tres ventanas resulta un 33,2 %. Esa cifra no debe leerse como una constante. Algunos bloques quedaron en el 13,2 % y otros en el 66,1 %, y la horquilla entre las tres ventanas muestra cuánto oscila el valor en pocos minutos. Lo sólido es el orden de magnitud: a grandes rasgos, una de cada tres transacciones sin voto en Solana no pasa.

Por qué una transacción de Solana fallida cuesta comisiones igualmente

La comisión base en Solana es de 5.000 lamports por firma. Un lamport es una milmillonésima de SOL, de modo que la comisión base equivale a 0,000005 SOL. Con un precio del SOL de 87,79 euros el 14 de septiembre de 2026 según CoinGecko, eso son unos 0,0004 euros, una fracción de céntimo.

En nuestra tercera ventana se pagaron en total 0,1371 SOL en comisiones. De esa cantidad, 0,0416 SOL correspondieron a transacciones que después fallaron, una proporción del 30,4 %. Convertido, son unos 3,65 euros en doce bloques, un orden de magnitud que, extrapolado a un día, cuenta para la red y no cuenta para ti en lo personal.

El daño económico de un fallo está, por tanto, en otra parte. Lo que duele es la cotización más que la comisión: si tu venta falla a un precio determinado y vuelves a enviarla treinta segundos después, operas al precio que rija entonces. Quien falla varias veces seguidas en un mercado rápido paga la diferencia.

Comisión de prioridad y tasa de fallo: qué dice la medición sobre el recargo

La regla general extendida dice que ante un problema basta con subir la comisión de prioridad. Una comisión de prioridad es un recargo voluntario sobre la comisión base con el que señalas al validador que procese tu transacción de forma preferente. En nuestra tercera ventana calculamos para cada una de las 5.949 transacciones el recargo por encima de la comisión base y obtuvimos la tasa de fallo por tramo de precio.

El resultado va en contra de la regla general. Las transacciones sin recargo alguno fallaron en nuestra ventana con menos frecuencia, y las de recargo pequeño con más. Dentro del grupo que paga, la tasa de fallo baja a medida que sube el recargo, pero nunca cae al nivel del grupo que no paga nada.

De ahí no se sigue que un recargo perjudique. Lo que medimos aquí es una composición y no un efecto. Quien paga un recargo suele tener un motivo: compite contra otros programas por el mismo precio y asume que perderá la carrera a menudo. Quien no paga ninguno envía normalmente una simple transferencia, donde no hay nada que perder. Los dos grupos hacen cosas distintas, y eso explica la diferencia mejor que el precio.

En la práctica esto significa que un recargo más alto te ayuda a que te incluyan cuando la cadena está saturada. Contra una instrucción rechazada por su contenido no sirve de nada. El recargo mediano en nuestra ventana fue de 163 lamports, el percentil noventa de 12.011 lamports, y el 31,0 % de todas las transacciones no pagó recargo alguno.

Leer un InstructionError: qué revelan el índice de error y el código propio

Si pulsas en el explorador sobre una transacción fallida, ves un objeto de error con una forma fija, por ejemplo InstructionError: [3, {"Custom": 6001}]. Contiene dos datos, y ambos son útiles.

El primer número es el índice de error: la posición, contada desde cero, de la instrucción de tu transacción que se ha interrumpido. Un tres significa que las tres primeras instrucciones se ejecutaron y la cuarta falló. En un swap las primeras instrucciones suelen ser preparativos, como fijar el presupuesto de cálculo, y la instrucción de negociación propiamente dicha va más atrás.

El segundo dato es el código propio: un número de error que no procede de la red, sino del programa que ha rechazado la instrucción. El mismo número significa cosas distintas en dos programas distintos. Los códigos más frecuentes en nuestra primera ventana fueron el 11 con 631 apariciones, el 6001 con 394 apariciones repartidas en dos índices de error, el 1 con 173 y el 7 con 124.

Códigos de error de Anchor a partir de 6000: por qué el número solo no explica nada

Una parte de estos códigos se puede situar sin conocer el programa concreto. Muchos programas de Solana están construidos con el marco de desarrollo Anchor, que asigna rangos numéricos con un esquema fijo: a partir de 100 los errores de instrucción, a partir de 2000 los de condición, a partir de 3000 los de cuenta y a partir de 6000 empiezan los errores propios de cada programa.

Un código como el 6001 procede, por tanto, del rango que el programa ha ocupado por sí mismo. Qué significa en concreto figura en la descripción de interfaz de ese programa, que el explorador muestra también en los programas conocidos. Los códigos bajos como el 1 o el 11 vienen en cambio casi siempre de programas ajenos a ese marco, por ejemplo la gestión de tokens de la red.

Para ti eso significa: anota el índice de error y el código, pero no deduzcas una causa a partir del número por sí solo. La correspondencia la da el explorador, no la cifra.

Comprobar tú mismo el estado de la transacción: firma, explorador y getSignatureStatuses

Antes de repetir una transacción, determina su estado. Un segundo intento mientras el primero sigue en curso puede llevar, en el peor de los casos, a que pasen los dos y acabes intercambiando por duplicado.

La vía sencilla pasa por la firma, el identificador único de tu transacción. Toda cartera la muestra tras el envío, casi siempre como una cadena larga con un enlace al explorador. Si encuentras allí la firma con una marca verde, la operación se ha realizado. Si figura como fallida, ha fracasado de forma definitiva y puedes volver a enviar sin riesgo.

Si no encuentras la firma en absoluto, tu transacción nunca llegó a incluirse en un bloque. También entonces un segundo intento es seguro, porque cada transacción de Solana contiene un hash de bloque reciente y caduca en cuanto este es demasiado antiguo. Esa ventana es corta y ronda el minuto y medio.

Quien necesite más detalle consulta el estado directamente a la red. El método RPC getSignatureStatuses de la documentación de Solana devuelve para una firma el grado de confirmación y, si existe, el objeto de error. Es el mismo conjunto de datos del que procede nuestra medición.

Qué vista te ofrece tu cartera varía bastante. Algunos programas muestran solo «correcta» o «fallida», otros presentan directamente el código de error y el paso de instrucción afectado. Echar un vistazo a la comparativa de carteras de software merece la pena también desde este punto de vista.

Slippage, hash de bloque y saldo de la cuenta: las causas más habituales

Tres causas explican la mayor parte de los fallos que los inversores particulares sufren realmente.

La primera es el límite de slippage: el rango de precio que aún aceptas en un intercambio. Los programas de negociación en Solana comprueban ese límite al final del cálculo. Si la cotización se ha movido entre el envío y la ejecución más de lo permitido, la instrucción se interrumpe. Es una función de protección y no un defecto. Un límite muy estrecho te protege de precios malos y a la vez eleva el número de fallos.

La segunda es el hash de bloque caducado. Cada transacción remite a un bloque producido hace poco y solo es válida durante un número limitado de bloques posteriores. Si confirmas en tu cartera con retraso, porque has dejado el dispositivo a un lado entre medias, puede caducar antes de llegar. En ese caso ni siquiera aparece en el explorador.

La tercera es la falta de saldo en la cuenta, y no del token negociado sino de SOL. Toda transacción necesita SOL para la comisión, y abrir una cuenta de tokens nueva exige además un depósito mínimo. Quien intercambia todo su SOL no puede enviar después ni una sola transacción. Dejar una pequeña reserva en la cuenta evita esa situación.

Si tu capital procede de una plataforma de negociación, antes del primer intercambio conviene mirar qué vías de retirada ofrece tu proveedor y qué comisión cobra por ellas. Nuestra comparativa de exchanges de criptomonedas ordena a los proveedores habituales según esos puntos.

Formato de transacción v1: qué cambia la actualización de Solana y qué no

Desde el 9 de septiembre de 2026 está activo en Solana un nuevo formato de transacción que eleva el tamaño máximo de una transacción de 1.232 a 4.096 bytes. Ya describimos el cambio y sus consecuencias con detalle de antemano. Nuestra medición se sitúa cinco días después y muestra una cadena en funcionamiento normal.

El formato cambia poco la tasa de fallo, y eso era de esperar. Una transacción mayor puede contener más instrucciones, pero con ello no se acepta antes. Que un programa rechace tu intercambio porque el precio se ha escapado no depende de cuántos bytes ocupe la instrucción.

La siguiente intervención de calado es el mecanismo de consenso Alpenglow, anunciado para octubre de 2026, que debe acortar de forma notable el tiempo hasta la firmeza de una transacción. Quien opera un nodo propio tiene que prepararse; para ti como usuario el proceso no cambia. También aquí vale lo mismo: una firmeza más rápida acorta la espera, no convierte una instrucción rechazada en válida.

Límites de la medición: qué no muestra este análisis

Nuestro muestreo abarca 36 bloques de tres ventanas temporales de un solo día. Basta para acreditar el orden de magnitud y no basta para afirmar nada sobre una media semanal o mensual. La horquilla del 13,2 al 66,1 % entre bloques concretos muestra la rapidez con que se mueve el valor.

Tampoco pudimos determinar qué parte de las transacciones fallidas procede de particulares y cuál de programas de negociación automatizados. Esa distinción no se extrae con limpieza de los datos de bloque, porque ambos se dirigen a los mismos programas. La valoración extendida de que la mayor parte corresponde al arbitraje automatizado encaja con el patrón de nuestros datos, pero con este método no podemos acreditarla.

La tasa de fallo real para una persona que lanza un swap de vez en cuando debería situarse, por tanto, bastante por debajo de nuestro valor global. Cuánto por debajo queda abierto.

Lo que no cambia es el mecanismo, y ese es el contenido propio de este artículo: inclusión y ejecución son dos pasos, solo el segundo decide tu intercambio, y el explorador te dice con claridad cuál de los dos ha fallado.

Este análisis lo elaboró cryptoticker.io el 14 de septiembre de 2026.

Comprobar la tasa de fallo de Solana: lo que te llevas

1. Comprueba la firma antes de volver a enviar. Marca verde significa realizada, marca roja significa fallida de forma definitiva, ninguna entrada significa que nunca llegó. En los tres casos sabes si un segundo intento intercambiaría por duplicado. Qué cartera te muestra siquiera el código de error y el paso de instrucción figura en la comparativa de carteras de software.
2. Trata el límite de slippage como un ajuste y no como una fuente de errores. Si tu intercambio falla varias veces en el mismo punto, el límite es demasiado estrecho para el movimiento de mercado actual. Ampliarlo significa más riesgo de precio, estrecharlo significa más fallos. Quien intercambia importes elevados con regularidad revisa las condiciones de los mercados en la comparativa de exchanges.
3. Mantén una reserva de SOL en la cuenta. Sin SOL para la comisión y el depósito de cuenta no pasa ninguna transacción, tampoco aquella con la que quieres resolver el problema. Quien deja sus intercambios en automático debería reservar ese colchón de forma fija; qué herramientas lo contemplan lo muestra la comparativa de bots de trading.

(14 de septiembre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)