Saltar al contenido
Financial Context Wiki

Cómo corregir «replacement transaction underpriced»

Este error RPC indica que una transacción del mismo remitente y nonce no cumplió la política de aumento de comisiones del nodo. Aprenda a revisarla, acelerarla o cancelarla con seguridad.

Actualizado

Solo con fines educativos; no es asesoramiento financiero ni de seguridad. Un reemplazo o cancelación puede ejecutar una transacción no deseada y las comisiones de red son irreversibles.

Respuesta directa

replacement transaction underpriced es un rechazo del RPC o del pool de transacciones, no una reversión de un contrato EVM. Suele indicar que el nodo ya conoce una transacción del mismo remitente con el mismo nonce, pero la nueva no aumenta suficientemente los campos de comisión para cumplir la política de reemplazo de ese nodo.

Primero verifique la cadena, el remitente, el nonce y el estado de todos los hashes conocidos. Si la original sigue pendiente y desea reemplazarla, use exactamente el mismo nonce y eleve las comisiones conforme a la política de la cartera o del nodo. Aumentar solo gasLimit, cambiar el deslizamiento o retransmitir la misma transacción firmada no cumple una regla de aumento.

Cómo funciona

  1. El nonce identifica la posición. Las transacciones de una cuenta externa usan nonces secuenciales. Si un nodo ya tiene una transacción de ese remitente y nonce, trata otra en esa posición como candidata a reemplazo. Un nonce posterior puede quedar en cola hasta resolver los anteriores.
  2. El reemplazo es una política local del pool. El consenso de Ethereum no fija un porcentaje universal. Clientes, proveedores RPC y relés privados pueden aplicar políticas distintas o conocer diferentes transacciones pendientes. El legacy pool de Geth usa actualmente 10% por defecto, pero es configurable y otros clientes no tienen que coincidir.
  3. EIP-1559 tiene dos topes de ejecución. maxPriorityFeePerGas limita la propina y maxFeePerGas el total por gas, incluida la tarifa base. En el legacy pool de Geth, el nuevo fee cap y tip cap deben superar los anteriores y el umbral porcentual configurado. La cartera debe calcular ambos.
  4. La aceptación no es confirmación. Un nodo puede aceptar el reemplazo mientras otros retienen el original. Solo una transacción de ese remitente y nonce puede entrar en la secuencia canónica. La primera candidata válida incluida inutiliza las demás en esa cadena, aunque las interfaces tarden en actualizarse.
  5. El tope y el importe pagado difieren. El precio efectivo EIP-1559 está limitado por el fee cap y el gas no usado no se cobra. Elevar maxFeePerGas aumenta la exposición máxima, no necesariamente el precio final, aunque el límite alto puede pagarse si lo exigen la tarifa base y la propina.

Flujo de resolución y ejemplo

Suponga nonce 42, maxFeePerGas = 30 gwei y maxPriorityFeePerGas = 2 gwei. Un nodo que exige 10% puede rechazar 31 gwei y 2.1 gwei; 35 gwei y 2.5 gwei superan esos umbrales ilustrativos. Aun así puede esperar si la tarifa base deja una propina efectiva insuficiente bajo el fee cap de 35 gwei. El porcentaje es un ejemplo, no una garantía de toda la red.

Siga este orden:

  1. Confirme la red y el remitente. Consulte el hash original y todos los reemplazos en la cartera y en un RPC o explorador independiente.
  2. Compare el recuento confirmado con la vista pending. Si el nonce 42 ya se confirmó, no cree otra transacción suponiendo que sigue pendiente.
  3. Decodifique to, value y data. Para acelerar, conserve operación y nonce. Para cancelar, las carteras suelen enviar 0 ETH al propio remitente con el mismo nonce; es un reemplazo competidor, no una retirada del protocolo.
  4. Use la función de acelerar o cancelar de la cartera cuando sea posible. Si no, obtenga la política y estimación actuales, eleve ambos topes EIP-1559 con margen de redondeo y compruebe que la cuenta cubra value + gasLimit x maxFeePerGas.
  5. Revise toda la transacción antes de firmar. Difunda una vez, guarde cada hash y vigile los recibos de todas las candidatas. Un hash pendiente no tiene recibo; el recibo ligado a la cadena y bloque correctos confirma la ejecución.

Riesgos

  • La cancelación no está garantizada. La original puede incluirse antes de que la cancelación llegue al productor, y una transacción privada o mal propagada puede ser invisible para su RPC.
  • Un nonce incorrecto puede crear un pago o llamada nuevos. Volver a firmar calldata obsoletos puede ejecutar una operación cuyo precio, allowance, plazo o estado ya cambió.
  • Un endpoint puede aceptar el reemplazo y otro rechazarlo. Cambiar repetidamente de RPC puede dejar candidatas en pools distintos y confundir la cartera.
  • Elevar gasLimit no mejora la prioridad. Subir topes a ciegas aumenta el coste máximo; cambiar deslizamiento o calldata altera la ejecución y no corrige la regla del pool.
  • Transacciones blob, user operations de abstracción de cuentas, L2 y relés privados pueden usar pools y reglas diferentes. No dé por válida para ellos la política EVM ordinaria de Geth.

Deténgase si desconoce remitente o nonce, no puede decodificar los calldata, la transacción quizá ya esté confirmada, la cartera propone otro destinatario o importe, o un RPC pide la frase semilla o clave privada. La resolución legítima nunca exige secretos de recuperación.

Errores comunes

  • «La cuenta no tiene fondos.» Los fondos insuficientes son otro error. Este mensaje trata la transacción competidora y el precio de reemplazo.
  • «Aumentar 10% siempre funciona.» Es un valor predeterminado común de Geth, no consenso. Configuración, cliente, tipo y redondeo pueden exigir más.
  • «La transacción más cara reemplazó la original en todas partes.» Los pools son locales. La aceptación de un RPC no borra la original de todos ni garantiza cuál entra primero.
  • «Cancelar revierte una transacción confirmada.» No. Solo compite mientras el nonce esté sin resolver; un cambio confirmado requiere un remedio de aplicación, si existe.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...