Ir para o conteúdo
Financial Context Wiki

Como corrigir “replacement transaction underpriced”

Este erro RPC indica que uma transação do mesmo remetente e nonce não cumpriu a política de aumento de taxas do nó. Saiba como verificar, acelerar ou cancelar com segurança.

Atualizado

Somente para fins educacionais; não é aconselhamento financeiro nem de segurança. Uma substituição ou cancelamento pode executar uma transação indesejada, e as taxas de rede são irreversíveis.

Resposta direta

replacement transaction underpriced é uma rejeição do RPC ou do pool, não um revert de contrato EVM. Em geral, o nó já conhece uma transação do mesmo remetente e nonce, mas a nova não elevou suficientemente os campos de taxa para cumprir a política de substituição daquele nó.

Primeiro confira rede, remetente, nonce e estado de todos os hashes conhecidos. Se a original ainda estiver pendente e você quiser substituí-la, use exatamente o mesmo nonce e eleve as taxas conforme a carteira ou o nó. Aumentar apenas gasLimit, mudar slippage ou retransmitir a mesma transação assinada não cumpre a regra.

Como funciona

  1. O nonce identifica a posição. Transações de uma conta externa usam nonces sequenciais. Se um nó já tem uma transação daquele remetente e nonce, trata outra na mesma posição como candidata à substituição. Um nonce posterior pode ficar na fila até os anteriores serem resolvidos.
  2. A substituição é política local do pool. O consenso Ethereum não define percentual universal. Clientes, provedores RPC e relays privados podem ter regras ou transações pendentes diferentes. O legacy pool do Geth usa hoje 10% por padrão, mas o valor é configurável e não obriga outros clientes.
  3. EIP-1559 tem dois tetos de execução. maxPriorityFeePerGas limita a gorjeta e maxFeePerGas o total por gas, incluindo a taxa base. No legacy pool do Geth, novos fee cap e tip cap devem superar os antigos e o limiar configurado. A carteira deve calcular ambos.
  4. Aceitação não é confirmação. Um nó pode aceitar a substituta enquanto outros mantêm a original. Só uma transação daquele remetente e nonce entra na sequência canônica. A primeira candidata válida incluída inutiliza as demais naquela rede, embora a interface possa demorar.
  5. Teto e valor pago diferem. O preço efetivo EIP-1559 é limitado pelo fee cap e gas não usado não é cobrado. Elevar maxFeePerGas aumenta a exposição máxima, não necessariamente o preço final, mas o teto alto pode ser pago se taxa base e gorjeta exigirem.

Procedimento e exemplo

Suponha nonce 42, maxFeePerGas = 30 gwei e maxPriorityFeePerGas = 2 gwei. Um nó que exige 10% pode rejeitar 31 gwei e 2.1 gwei; 35 gwei e 2.5 gwei superam esses limiares ilustrativos. Ainda pode haver espera se a taxa base deixar gorjeta efetiva baixa sob o fee cap de 35 gwei. O percentual é exemplo, não garantia da rede.

Siga esta ordem:

  1. Confira rede e remetente. Consulte o hash original e os substitutos na carteira e em RPC ou explorador independente.
  2. Compare a contagem confirmada com a visão pending. Se o nonce 42 já foi confirmado, não crie outra transação supondo que ainda esteja aberto.
  3. Decodifique to, value e data. Para acelerar, preserve operação e nonce. Para cancelar, carteiras costumam enviar 0 ETH ao remetente com o mesmo nonce; é substituição concorrente, não revogação do protocolo.
  4. Use a função da carteira quando possível. Caso contrário, obtenha política e estimativa atuais, eleve ambos os tetos EIP-1559 com margem de arredondamento e confirme cobertura de value + gasLimit x maxFeePerGas.
  5. Revise tudo antes de assinar. Transmita uma vez, guarde cada hash e acompanhe os recibos. Hash pending não tem recibo; o recibo ligado à rede e bloco corretos é a confirmação da execução.

Riscos

  • O cancelamento não é garantido. A original pode ser incluída antes, e uma transação privada ou mal propagada pode ser invisível ao seu RPC.
  • Nonce errado pode criar novo pagamento ou chamada. Reassinar calldata antigos pode executar operação cujo preço, allowance, prazo ou estado mudou.
  • Um endpoint pode aceitar e outro rejeitar. Trocar RPC repetidamente pode deixar candidatas em pools diferentes e confundir a carteira.
  • Elevar gasLimit não melhora a prioridade. Elevar tetos às cegas aumenta o custo máximo; mudar slippage ou calldata altera a execução sem corrigir a regra.
  • Transações blob, user operations de abstração de conta, L2 e relays privados podem usar pools e regras diferentes. A política EVM comum do Geth não se aplica automaticamente.

Pare se remetente ou nonce forem desconhecidos, calldata não puderem ser decodificados, a transação talvez já esteja confirmada, a carteira propuser destinatário ou valor diferente, ou um RPC pedir seed phrase ou chave privada. Solução legítima nunca exige segredos de recuperação.

Erros comuns

  • “A conta não tem fundos.” Esse é outro erro. Esta mensagem trata da candidata concorrente e do preço de substituição.
  • “Aumentar 10% sempre funciona.” É padrão comum do Geth, não consenso. Configuração, cliente, tipo e arredondamento podem exigir mais.
  • “A transação mais cara substituiu a original em todo lugar.” Pools são locais. A aceitação de um RPC não apaga a original de todos nem garante a ordem.
  • “Cancelar reverte uma transação confirmada.” Não. Só compete enquanto o nonce está sem solução; estado confirmado exige remédio no aplicativo, se existir.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...