Por qué una transacción de Ethereum queda pendiente: orden de nonce e intentos de reemplazo o cancelación

Después de firmar una transacción de Ethereum, una cartera puede enviarla a un cliente de ejecución o a un servicio de retransmisión. El nodo que la recibe puede propagarla a otros nodos, y un proponente de bloque podría incluirla más adelante en un bloque. Hasta entonces, la transacción no cambia el estado de la cadena canónica. Si una cartera o un explorador muestra «pending» o «pendiente», normalmente significa que ese servicio conoce la transacción, pero aún no la ha visto confirmada dentro de un bloque. No significa que toda la red comparta una única cola. La guía de transacciones de Ethereum.org explica el proceso desde la firma y propagación hasta la inclusión en un bloque.

Una transacción puede estar esperando por distintos motivos. El límite máximo de comisión quizá no se ajuste a las condiciones del bloque, o puede que siga sin resolverse una transacción anterior de la misma cuenta. También es posible que el nodo que consultas no haya recibido la transacción, que la cartera muestre datos antiguos o que solo muestre la información de un proveedor concreto. Cada causa requiere una comprobación distinta. Aumentar la comisión no corrige haber elegido la red equivocada. Volver a enviar el mismo pago sin revisar el estado del primero puede hacer que lo pagues dos veces.

«Pendiente», «confirmada», «finalizada» y «fallida» no son el mismo estado. El hash de la transacción puede aparecer antes de que haya un recibo disponible. El recibo solo se puede consultar cuando la transacción está incluida en un bloque. Después, los bloques de Ethereum atraviesan estados del proceso de consenso. Las carteras y los exploradores pueden usar estos términos de forma distinta, así que revisa el hash, el bloque, el recibo y el estado actual de la cadena en vez de fiarte de una etiqueta breve en pantalla.

Una cuenta externa normal de Ethereum (EOA) tiene un nonce que establece el orden de sus transacciones. El nonce es un contador propio de la cuenta; no es una comisión, una marca de tiempo ni un hash único de transacción. La cadena acepta la transacción cuyo nonce coincide con el siguiente valor esperado en el estado de la cuenta. Una misma cuenta no puede ejecutar dos transacciones con el mismo nonce en la cadena canónica. La guía de cuentas de Ethereum.org describe el nonce como el contador de transacciones de una cuenta y como una medida para ayudar a evitar ataques de repetición.

Supongamos que el siguiente nonce disponible de una cuenta es 41. La siguiente transacción válida que envíe esa cuenta usará el nonce 41 y, una vez incluida y procesada, la siguiente usará el nonce 42. El nonce pertenece a la cuenta emisora, no a la dirección destinataria. Cada cuenta tiene su propia secuencia, por lo que dos cuentas distintas pueden tener al mismo tiempo una transacción con nonce 41.

Puedes firmar una transacción con un nonce superior al nonce actual en la cadena, pero no puedes saltarte el orden al ejecutarla. Primero debe consumirse el nonce anterior que falta. Una transacción que reutiliza un nonce ya consumido por la cuenta es antigua y no puede ejecutarse como una transacción nueva. Esta regla hace que las transacciones de cada cuenta se procesen en orden, aunque se propaguen en momentos diferentes a través de varios nodos.

La regla del nonce se aplica a las transacciones EOA normales de la capa de ejecución de Ethereum. No describe de una vez el comportamiento de todos los sistemas de abstracción de cuentas, secuenciadores de rollups u otras cadenas. Los sistemas de cuentas inteligentes pueden añadir su propio orden de operaciones y reglas de nonce, que se explican más adelante.

Ethereum no tiene una única sala de espera sincronizada que todas las carteras, nodos, exploradores de bloques y proponentes vean de la misma manera. Cada cliente de ejecución guarda localmente las transacciones que recibió y considera válidas según sus límites y políticas. Un nodo puede conocer una transacción que otro no tiene. La documentación de la RPC txpool de Geth muestra los grupos locales pending y queued de ese cliente y explica que puede haber varios candidatos para el mismo emisor y nonce.

En Geth, pending suele referirse a las transacciones que se pueden procesar en orden de nonce según el estado actual de la cuenta. queued se refiere a transacciones posteriores que esperan a que se cubra un hueco de nonce. Es una distinción de la interfaz del cliente, no un estado con nombre que las reglas de consenso impongan a todo el software. Algunas carteras llaman «pending» a toda su lista de transacciones sin confirmar, y algunos exploradores solo muestran las transacciones observadas por su proveedor de datos.

Por ejemplo, si un nodo conoce una transacción con nonce 41 y otra con nonce 43, no puede ejecutar la 43 antes que la 42. Puede dejar la 43 en cola hasta que llegue la 42 o cambie el estado de la cuenta por otra vía. En cambio, otro nodo que no haya recibido la 43 ni siquiera la mostrará. Si dos exploradores muestran una transacción como «pendiente» o «no encontrada» de forma distinta, ninguna de las dos pantallas demuestra por sí sola qué han recibido todos los validadores.

Algunos clientes guardan más de un candidato de transacción sin confirmar para el mismo emisor y nonce. Son alternativas que compiten por el mismo número de secuencia, no transacciones que se vayan a ejecutar todas en orden. La capacidad del pool, el tiempo que conserva las transacciones y las condiciones de reemplazo son políticas de cada implementación y pueden cambiar según la versión del software. Por ejemplo, la configuración del pool de transacciones de Geth incluye un umbral de aumento de precio que usa ese cliente. No lo confundas con una regla de comisiones aplicable a todas las transacciones de Ethereum. Consulta el alcance de los ajustes en la referencia de opciones de línea de comandos de Geth.

Supongamos que el siguiente nonce en la cadena de una cuenta es 41. La cuenta propaga la transacción A con nonce 41 y después envía la transacción B con nonce 42. Si A no se resuelve, B no puede aplicarse primero. B puede quedarse en la cola local, aparecer como pendiente solo en la cartera o no mostrarse en un explorador que aún no la haya recibido. Lo que importa es el orden de los nonces, no el orden en que la cartera creó o mostró ambas transacciones.

Si A se incluye más adelante, el nonce de la cuenta avanza a 42 y B puede ejecutarse si cumple sus propios requisitos de validez, comisión y política del pool. Si A, con nonce 41, se reemplaza por otra transacción válida, la transacción de reemplazo ocupa esa secuencia si se incluye. Si otra transacción de la cuenta ya consumió el nonce 41, los candidatos anteriores con ese nonce quedan obsoletos y ya no pueden ejecutarse después.

Por eso, enviar una transacción nueva con un nonce superior normalmente no libera una transacción atascada. Solo añade otra transacción detrás de la secuencia que falta. Cancelar B, que es posterior, tampoco resuelve A. Primero localiza el nonce sin resolver más bajo de la cuenta y comprueba su estado antes de reemplazarlo.

Un hueco de nonce puede ser breve o prolongarse. Quizá la transacción anterior no llegó al nodo que consultas, su comisión no resulte atractiva en las condiciones actuales o se haya eliminado del pool de un nodo concreto. La cartera también podría mostrar como en cola una transacción creada en otro dispositivo. La pantalla por sí sola no permite saber cuál es el caso. Compara el nonce confirmado de la cuenta, el hash de la transacción y los resultados de varias consultas fiables.

El orden de nonce y las condiciones de comisión son restricciones distintas. Una transacción con el siguiente nonce correcto puede esperar si no cumple las condiciones para entrar en un bloque. A la inversa, una transacción con nonce posterior no puede adelantarse solo por ofrecer una propina mayor. Aumentar la comisión de la transacción con nonce 42 no elimina la de nonce 41.

En una transacción EIP-1559 normal, la comisión máxima debe cubrir la comisión base del bloque en el que se incluya; la comisión de prioridad puede influir en la selección del proponente del bloque. Mientras la transacción espera, pueden cambiar la comisión base y el espacio disponible en los bloques. La comisión máxima es un límite y subirlo no garantiza la inclusión en un momento concreto. La guía de comisiones de gas de Ethereum explica sus componentes y cómo se calcula la comisión efectiva.

Un nodo o una cartera también pueden aplicar sus propios umbrales de propagación y reemplazo. Esa política determina qué acepta o retransmite un servicio concreto; no es una regla de consenso que todo el mundo deba seguir. Por ejemplo, Geth puede configurar el umbral de aumento de precio que se usa para reemplazar una transacción pendiente en su propio pool. Otros clientes, proveedores, carteras y versiones del software pueden comportarse de otra forma. No consideres un porcentaje de comisión que recuerdes o un tiempo de espera fijo como una garantía de toda la red.

Si estás esperando porque hay un nonce inferior sin resolver, busca primero la transacción que ocupa esa secuencia. Si parece que la causa es no cubrir la comisión base actual, entiende los campos de comisión antes de cambiarlos. La guía de gas enlazada sirve para calcular comisiones; este artículo se centra en el problema independiente del orden de la cuenta.

La opción «acelerar» de una cartera suele crear una nueva transacción con la misma cuenta y el mismo nonce, pero con ajustes de comisión distintos. Dos candidatos con el mismo nonce compiten entre sí, porque la cuenta solo puede ejecutar una transacción en esa secuencia. Si los pools de transacciones pertinentes aceptan el reemplazo y la nueva transacción se incluye en un bloque, puede ocupar ese nonce; la transacción original no puede ejecutarse junto a ella en la cadena canónica. La ayuda de MetaMask sobre transacciones pendientes explica que la función de acelerar de su producto vuelve a enviar la transacción con el mismo nonce y una comisión más alta.

Una transacción de reemplazo puede conservar el destinatario y la acción de la original y cambiar solo los campos de comisión, pero no lo des por hecho sin revisar la pantalla. Cada cartera se implementa de manera distinta y puede mostrar otras entradas o usar un nombre diferente para la función. Antes de firmar, comprueba la cuenta emisora, el nonce, la dirección destinataria, el importe y los datos del contrato. Si cambia la acción de la transacción, no se trata de un simple ajuste de comisión.

No se garantiza que el reemplazo se acepte en todas partes ni que se incluya pronto. La original quizá ya esté en un bloque, o un nodo puede rechazar el reemplazo según su propia política. Las condiciones del reemplazo pueden seguir sin resultar atractivas para el proponente del bloque o quizá no se hayan propagado al nodo que consultas. Si la transacción original ya se confirmó, no puedes revertirla enviando una nueva con un nonce consumido; normalmente se rechazará por usar un nonce antiguo.

Aquí, «reemplazo» significa una transacción en competencia con la misma cuenta emisora y el mismo nonce. No apliques a Ethereum los procedimientos RBF o CPFP de Bitcoin. Bitcoin tiene otra estructura de transacciones y sus métodos de ajuste de comisión no describen cómo se procesan las transacciones de cuentas de Ethereum.

Después de propagar una transacción de Ethereum firmada no existe un comando de deshacer a nivel de protocolo que la retire de todos los nodos. Algunas carteras ofrecen una función de cancelación mientras la transacción no se haya confirmado. Normalmente intenta propagar otra transacción desde la misma cuenta y con el mismo nonce. Un método común de algunas carteras consiste en crear una transacción de importe 0 a tu propia dirección. Si el candidato de cancelación se acepta antes que el original y entra en un bloque, consume el nonce, de modo que el candidato original ya no puede ejecutarse después. La forma exacta de crearla y su disponibilidad dependen de la cartera.

La transacción original y el candidato de cancelación compiten entre sí. Si la original se incluye primero, la cancelación posterior no puede deshacer lo ocurrido. Si no se acepta ni se incluye ninguna de las dos, el nonce puede seguir sin resolverse. Ni pulsar el botón de la cartera ni recibir una notificación de éxito demuestran que haya ganado el candidato de cancelación. Comprueba el nuevo hash y el estado de la cadena canónica. La guía de MetaMask también limita la función a intentar cancelar una transacción que sigue pendiente y explica que una confirmada no se puede cancelar.

Antes de firmar una cancelación, comprueba que usa la misma cuenta y el mismo nonce que la transacción objetivo, y revisa todos los campos que muestra la cartera. Si se incluye, podrías tener que pagar una nueva comisión de red. Según la política del pool, el candidato de cancelación también podría esperar o no reemplazar la transacción original. Aunque la cartera indique «cancelada», eso no significa que el protocolo haya revertido una transacción ya procesada. Comprueba qué transacción consumió el nonce antes de valorar el resultado.

Si la transacción ya se ejecutó, por ejemplo al aprobar un token, llamar a un contrato o transferir un activo, cancelar una transacción posterior no revierte ese cambio de estado. Algunas acciones de contratos pueden tener una función de seguimiento independiente, pero su disponibilidad y resultado dependen del contrato. No firmes una transacción desconocida solo porque la pantalla la llame «cancelar».

Una transacción incluida en un bloque tiene información del bloque y un recibo. Si la ejecución tiene éxito, puede aplicarse el cambio de estado previsto. Si la ejecución de la EVM revierte, se deshacen los cambios de estado de esa ejecución, pero se consume el nonce de la cuenta y puede haber un coste de gas. Comprueba el recibo y el estado de ejecución en lugar de deducir el éxito de una notificación de la cartera. La guía de transacciones de Ethereum.org y la guía de gas explican la diferencia entre inclusión y resultado de ejecución.

«Eliminada» o «no encontrada» suele ser un estado que informa una cartera, un explorador, un proveedor RPC o un pool local concreto. Esa etiqueta por sí sola no demuestra que el protocolo cancelara la transacción ni que el nonce esté libre. Otro nodo puede conservar la transacción y la cartera puede volver a propagar una transacción firmada. A la inversa, aunque no aparezca en las pantallas consultadas, el nonce confirmado de la cuenta puede seguir igual.

Si no encuentras el hash, comprueba que seleccionaste la cadena correcta y la cuenta desde la que se creó la transacción. Compara el nonce actual de la cuenta en la cadena con el nonce de la transacción y consulta las transacciones recientes de la cuenta emisora. Una respuesta nonce too low es una pista de que, desde el punto de vista del endpoint consultado, el nonce podría haberse consumido ya; no es una indicación para repetir la misma solicitud sin parar. Averigua qué transacción usó ese nonce y si su bloque sigue en la cadena canónica.

Incluso una transacción incluida puede verse afectada por una reorganización breve antes de que la cadena se estabilice. La cartera y el explorador pueden corregir lo que muestran cuando cambian los datos observados. Si se trata de una transferencia importante, sigue el umbral de confirmaciones del servicio receptor y, cuando sea necesario, comprueba una finalización por consenso más sólida. «Se vio en un bloque» no significa lo mismo que «no se puede revertir bajo ninguna circunstancia».

Empieza por confirmar la cadena, la cuenta emisora y el hash correctos. Busca el hash en un explorador fiable de esa red y comprueba si hay recibo, el nonce, si la ejecución tuvo éxito y qué transacciones posteriores envió la cuenta emisora. Para consultar una transacción no tienes que revelar ni escribir tu frase semilla. Una dirección pública y el hash bastan para consultar los datos de una cadena pública.

Si no aparece el hash, compara el nonce confirmado más reciente de la cuenta con el que muestra la cartera. Los desarrolladores y operadores de nodos pueden consultar eth_getTransactionCount con las etiquetas de bloque latest y pending. La referencia JSON-RPC de Ethereum.org define latest como el estado del bloque más reciente y pending como el estado pendiente. El valor pending también es una observación del endpoint RPC concreto y puede diferir entre proveedores. La mayoría de los usuarios puede obtener las mismas primeras pistas de la actividad de la cuenta en su cartera y de un explorador fiable sin ejecutar comandos.

Revisa el nonce más bajo que aún no se haya consumido. Si la transacción original sigue visible y tu cartera admite reemplazos, revisa los campos y la configuración de comisión del reemplazo antes de firmar otra vez. Si no ves la original, no supongas que desapareció de la red: pregunta a la cartera o al proveedor RPC cómo gestionan el reenvío y el reemplazo. Si el nonce ya se consumió, averigua primero qué transacción lo usó y después decide qué hacer. Enviar varias transacciones con nonces superiores puede alargar la cola sin resolver el primer hueco.

Este artículo trata las transacciones normales de cuentas de propiedad externa de Ethereum. Los sistemas de abstracción de cuentas pueden enviar UserOperations a través de un bundler, y las cuentas inteligentes pueden usar claves y secuencias de nonce más complejas que un único contador sencillo. EIP-4337 define la estructura de nonce utilizada por esas operaciones, por lo que una cartera de abstracción de cuentas puede comportarse de forma distinta al ejemplo EOA de este artículo. Para revisar la red de destino, la dirección y el estado de la transferencia, consulta la lista de verificación de transferencias de criptoactivos.