Aller au contenu
Financial Context Wiki

Corriger « replacement transaction underpriced »

Cette erreur RPC signifie qu'une transaction du même expéditeur et nonce ne respecte pas la hausse de frais exigée par le nœud. Voici comment la vérifier, l'accélérer ou l'annuler.

Mis à jour

À titre éducatif uniquement ; ceci n’est pas un conseil financier ou de sécurité. Un remplacement ou une annulation peut exécuter une transaction non voulue, et les frais réseau sont irréversibles.

Réponse directe

replacement transaction underpriced est un rejet du RPC ou du pool, et non un revert de contrat EVM. Le nœud connaît généralement déjà une transaction du même expéditeur et du même nonce, mais la nouvelle n’augmente pas assez les champs de frais pour satisfaire sa politique de remplacement.

Vérifiez d’abord la chaîne, l’expéditeur, le nonce et l’état de chaque hash connu. Si l’original reste en attente et doit être remplacé, utilisez exactement le même nonce et relevez les frais selon la politique du portefeuille ou du nœud. Augmenter seulement gasLimit, modifier le slippage ou rediffuser la même transaction signée ne satisfait pas cette règle.

Fonctionnement

  1. Le nonce repère la position. Les transactions d’un compte externe ont des nonces séquentiels. Un nœud possédant déjà une transaction pour cet expéditeur et ce nonce traite une autre à la même position comme candidate au remplacement. Un nonce ultérieur peut rester en file jusqu’à résolution des précédents.
  2. Le remplacement est une politique locale. Le consensus Ethereum n’impose aucun pourcentage universel. Clients, fournisseurs RPC et relais privés peuvent avoir des règles ou des transactions en attente différentes. Le legacy pool de Geth utilise actuellement 10% par défaut, mais ce réglage est configurable et non obligatoire ailleurs.
  3. EIP-1559 comporte deux plafonds. maxPriorityFeePerGas limite le pourboire et maxFeePerGas le total par gas, base fee comprise. Dans le legacy pool de Geth, les nouveaux fee cap et tip cap doivent dépasser les anciens et le seuil configuré. Le portefeuille doit calculer les deux.
  4. Acceptation n’est pas confirmation. Un nœud peut accepter le remplacement tandis que d’autres gardent l’original. Une seule transaction de cet expéditeur et nonce peut entrer dans la séquence canonique. La première candidate valide incluse rend les autres inutilisables sur cette chaîne, même si l’interface tarde.
  5. Plafond et somme payée diffèrent. Le prix effectif EIP-1559 est limité par le fee cap et le gas inutilisé n’est pas facturé. Relever maxFeePerGas augmente l’exposition maximale, pas forcément le prix final, mais le plafond élevé peut être payé selon la base fee et le pourboire.

Procédure et exemple

Supposons nonce 42, maxFeePerGas = 30 gwei et maxPriorityFeePerGas = 2 gwei. Un nœud exigeant 10% peut rejeter 31 gwei et 2.1 gwei ; 35 gwei et 2.5 gwei dépassent ces seuils illustratifs. La transaction peut encore attendre si la base fee laisse trop peu de pourboire effectif sous le fee cap de 35 gwei. Ce taux n’est pas une garantie du réseau.

Procédez ainsi :

  1. Vérifiez réseau et expéditeur. Consultez le hash original et tous les remplacements avec le portefeuille et un RPC ou explorateur indépendant.
  2. Comparez le compteur confirmé à la vue pending. Si le nonce 42 est confirmé, ne créez pas une autre transaction en le croyant encore ouvert.
  3. Décodez to, value et data. Pour accélérer, gardez opération et nonce. Pour annuler, les portefeuilles envoient souvent 0 ETH à l’expéditeur avec le même nonce : c’est un remplacement concurrent, pas un rappel protocolaire.
  4. Utilisez si possible la fonction du portefeuille. Sinon, obtenez politique et estimation actuelles, relevez les deux plafonds EIP-1559 avec une marge d’arrondi et vérifiez que le compte couvre value + gasLimit x maxFeePerGas.
  5. Relisez tout avant de signer. Diffusez une fois, gardez tous les hash et surveillez les reçus. Un hash pending n’a pas de reçu ; le reçu lié à la bonne chaîne et au bon bloc atteste l’exécution.

Risques

  • L’annulation n’est pas garantie. L’original peut être inclus avant son arrivée, et une transaction privée ou mal propagée peut être invisible pour votre RPC.
  • Un mauvais nonce peut créer un nouveau paiement ou appel. Re-signer des calldata obsolètes peut exécuter une opération dont le prix, l’allowance, l’échéance ou l’état a changé.
  • Un endpoint peut accepter le remplacement et un autre le refuser. Changer souvent de RPC peut laisser des candidates dans plusieurs pools et brouiller l’affichage.
  • Relever gasLimit n’améliore pas la priorité. Relever aveuglément les plafonds accroît le coût maximal ; modifier slippage ou calldata change l’exécution sans corriger la règle.
  • Transactions blob, user operations d’abstraction de compte, L2 et relais privés peuvent utiliser d’autres pools et règles. La politique EVM ordinaire de Geth ne s’y applique pas automatiquement.

Arrêtez-vous si expéditeur ou nonce sont inconnus, si les calldata sont indécodables, si la transaction est peut-être confirmée, si le portefeuille propose un autre destinataire ou montant, ou si un RPC demande seed phrase ou clé privée. Un dépannage légitime ne demande jamais les secrets de récupération.

Idées reçues

  • « Le compte manque de fonds. » C’est une autre erreur. Ce message concerne la transaction concurrente et son prix de remplacement.
  • « Une hausse de 10% fonctionne toujours. » C’est un défaut courant de Geth, pas une règle de consensus. Configuration, client, type et arrondi peuvent exiger plus.
  • « La transaction plus chère a remplacé l’original partout. » Les pools sont locaux. L’acceptation par un RPC n’efface pas l’original partout et ne garantit pas l’ordre.
  • « Annuler inverse une transaction confirmée. » Non. L’annulation ne concourt que tant que le nonce reste ouvert ; un état confirmé exige un recours applicatif, s’il existe.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...