Ciclo de vida de una transacción en MetaMask: diagnosticar transacciones pendientes, fallidas y atascadas

Qué es realmente una transacción de MetaMask

MetaMask es una billetera de autocustodia: guarda tus claves localmente, construye una transacción, te pide que la firmes y difunde el payload firmado a un endpoint RPC. La billetera no mina, ordena ni confirma transacciones. Todo lo que ocurre después de la difusión depende de las reglas del mempool de la red, el precio del gas al que te comprometiste y el proveedor RPC que aceptó el payload.

Esa separación es importante para la solución de problemas. Una transacción que parece atascada en MetaMask puede que ya esté incluida en la cadena, puede estar en un mempool, puede haber sido rechazada por el endpoint RPC antes de llegar a la red, o puede que nunca se haya firmado. Cada caso tiene una solución diferente, y la interfaz de la billetera por sí sola no siempre puede decirte en cuál estás.

Este artículo cubre el ciclo de vida completo para redes EVM y te ofrece un procedimiento de diagnóstico que utiliza el hash de la transacción, el nonce de la cuenta y una consulta RPC independiente como evidencia. No recomienda una configuración específica de billetera ni un proveedor; para la selección de endpoints, el Asistente RPC cubre opciones concretas de red.

• Lado de la billetera: custodia de claves, construcción de transacciones, firma, historial de actividad local.
• Lado de la red: admisión en el mempool, mercado de gas, inclusión en bloques, profundidad de confirmación.
• Lado del RPC: aceptación de la difusión, consultas de estado y si el endpoint está sincronizado y saludable.

Supuestos y requisitos previos

El procedimiento asume que tienes el hash de la transacción (también llamado ID de transacción) de la pestaña Actividad de MetaMask, la dirección de la cuenta que la envió y acceso a al menos un endpoint RPC para la misma red. También debes saber a qué red se dirigió la transacción, porque una transacción difundida en una cadena no se puede encontrar en otra aunque la dirección sea idéntica.

No necesitas la clave privada para diagnosticar una transacción. Leer el estado, verificar los nonces y consultar los recibos son operaciones públicas. Solo la sustitución o cancelación requiere firmar una nueva transacción, y eso debe hacerse desde la billetera que tiene la clave.

Si ejecutas tu propia infraestructura, un nodo dedicado te da una visión estable del mempool y del estado que no depende de un endpoint público compartido. Para la mayoría de los lectores, un endpoint alojado confiable es suficiente para el diagnóstico.

El ciclo de vida de la transacción etapa por etapa

La primera etapa es la construcción. MetaMask ensambla los campos de la transacción: from, to, value, data, límite de gas, tarifa máxima, tarifa de prioridad y nonce. El nonce es el contador de transacciones de la cuenta y es el campo más útil para diagnosticar problemas de orden. Cada transacción de una cuenta debe incluirse en orden de nonce, por lo que un hueco en el nonce N bloquea todas las transacciones posteriores de esa cuenta en esa red.

La segunda etapa es la firma. La billetera firma el payload localmente con tu clave. Si rechazas la solicitud de confirmación, no se difunde nada y no se consume ningún nonce. Una solicitud de firma que apruebas pero que nunca aparece en Actividad generalmente indica un problema de interfaz o de sesión, no un problema de red.

La tercera etapa es la difusión. El payload firmado va a un endpoint RPC, que puede aceptarlo en su mempool, rechazarlo por fondos insuficientes o conflicto de nonce, o aceptarlo pero no propagarlo. Un hash de transacción puede existir localmente en MetaMask incluso cuando ningún nodo ha aceptado el payload.

La cuarta etapa es la inclusión. Un productor de bloques selecciona la transacción, la ejecuta y la incluye en un bloque. La ejecución puede tener éxito o revertirse; una reversión igual consume gas y cuenta como incluida. La quinta etapa es la confirmación, donde bloques adicionales entierran la transacción y reducen el riesgo de reorganización. Las etiquetas de estado de MetaMask se corresponden vagamente con estas etapas, por lo que el explorador es la fuente autoritativa.

Leer el nonce y el gas como evidencia de diagnóstico

Dos números explican la mayoría de las transacciones atascadas. El primero es el nonce pendiente frente al nonce más reciente. El nonce más reciente cuenta las transacciones ya incluidas en un bloque; el nonce pendiente cuenta las transacciones que el nodo cree que están en cola o incluidas. Si tu transacción atascada tiene nonce N y el nonce más reciente es menor que N, la transacción no se ha incluido. Si el nonce más reciente es mayor que N, se incluyó y estás viendo una vista desactualizada de la billetera.

El segundo número es el precio efectivo del gas en relación con la tarifa base actual de la red. En redes EIP-1559, una transacción solo es elegible para inclusión cuando su tarifa máxima cubre la tarifa base más su tarifa de prioridad. Si la tarifa base subió después de que firmaste, una transacción que era razonable en el momento de la firma puede volverse inelegible y permanecer en el mempool hasta que la tarifa base baje o la sustituyas.

Una regla útil: antes de sustituir cualquier cosa, confirma que la transacción realmente no está incluida. Consulta el recibo por hash. Un recibo nulo con un nonce pendiente igual o superior al nonce de tu transacción significa que aún está en vuelo; un recibo no nulo significa que está hecha, independientemente de lo que muestre la billetera.

Procedimiento de diagnóstico con curl

Los siguientes comandos consultan directamente un endpoint RPC. Reemplaza RPC_URL con tu endpoint y TX_HASH y ADDRESS con tus valores. Estos son métodos JSON-RPC estándar compatibles con nodos EVM; el comportamiento exacto de las consultas pendientes depende de la visibilidad del mempool del nodo.

Primero, verifica si la transacción ha sido minada solicitando su recibo. Un resultado null significa que aún no existe ningún recibo. Segundo, compara el nonce más reciente y el pendiente del remitente. Tercero, lee la tarifa base actual del último bloque para juzgar si tu tarifa sigue siendo competitiva.

curl -s RPC_URL -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["TX_HASH"]}'

curl -s RPC_URL -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":2,"method":"eth_getTransactionCount","params":["ADDRESS","latest"]}'

curl -s RPC_URL -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":3,"method":"eth_getTransactionCount","params":["ADDRESS","pending"]}'

curl -s RPC_URL -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":4,"method":"eth_getBlockByNumber","params":["latest",false]}'

Interpretar la tabla de resultados

Registra cada resultado de consulta en una pequeña tabla antes de sacar conclusiones. La siguiente tabla es una plantilla; complétala con tus propios valores observados en lugar de asumir números típicos. No consideres ninguna fila como concluyente por sí sola.

Si el recibo es null y el nonce pendiente es igual o superior al nonce de tu transacción, la transacción está en vuelo. Si el recibo es null y el nonce pendiente es inferior al nonce de tu transacción, hay un hueco de nonce y las transacciones posteriores no pueden proceder. Si el recibo existe con estado 0x0, la transacción se incluyó pero se revirtió, lo cual es un problema de ejecución, no de red.

Comprobación ejecutable con JavaScript

Para un diagnóstico repetido, un script corto es más confiable que las consultas manuales. El siguiente ejemplo usa una llamada fetch JSON-RPC e imprime el estado del recibo, ambos nonces y la tarifa base actual. Utiliza marcadores de posición para el endpoint y los valores, y no requiere una clave privada.

Ejecútalo contra dos endpoints diferentes si sospechas que un proveedor está retrasado. Las respuestas divergentes entre proveedores suelen indicar una diferencia de sincronización o de visibilidad del mempool, no un problema a nivel de cadena.

const RPC_URL = 'RPC_URL';
const TX_HASH = 'TX_HASH';
const ADDRESS = 'ADDRESS';

async function rpc(method, params) {
  const res = await fetch(RPC_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
  });
  const json = await res.json();
  if (json.error) throw new Error(json.error.message);
  return json.result;
}

(async () => {
  const receipt = await rpc('eth_getTransactionReceipt', [TX_HASH]);
  const latest = await rpc('eth_getTransactionCount', [ADDRESS, 'latest']);
  const pending = await rpc('eth_getTransactionCount', [ADDRESS, 'pending']);
  const block = await rpc('eth_getBlockByNumber', ['latest', false]);
  console.log({ receipt: receipt ? receipt.status : null, latest, pending, baseFee: block.baseFeePerGas });
})();

Solución de problemas por síntoma

Pendiente durante mucho tiempo con un recibo nulo y un nonce pendiente igual al nonce de tu transacción: la transacción está en un mempool pero no se está seleccionando. Verifica si tu tarifa máxima cubre la tarifa base actual más la tarifa de prioridad. Si no es así, la solución es una transacción de sustitución con el mismo nonce y una tarifa más alta, firmada desde la misma billetera.

Pendiente con un hueco de nonce: una transacción anterior de la cuenta se descartó o nunca se difundió. Las transacciones posteriores no pueden incluirse hasta que se llene el hueco. Envía una transacción en el nonce faltante, o sustituye la transacción faltante, antes de esperar que las posteriores se confirmen.

Fallida con estado 0x0: la transacción se incluyó y se revirtió. Lee el motivo de la reversión desde el explorador o reproduciendo la llamada contra el bloque anterior a la inclusión. Las causas comunes son deslizamiento en intercambios, aprobación de tokens insuficiente o un require a nivel de contrato que falló. Aumentar el gas no soluciona una reversión.

Fondos insuficientes o botón de confirmar deshabilitado: la cuenta no puede cubrir el valor más el gas con la tarifa seleccionada. Esto es un problema de saldo, no de red. Reduce el monto o la tarifa, o agrega fondos a la cuenta.

Transacción visible en MetaMask pero ausente en el explorador: puede que el payload nunca haya llegado a un nodo. Vuelve a difundir la transacción firmada en bruto a un endpoint saludable, o restablece la vista de actividad de la billetera y confirma con el explorador.

Sustitución, cancelación y sus compensaciones

La sustitución funciona enviando una nueva transacción con el mismo nonce y una tarifa más alta. La mayoría de las redes requieren un incremento mínimo, a menudo alrededor del diez por ciento por encima de la tarifa original, aunque la regla exacta es específica de cada red. Una cancelación es una sustitución que envía valor cero a tu propia dirección, consumiendo el nonce para que la original nunca pueda incluirse.

La compensación es que la sustitución es una carrera. Si la original se incluye antes de que se propague la sustitución, la sustitución se rechaza como conflicto de nonce y la original prevalece. Confirma siempre que el recibo original es nulo inmediatamente antes de difundir una sustitución, y conserva ambos hashes para poder identificar cuál gana.

La sustitución también cuesta gas. Una cancelación que tiene éxito igual paga la tarifa por la transacción de valor cero. Si la original iba a confirmarse de todos modos, has pagado dos veces. Para transacciones de alto valor o sensibles al tiempo, este costo suele ser aceptable; para transacciones de bajo valor, esperar a que baje la tarifa base suele ser más económico.

Limitaciones del diagnóstico del lado de la billetera

La pestaña Actividad de MetaMask es un registro local, no un índice de cadena. Puede mostrar una transacción como pendiente después de que se haya confirmado, u omitir una transacción que se difundió fuera de la billetera. Trata el explorador y las consultas RPC directas como autoritativos y la billetera como una capa de conveniencia.

El nonce pendiente y la visibilidad del mempool también varían según el endpoint. Un nodo con un mempool pequeño o poda agresiva puede informar un nonce pendiente que difiere de lo que ven los productores de bloques. Cuando un diagnóstico es ambiguo, consulta un segundo endpoint independiente antes de actuar.

Finalmente, este procedimiento cubre la mecánica de transacciones EVM. Las redes con diferentes mercados de tarifas, modelos de cuenta o reglas de confirmación necesitan sus propios pasos de diagnóstico. El principio general sigue siendo válido: separa el estado de la billetera, el estado de difusión y el estado de inclusión, y verifica cada uno con una fuente independiente.

Próximos pasos para operaciones de transacciones confiables

Una vez que puedas leer directamente el nonce, la tarifa y el estado del recibo, la siguiente mejora es la confiabilidad de la infraestructura. Un endpoint estable reduce la probabilidad de que una difusión se descarte silenciosamente y te da una visibilidad consistente del nonce pendiente. Revisa las guías de red para el comportamiento específico de cada cadena y compara las opciones de endpoint antes de comprometerte con un proveedor.

Para equipos que ejecutan transacciones frecuentes o automatizadas, un nodo dedicado elimina la variabilidad de los endpoints compartidos y te da control sobre la política del mempool. Para usuarios individuales, un endpoint alojado de reputación confiable más el procedimiento de diagnóstico anterior suele ser suficiente.

Mantén el hábito de verificar cada transacción importante en el explorador por hash, no por la etiqueta de la billetera. Esa única práctica resuelve la mayor parte de la confusión en torno a las transacciones pendientes, fallidas y atascadas de MetaMask.

• Revisa el comportamiento específico de cada cadena en las guías de red.
• Compara las opciones de endpoint para tu red antes de escalar el volumen de transacciones.
• Considera un nodo dedicado si necesitas visibilidad consistente del mempool y del nonce.