A carteira diz confirmada. A página do explorador mostra um sinal verde. E os tokens não estão na conta. Nada travou e nada precisa ser reenviado: o campo de status respondeu a uma pergunta mais estreita do que a que você está fazendo. Aqui está o que esse campo atesta, o que ele deixa de fora e onde fica registrada a resposta que você realmente procura.
O que um status de sucesso realmente atesta
A EIP-658 colocou um código de status no recibo da transação e definiu seus dois valores em uma linha: 0 indica falha, causada por qualquer operação capaz de reverter a transação ou a chamada de nível superior, e 1 indica sucesso. Um explorador de blocos transforma esse 1 em um sinal.
O que importa é o alcance dessa definição. O código descreve a chamada de nível superior. Ele relata que a parte mais externa da execução terminou sem reverter, e não relata nada além disso: nem que o saldo de um token específico mudou, nem que o valor que você tinha em mente se moveu, nem que o contrato chamado fez aquilo que você pediu. Um recibo com status 0 é o que um explorador rotula como reverted. Um recibo com status 1 descarta esse caso e para por aí.
Cada caso abaixo mora nessa fresta. A cadeia registrou por inteiro o que aconteceu. O resumo de uma palavra no topo da página respondia a outra pergunta.
| A pergunta que você está fazendo | Onde a resposta fica registrada |
|---|---|
| Chegou a um bloco | O número do bloco no recibo |
| A chamada mais externa evitou reverter | O código de status do recibo |
| O saldo deste token mudou | Os eventos de transferência nos registros |
| Minha operação de usuário fez o trabalho dela | A marca de sucesso no evento dela |
Por que uma transferência de tokens pode falhar sem reverter
O padrão do token ERC-20 declara transfer como uma função que devolve um booleano, e é enfático quanto à consequência: quem chama deve tratar o false vindo de returns bool success, e quem chama não deve supor que false nunca é devolvido. À falha é permitido chegar como valor de retorno em vez de como reversão.
Quando um token relata a falha desse jeito, o desfecho depende do contrato que o chamou. Quem chama e inspeciona o booleano pode reverter no false, e o recibo volta com status 0. Quem chama e descarta o booleano segue em frente, a chamada mais externa se completa, o recibo diz sucesso, e o saldo nunca se moveu.
Os valores de retorno diferem de um segundo jeito. A biblioteca SafeERC20 da OpenZeppelin se descreve como invólucros em torno de operações ERC-20 que lançam exceção na falha quando o contrato do token devolve false, e acrescenta que tokens que não devolvem valor algum também são suportados, com as chamadas sem reversão presumidas bem-sucedidas. Uma biblioteca escrita para uniformizar esses valores de retorno é evidência direta de que eles não são uniformes.
Falhas que um contrato engole de propósito
Um contrato pode chamar outro contrato e decidir de antemão não cair junto com ele. A construção try e catch do Solidity, e a chamada de baixo nível que devolve uma marca de sucesso em vez de propagar a reversão, existem justamente para que a execução siga adiante depois de uma falha interna. Roteadores, agrupadores e retransmissores usam isso de propósito: uma perna de um lote falha, as demais pernas se liquidam, e a transação como um todo é um sucesso.
Vista do recibo, essa situação é indistinguível do caso anterior. Uma chamada interna falhou, a chamada externa absorveu a falha, e o campo de status registra o resultado externo. A falha interna continua na cadeia, mas fica no rastro de execução e naquilo que os registros não contêm, não no campo de status.
Um limite de gasto insuficiente é um dos caminhos para essa forma. Um contrato que move seus tokens com transferFrom gasta dentro do limite que você fixou com uma aprovação de tokens. Quando esse limite é menor que o valor puxado, a chamada interna falha, e se a transação inteira cai junto quem decide é quem chama, não o token.
Quando chega menos do que foi enviado
Num terceiro caso não há falha alguma, e a aritmética mesmo assim não fecha. Um contrato de token pode descontar algo dentro da própria função transfer, creditando ao destinatário menos do que o remetente entregou. Envie 5.000 unidades de um token que cobra 3% em cada transferência e chegam 4.850. O recibo diz sucesso, o evento de transferência existe, e o número dentro dele não é o número que foi digitado.
Tokens com rebase produzem um descompasso aparentado pelo lado oposto. Os saldos deles são reescritos pelo contrato em vez de movidos por uma transferência, então um saldo pode mudar sem nenhum evento de transferência por trás. Conciliar o que a carteira mostra com os valores do histórico de transações não fecha para um token assim, e nenhuma das duas leituras está errada.
O que significa uma mensagem de transação falha com paymaster
Sob a abstração de contas, o que você envia não é uma transação. O ERC-4337 define um objeto UserOperation com um mempool próprio e um bundler que empacota esses objetos em uma transação comum endereçada a um contrato EntryPoint. Um paymaster é um contrato que concorda em pagar pela transação no lugar do remetente. Uma mensagem de erro que cita o paymaster cobre duas situações que não têm nada em comum além da palavra falha.
A primeira é a rejeição durante a validação. O ERC-4337 exige que, se qualquer chamada a validateUserOp falhar, o handleOps pule a execução de pelo menos aquela operação de usuário, e exige dos bundlers que rejeitem operações inválidas do próprio mempool em vez de colocá-las na cadeia. Um paymaster que se recusa a patrocinar a chamada, cujo depósito restante é pequeno demais, ou que não passa na própria validação, joga a operação nesse ramo. Nada foi incluído, nada foi cobrado, e não há hash para consultar, porque a falha aconteceu antes de a cadeia enxergar a operação.
A segunda acontece depois da inclusão, e é ela que produz o sinal verde. Uma vez passada a validação, a especificação afirma que a execução vai acontecer e vai acontecer só uma vez, e ainda garante o pagamento da taxa. O EntryPoint então emite, para cada operação de usuário, um evento que carrega uma marca de sucesso, documentada como true se a transação do remetente teve sucesso e false se ela reverteu, ao lado do valor efetivamente pago pela conta ou pelo paymaster. A transação do lote tem sucesso, o paymaster é cobrado, e a marca da sua operação é false. As três coisas valem ao mesmo tempo.
| Onde falhou | Chegou a um bloco | Quem pagou | O que há para consultar |
|---|---|---|---|
| Validação, antes da inclusão | Não | Ninguém | Um erro do bundler ou da carteira, e nenhum registro na cadeia |
| Execução, depois da inclusão | Sim | A conta ou o paymaster | Uma transação bem-sucedida cujo evento de operação de usuário carrega uma marca de sucesso em false |
Onde olhar em vez do campo de status
Os movimentos de tokens ficam registrados como eventos nos registros. A visão de transferências de tokens de um explorador é uma representação desses eventos, então se o seu endereço não aparece em nenhum deles, aquele token não se moveu, diga o status o que disser. O que se confere são os registros; o status é o resumo.
Três perguntas dão conta do serviço. Existe sequer um evento de transferência envolvendo o seu endereço, ou essa seção da página está vazia? Se existe, o valor dele é o valor que foi enviado? E o contrato que o emite é o contrato de token que você tinha em mente, na rede que você tinha em mente?
Uma quarta possibilidade sobrevive às três conferências: a transferência aconteceu exatamente como mandado e está sendo procurada no lugar errado. Um segundo endereço derivado da mesma frase-semente, o mesmo endereço em outra rede, e um token que a carteira não exibe enquanto o contrato dele não for adicionado à mão produzem, cada um, uma tela vazia ao lado de um recibo perfeitamente bom.
Em resumo
O status de um recibo é uma afirmação sobre a chamada mais externa e sobre mais nada. Sucesso quer dizer que a transação não reverteu. Nunca quis dizer que um token se moveu, que o valor certo se moveu, ou que o contrato fez com ele o que se queria. Esses fatos moram nos registros de eventos e, sob o ERC-4337, em uma marca de sucesso mantida separada do status da transação que a carrega.
Quando uma transferência some atrás de um sinal verde, desça as camadas em ordem: um evento de transferência, depois o valor dele, depois o contrato de token e a rede. 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
- O que é um QR code de cripto?
- Liquidez global, M2 e Bitcoin: um guia de medição
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] Ethereum Improvement Proposals, EIP-20: Token Standard (a função transfer e seu valor de retorno booleano) eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-658: Embedding transaction status code in receipts (o campo de status do recibo da transação) eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-4337: Account Abstraction Using Alt Mempool (validação, bundlers e paymasters) eips.ethereum.org
[4] eth-infinitism, account-abstraction, contracts/interfaces/IEntryPoint.sol, tag v0.7.0 (a declaração de UserOperationEvent) raw.githubusercontent.com
[5] OpenZeppelin, openzeppelin-contracts, contracts/token/ERC20/utils/SafeERC20.sol, tag v5.1.0 (o comentário de documentação da biblioteca) raw.githubusercontent.com
