Confirmações e finalidade Ethereum: confira o bloco, não só Success

Uma transação incluída no Ethereum pode mostrar Success antes de o bloco que a contém ser finalizado. Success descreve a execução; as confirmações descrevem blocos adicionados após a inclusão segundo a convenção de contagem da ferramenta. A finalidade é um estado de consenso separado. Confira o bloco da transação e a cadeia finalizada da rede em vez de tratar essas indicações como equivalentes.

Este guia trata do Ethereum Mainnet após a transição para prova de participação. Rollups, pontes, outras cadeias e serviços de custódia têm regras adicionais. É uma verificação somente de leitura de uma transação que você já tem, não uma recomendação para enviar, cancelar ou repetir um pagamento.

Separe inclusão, execução e finalidade

A referência de recibos JSON-RPC retorna o número e o hash do bloco que contém a transação, junto com o status da execução. Uma transação pendente ainda não tem recibo de inclusão. O status 1, mostrado como 0x1 no JSON-RPC bruto, indica sucesso da execução; 0 ou 0x0 indica falha.

Nenhum desses valores é um indicador de finalidade. Uma transação cuja execução foi revertida ainda pode pertencer a um bloco finalizado. Por outro lado, uma execução bem-sucedida pode estar em um bloco recente que ainda não foi finalizado. Esperar pela finalidade não transformará uma ação revertida em uma ação bem-sucedida.

Observação	O que informa	O que não resolve
Recibo com um bloco	O provedor informa a inclusão ali	Se esse bloco está finalizado
Status do recibo Success	A execução de nível superior teve sucesso	O recebimento dos tokens pretendidos ou a finalidade
Contagem de confirmações	A ferramenta informa a profundidade desde a inclusão	Uma regra universal de finalidade ou crédito
A cadeia finalizada inclui o bloco	A finalidade do consenso abrange esse bloco	A segurança do contrato ou o crédito em uma corretora

Se a transação ainda estiver pendente, consulte o guia de transações pendentes antes de considerar outra ação. Se teve sucesso, mas os tokens pretendidos não apareceram, o guia de evidências de transferência aborda essa questão separada.

O que Ethereum entende por finalizado

A explicação da prova de participação do Ethereum descreve validadores votando em pontos de controle. A finalidade oferece uma garantia mais forte que a simples proximidade da ponta atual da cadeia: reverter um bloco finalizado exigiria uma grande falha de consenso com graves consequências econômicas. Não promete que toda aplicação ou ativo no bloco seja seguro.

A explicação da camada de aplicação da Ethereum Foundation distingue safe head de blocos finalizados. Safe é um estado intermediário de confiança, não um sinônimo de finalized. A API de execução expõe as tags de bloco latest, safe e finalized para consultar o topo relevante.

Use essas indicações no contexto do Ethereum. Um rollup pode expor palavras semelhantes para etapas envolvendo um sequenciador e uma cadeia principal. Não aplique o procedimento do Mainnet sem alterações a uma transferência por ponte nem suponha que uma transação finalizada na cadeia de origem conclui a ação no destino.

Não se promete aqui um tempo fixo de espera. Um atraso, um provedor desatualizado ou um problema de rede pode fazer de um cronômetro um substituto ruim para a verificação do estado real. Se um serviço exigir uma contagem específica de confirmações ou outra condição, consulte seus requisitos oficiais atuais em uma verificação separada.

Compare a transação com a cadeia finalizada

Comece por um explorador Ethereum conhecido ou um leitor público de blocos acessado por um caminho confiável. Alguns exploradores exibem a finalidade diretamente; outros mostram apenas detalhes do bloco. Os nomes dos métodos abaixo identificam leituras públicas, não instruções para executar uma transação ou conectar uma carteira. Este procedimento foi conferido com a documentação em 27 de outubro de 2026; não foi testado em uma carteira real para este artigo.

1. Fixe a identidade da transação. Registre Ethereum Mainnet e o hash completo da transação. Leia seu recibo, anotando o número e o hash do bloco que a contém e o status da execução. Um recibo indisponível continua sem resolução; confira a rede e o provedor antes de classificar a transação como falha.
2. Leia o estado de finalidade informado. Use a indicação de bloco documentada do explorador. Em um leitor JSON-RPC, eth_getBlockByNumber com finalized solicita o topo finalizado atual. Guarde o número de bloco retornado e o horário da observação. Leituras não suportadas ou com falha continuam sem verificação.
3. Compare a identidade do bloco e a altura. Se o topo finalizado estiver abaixo do bloco da transação, essa observação ainda não abrange a transação. Se atingiu ou passou dessa altura, releia o bloco canônico na altura de inclusão e compare seu hash com o hash do bloco no recibo. Use um provedor consistente e atualizado e confira novamente o recibo se os hashes divergirem.
4. Mantenha claro o alcance do resultado. Um bloco contêiner correspondente, na altura do topo finalizado ou anterior a ele, sustenta a finalidade nessa cadeia informada. Um provedor desatualizado ou inconsistente ainda pode fornecer dados enganosos. Preserve as divergências e consulte o status oficial ou o suporte do provedor em vez de forçar uma resposta com retratos de momentos diferentes.
5. Confira a exigência da aplicação separadamente. Estabeleça o que a transação realmente fez e se o serviço destinatário a creditou segundo suas próprias regras. Não envie um segundo pagamento só porque uma galeria ou página de depósito ainda não foi atualizada.

A documentação de consulta de blocos fornece o número e o hash do bloco. A altura sozinha não basta quando os registros divergem: dois blocos diferentes podem ocupar a mesma altura em uma reorganização da cadeia. Guarde o hash junto com o número para que sua comparação identifique o bloco que continha a transação.

Leia com cuidado uma contagem de confirmações variável

Suponha que um recibo hipotético coloque uma transação no bloco 100, enquanto um leitor informe um topo finalizado em 98. A transação já pode mostrar Success, mas essa observação do topo finalizado não abrange o bloco 100. Se uma leitura posterior consistente informar o topo finalizado 102, confira se o bloco canônico em 100 ainda tem o hash do recibo antes de registrar o bloco da transação como abrangido.

Esses números de bloco propositalmente pequenos são uma ilustração inventada, não uma observação atual do Mainnet. Não preveem quanto a finalidade demora nem especificam um limite de depósito. A contagem de confirmações exibida pode usar uma convenção que inclui o bloco contêiner; leia a definição da ferramenta antes de comparar contagens de duas interfaces.

Uma reorganização pode mover a transação para outro bloco ou deixá-la sem seu registro de inclusão anterior. Guarde o hash original, atualize seu recibo e compare os registros atuais. Uma mudança na contagem, sozinha, não é evidência de que você deve reenviar. Tampouco uma notificação antiga da carteira prevalece sobre um registro de bloco mais recente.

Termine com um registro de bloco datado

Guarde juntos a rede, o hash da transação, o número e o hash do bloco contêiner, o status da execução, o topo finalizado observado e o horário da verificação. Marque se os registros eram consistentes e se a finalidade foi indicada diretamente pelo explorador ou inferida da comparação de blocos acima.

A finalidade não prova que o token correto chegou ao destinatário correto, que um contrato é confiável ou que um serviço de custódia concluiu sua própria contabilização. Uma divergência no saldo da carteira também pode ser um problema de exibição, cobertura ou preço após a finalização da transação.

Não é necessária assinatura, aprovação ou frase de recuperação para esses registros públicos. Se um site pedir isso apenas para mostrar confirmações ou finalidade, interrompa esse fluxo. Seu resultado deve ser um estado observado específico com seus limites, não uma promessa universal de que um selo verde significa que todas as partes do pagamento estão concluídas.