Sua carteira mostra uma prévia do swap, informa quanto você vai receber e não relata nenhum problema. Você assina, e a transação cai na rede como uma falha que mesmo assim cobra gas. A prévia não mentiu para você. Ela respondeu a uma pergunta sobre um momento, e sua transação foi executada em outro.
O que uma simulação realmente executa
A prévia da carteira é um ensaio a seco. Um nó executa sua chamada contra uma cópia do estado da rede, relata o que aconteceria e depois descarta o resultado. A documentação para desenvolvedores da Ethereum descreve o método por trás disso como um que executa imediatamente uma nova chamada de mensagem sem criar uma transação na blockchain, e descreve o método de gas correspondente como um que devolve uma estimativa enquanto a transação não será adicionada à blockchain.
Dessa descrição decorrem duas propriedades, e ambas importam adiante. O ensaio a seco é executado contra um bloco escolhido, então sua resposta fica presa ao estado naquele bloco. E ele roda sozinho: entre a chamada e o resultado nada mais é executado.
O estado contra o qual você simulou não é o estado em que você aterrissa
Entre a prévia e a execução, sua transação precisa viajar. Ela é assinada, difundida, mantida em um mempool, selecionada por um produtor de blocos e só então executada sob as regras do bloco que a contém. Cada passo dessa viagem leva tempo, e a rede não para enquanto isso acontece.
O código do contrato lê o estado no momento da execução, nunca no momento da simulação. As reservas de um pool, a resposta de um oráculo, um limite de gasto concedido, uma entrada em lista branca, um sinalizador de pausa, um teto por endereço, um leilão já encerrado: qualquer um desses valores pode ter um valor quando a prévia roda e outro quando o bloco é construído. Um contrato que inspeciona esse valor e para quando a condição não é atendida se comporta de forma idêntica nos dois momentos. O que mudou foi a entrada.
Saída mínima e prazo: as verificações que falham de propósito
Uma chamada de swap pode carregar duas proteções dentro da própria chamada. Uma é um piso sobre o que você precisa receber, derivado da sua tolerância de slippage. A outra é um carimbo de tempo depois do qual a chamada deixa de ser válida. Ambas são argumentos que você assina, então ambas ficam congeladas nos valores que a prévia calculou.
Suponha que a prévia cote 10.000 USDC pelos tokens que você está vendendo e que sua tolerância esteja em 0,5%. A chamada passa então a carregar um piso de 9.950 USDC, e o contrato recebe a instrução de abandonar toda a interação em vez de entregar menos. Quando o preço se move além da sua tolerância enquanto a transação está a caminho, a proteção faz exatamente o que você pediu a ela. O prazo se comporta do mesmo jeito: uma chamada que fica sem confirmação além do próprio carimbo de tempo é recusada na chegada, ainda que a mesma chamada tivesse passado alguns minutos antes.
Este é o caso em que a falha é a proteção funcionando. Uma proteção que nunca dispara deixaria a interação liquidar a qualquer preço para o qual o mercado tivesse derivado até o bloco ser construído.
Ordenação: a mesma transação em outro lugar
Um bloco é uma sequência, e a ordenação de transações decide qual interação enxerga qual estado. Sua prévia colocou a chamada no início de uma fila vazia. O bloco a coloca atrás de tudo o que o produtor pôs ali, e esses vizinhos podem consumir a liquidez, o limite de gasto ou o saldo restante com os quais sua chamada contava.
Um mint com teto rígido mostra isso com clareza. Dez carteiras podem simular com sucesso, cada uma, a última unidade disponível, porque cada prévia roda contra um estado em que essa unidade ainda não foi reivindicada. Uma delas aterrissa primeiro e as outras nove encontram um contrato esgotado. Não havia nada de errado com as nove prévias. Elas responderam a uma pergunta que tinha uma resposta antes de o bloco existir e outra depois.
Gas: uma estimativa não é uma reserva
Uma estimativa de gas é produzida do mesmo jeito que a prévia, executando a chamada uma vez e medindo-a. A mesma documentação avisa que a estimativa pode ser significativamente maior do que a quantidade de gas realmente usada pela transação, e a direção contrária é a que dói: uma estimativa medida em um caminho barato pode ficar aquém do caminho que a transação acaba tomando.
É nas ramificações da execução que essa lacuna se abre. Um swap roteado por um pool na prévia pode ser roteado por dois na execução; a primeira escrita em uma posição de armazenamento custa mais do que uma escrita posterior na mesma posição; um laço que tocou três posições pode tocar nove. Se o limite que você assinou acaba no meio da execução, o trabalho é desfeito e o gas é consumido do mesmo jeito, que é a mesma aritmética aplicada a qualquer transação falha. Deixar folga acima da estimativa não eleva a taxa quando essa folga fica sem uso, porque como o gas é precificado separa a quantidade de trabalho do preço por unidade de trabalho.
Quando a simulação não estava simulando a transação que você enviou
Às vezes a prévia e a execução nem sequer são a mesma chamada. Uma simulação é feita contra um ponto de acesso em uma rede, então uma carteira apontada para outra rede ou para um nó com estado desatualizado responde sobre um mundo diferente daquele para o qual sua assinatura é difundida.
Sua própria fila de pendentes é uma segunda fonte desse descompasso. As transações de uma conta são executadas em ordem de nonce, então uma chamada pendente anterior da mesma carteira roda primeiro e pode mudar o estado do qual uma chamada posterior depende. Quando essa chamada anterior é uma aprovação ainda não confirmada, a interação enfileirada atrás dela pode ser simulada contra o limite que você espera e executada contra o limite que você de fato tem.
| O que a prévia mostrou | O que mudou até a execução | Onde olhar |
|---|---|---|
| Um valor de saída cotado | As reservas ou a resposta do oráculo se moveram | O argumento de saída mínima na chamada assinada |
| Uma chamada válida | O carimbo de tempo assinado expirou | O argumento de prazo e o tempo passado pendente |
| Saldo ou liquidez disponíveis | Outra transação do bloco pegou isso antes | A posição da sua transação dentro do bloco dela |
| Uma estimativa de gas | A execução tomou um ramo mais longo | O gas usado ante o limite de gas no recibo |
| Um ensaio a seco limpo | A carteira estava em outra rede ou outro nó | O identificador de rede e o ponto de acesso na assinatura |
Como a falha aparece depois
Uma interação que para desse jeito fica registrada. Ela ocupa uma posição em um bloco, consome gas, e seu recibo carrega um campo de status: a EIP-658 substituiu a raiz de estado intermediária do recibo por um código de status em que zero indica falha e um indica sucesso. Os exploradores transformam esse campo no rótulo revertida.
O rótulo nomeia o resultado e não a causa. Alguns contratos anexam uma cadeia de motivo ao parar, e um explorador ou um rastreamento consegue exibi-la; outros param sem anexar nada. Ler a transação falha ao lado dos argumentos que você de fato assinou é o que transforma um código de status em um diagnóstico, porque esses argumentos são a parte da história que o recibo não consegue reconstruir para você.
O que de fato reduz a taxa de falhas
Encurte a lacuna. Uma prévia tirada um instante antes de assinar descreve um estado mais próximo do que o bloco vai conter, e uma transação que confirma rápido tem menos tempo para ser ultrapassada.
Dimensione as proteções pelo ativo, e não pelo hábito. Um piso apertado o bastante para rejeitar um minuto comum de movimento em um mercado raso vai parar suas interações repetidamente, enquanto um piso frouxo o bastante para aceitar qualquer coisa abre mão da proteção pela qual você o definiu. O mesmo julgamento vale para o prazo, que precisa ser longo o bastante para sobreviver a um período de congestionamento.
Trate uma falha repetida como informação. Quando a mesma interação para várias vezes com os mesmos argumentos, o contrato está relatando uma condição que no momento não pode ser satisfeita, e reenviar a mesma chamada gasta gas para receber a mesma resposta.
Em resumo
Uma simulação responde ao que aconteceria se esta chamada rodasse agora, sozinha, contra este bloco. Uma execução na rede responde ao que aconteceu quando a chamada rodou depois, entre outras transações, contra outro bloco. Uma falha após uma prévia limpa é a distância entre essas duas perguntas, e as proteções que você assinou são o que converte essa distância em uma parada em vez de uma execução ruim. Confira os argumentos da chamada assinada, a posição da transação dentro do bloco dela e o gas usado ante o limite de gas, e o motivo estará em um dos três. Para continuar aprendendo os fundamentos, acompanhe mais conteúdos da Bitbase Academy.
Leituras relacionadas
Outros artigos da Bitbase sobre este tema:
- Como trocar de endpoint RPC com segurança
- Taxa máxima de transação excedida: o que significa esse aviso da carteira
- Limite de requisições RPC excedido e como evitá-lo
- FIFO e LIFO no custo base de cripto
- Prêmio memético: por que memes movem preços
Aviso: Este artigo é conteúdo educacional da Bitbase Academy, fornecido apenas para fins informativos. Não constitui aconselhamento de investimento, negociação, tributário ou financeiro. Criptoativos são voláteis; avalie seu próprio risco. Escrito em setembro de 2026; consulte as informações oficiais mais recentes.
Fontes
[1] Documentação para desenvolvedores da Ethereum.org, JSON-RPC API (eth_call, eth_estimateGas) ethereum.org
[2] Ethereum Improvement Proposals, EIP-658: Embedding transaction status code in receipts eips.ethereum.org
[3] Documentação para desenvolvedores da Ethereum.org, “Transações” (Transactions) ethereum.org
