Vai al contenuto
Financial Context Wiki

Come correggere «replacement transaction underpriced»

Questo errore RPC indica che una transazione dello stesso mittente e nonce non soddisfa la politica di aumento delle commissioni del nodo. Ecco come verificarla, accelerarla o annullarla.

Aggiornato

Solo a scopo educativo; non è consulenza finanziaria o di sicurezza. Una sostituzione o cancellazione può eseguire una transazione indesiderata e le commissioni di rete sono irreversibili.

Risposta diretta

replacement transaction underpriced è un rifiuto dell’RPC o del pool, non un revert di un contratto EVM. Di solito il nodo conosce già una transazione dello stesso mittente con lo stesso nonce, ma quella nuova non aumenta abbastanza i campi delle commissioni per rispettare la sua politica di sostituzione.

Verifica prima chain, mittente, nonce e stato di ogni hash noto. Se l’originale è ancora pending e vuoi sostituirla, usa esattamente lo stesso nonce e aumenta le commissioni secondo la politica del wallet o del nodo. Aumentare solo gasLimit, cambiare slippage o ritrasmettere la stessa transazione firmata non soddisfa la regola.

Come funziona

  1. Il nonce identifica la posizione. Le transazioni di un account esterno usano nonce sequenziali. Un nodo che possiede già una transazione di quel mittente e nonce tratta un’altra nella stessa posizione come candidata sostitutiva. Un nonce successivo può restare in coda finché i precedenti non sono risolti.
  2. La sostituzione è una politica locale. Il consenso Ethereum non impone una percentuale universale. Client, provider RPC e relay privati possono applicare regole diverse o conoscere pending diverse. Il legacy pool di Geth usa attualmente 10% come valore predefinito, ma è configurabile e non vincola altri client.
  3. EIP-1559 ha due limiti di esecuzione. maxPriorityFeePerGas limita la mancia e maxFeePerGas il totale per gas, base fee inclusa. Nel legacy pool di Geth, nuovi fee cap e tip cap devono superare i vecchi valori e la soglia configurata. Il wallet deve calcolarli entrambi.
  4. Accettazione non significa conferma. Un nodo può accettare la sostituta mentre altri conservano l’originale. Solo una transazione di quel mittente e nonce entra nella sequenza canonica. La prima candidata valida inclusa rende le altre inutilizzabili su quella chain, anche se l’interfaccia tarda.
  5. Limite e importo pagato sono diversi. Il prezzo EIP-1559 effettivo è limitato dal fee cap e il gas inutilizzato non viene addebitato. Alzare maxFeePerGas aumenta l’esposizione massima, non necessariamente il prezzo finale, ma il limite alto può essere pagato se base fee e mancia lo richiedono.

Procedura ed esempio

Supponi nonce 42, maxFeePerGas = 30 gwei e maxPriorityFeePerGas = 2 gwei. Un nodo che richiede 10% può rifiutare 31 gwei e 2.1 gwei; 35 gwei e 2.5 gwei superano queste soglie illustrative. Può comunque attendere se la base fee lascia una mancia effettiva troppo bassa sotto il fee cap di 35 gwei. La percentuale non è una garanzia di rete.

Procedi così:

  1. Verifica rete e mittente. Interroga hash originale e sostituti con il wallet e un RPC o explorer indipendente.
  2. Confronta il conteggio confermato con la vista pending. Se il nonce 42 è confermato, non creare un’altra transazione credendolo ancora aperto.
  3. Decodifica to, value e data. Per accelerare conserva operazione e nonce. Per annullare, i wallet spesso inviano 0 ETH al mittente con lo stesso nonce: è una sostituta concorrente, non un richiamo del protocollo.
  4. Usa se possibile la funzione del wallet. Altrimenti ottieni politica e stima correnti, alza entrambi i limiti EIP-1559 con margine di arrotondamento e verifica la copertura di value + gasLimit x maxFeePerGas.
  5. Ricontrolla tutto prima di firmare. Trasmetti una volta, conserva ogni hash e monitora le ricevute. Un hash pending non ha ricevuta; quella legata alla chain e al blocco corretti prova l’esecuzione.

Rischi

  • L’annullamento non è garantito. L’originale può essere inclusa prima, e una transazione privata o poco propagata può essere invisibile al tuo RPC.
  • Un nonce errato può creare un nuovo pagamento o una nuova chiamata. Rifirmare calldata obsoleti può eseguire un’operazione con prezzo, allowance, scadenza o stato cambiati.
  • Un endpoint può accettare la sostituta e un altro rifiutarla. Cambiare spesso RPC può lasciare candidate in pool diversi e confondere il wallet.
  • Aumentare gasLimit non migliora la priorità. Alzare alla cieca i limiti aumenta il costo massimo; modificare slippage o calldata cambia l’esecuzione senza correggere la regola.
  • Transazioni blob, user operation di account abstraction, L2 e relay privati possono usare pool e regole diversi. La normale politica EVM di Geth non vale automaticamente.

Fermati se mittente o nonce sono ignoti, i calldata non sono decodificabili, la transazione potrebbe essere confermata, il wallet propone destinatario o valore diversi, oppure un RPC chiede seed phrase o chiave privata. La risoluzione legittima non richiede mai segreti di recupero.

Errori comuni

  • «L’account non ha fondi.» È un altro errore. Questo messaggio riguarda la candidata concorrente e il prezzo di sostituzione.
  • «Aumentare del 10% funziona sempre.» È un default comune di Geth, non consenso. Configurazione, client, tipo e arrotondamento possono richiedere di più.
  • «La transazione più costosa ha sostituito l’originale ovunque.» I pool sono locali. L’accettazione di un RPC non cancella l’originale ovunque né garantisce l’ordine.
  • «Annullare inverte una transazione confermata.» No. Compete solo finché il nonce è irrisolto; uno stato confermato richiede un rimedio applicativo, se esiste.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...