---
title: "Confirmações de bloco"
description: "Guia orientado por verificação sobre profundidade de confirmação PoW, estados safe e finalized de PoS, substituição no mempool, reorganizações e política de crédito de depósitos em plataformas."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Confirmações de bloco
> Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.
## Resposta direta
Uma confirmação de bloco é uma afirmação específica do observador e do protocolo: uma transação está incluída em um bloco da cadeia canônica vista por esse observador. A convenção inclusiva comum do Bitcoin Core conta o bloco que contém a transação como confirmação um. Para altura de inclusão `h` e altura da melhor cadeia `H`, a profundidade é `H - h + 1`. Alguns serviços exibem apenas os descendentes como `H - h`; portanto, a convenção deve ser declarada.
Em Proof of Work, a profundidade reduz o risco de reorganização sob premissas explícitas, mas não cria um ponto mágico de finalidade absoluta. Sistemas Proof of Stake podem expor estados nativos do protocolo. A Ethereum distingue `latest`, `safe` e `finalized`; uma quantidade fixa de blocos, slots ou minutos não substitui esses rótulos. Os estados detectado, creditado, negociável e sacável de uma plataforma são políticas internas distintas mesmo após o limiar da cadeia ser atingido.
## Como funciona
1. Fixe cadeia e rede, ativo, identificador da transação, nó ou API, instante do observador, modelo de consenso e convenção de contagem. Verifique destinatário, valor e eventual memo ou tag antes de considerar que um hash correspondente é o pagamento pretendido.
2. Separe assinada, transmitida, aceita pelo mempool local de um nó e propagada. Mempools são visões de política, não uma fila global de consenso. Verifique taxas, ancestrais não confirmados, Replace-by-Fee ou substituição pelo mesmo nonce e gastos conflitantes.
3. Verifique inclusão pelo hash do bloco, altura, índice da transação e ancestralidade canônica, não só pela altura ou selo do explorador. Em cadeias de contas, inspecione também status do recibo, logs e mudança de estado efetiva; uma execução incluída ainda pode reverter.
4. Aplique o modelo de consenso. Em PoW, declare a convenção, calcule a profundidade e compare visões independentes de melhor cadeia e trabalho acumulado. Em PoS, consulte estados nativos head, safe, justified ou finalized; não os deduza de distância fixa em blocos ou slots.
5. Registre o ciclo de vida como estados explícitos: criada, transmitida, aceita no mempool local, incluída, profundidade canônica ou estado safe/finalized, reorganizada, reincluída, substituída ou conflitante. Uma reorganização não garante que a transação original retorne a todos os mempools.
6. Mantenha separado o livro da plataforma: observada, limiar de rede atingido, creditada, negociável e sacável. Aplique a política vigente da plataforma por ativo, rede, valor e incidente; manutenção, conformidade e revisão manual podem acrescentar atrasos independentes.
7. Cruze nós ou provedores independentes e continue monitorando até o estado exigido. Registre hashes, alturas, horários, rótulos RPC e versão da política, e ensaie substituição, reorganização, atraso de finalidade, nó desatualizado, relay da ponte e indisponibilidade da plataforma.
## Exemplos resolvidos
- **Convenção de contagem.** Uma transação Bitcoin está no bloco canônico `h = 900,000` e a ponta da melhor cadeia é `H = 900,005`. A profundidade inclusiva é `900,005 - 900,000 + 1 = 6 confirmations`; uma interface que conta só descendentes informa `900,005 - 900,000 = 5`. A diferença é terminológica se ambas se referem ao mesmo hash e ancestralidade.
- **Reorganização e reinclusão.** A transação primeiro tem `1 confirmation` no bloco `900,000`; depois o bloco sai da melhor cadeia e ela volta a `0` se continuar válida e sem conflito. Se for reincluída em `900,003` e a ponta alcançar `900,006`, a profundidade inclusiva será `900,006 - 900,003 + 1 = 4 confirmations`. Se um conflito confirmado a substituir, o Bitcoin Core pode informar confirmações negativas.
- **Rótulos PoS não são contagens de blocos.** Suponha que uma transação Ethereum esteja no bloco de execução `20,000,000`, enquanto um nó informa `latest = 20,000,020`, `safe = 20,000,012` e `finalized = 19,999,980`, todos na mesma ancestralidade. A profundidade latest numérica é `20,000,020 - 20,000,000 + 1 = 21`; a transação é safe, mas não finalized. São necessários ancestralidade dos hashes e rótulos de consenso; alturas não bastam.
- **Limiar da cadeia versus crédito da plataforma.** A política exige `6 confirmations`. Um depósito no bloco `900,000` está em `5/6` quando a ponta é `900,004` e chega a `6/6` em `900,005`. Se a plataforma aplicar depois uma `15-minute compliance hold`, elegibilidade on-chain e horários de crédito, negociação ou saque continuam sendo estados distintos; a retenção não é uma sétima confirmação.
## Riscos
- Consultar cadeia, rede ou ativo incorretos.
- Usar hash, destinatário, memo ou tag errados.
- Tratar uma transação assinada mas não transmitida como pendente.
- Tratar o mempool de um nó como estado global da rede.
- Não detectar rejeição por política, expulsão ou falta de propagação.
- Ignorar substituição RBF, por mesmo nonce ou gasto conflitante.
- Interpretar mal ancestrais, descendentes ou taxas de pacote não confirmados.
- Misturar contagens inclusivas e somente de descendentes.
- Confiar em nó desatualizado, sincronizando ou isolado.
- Comparar alturas sem verificar hashes e ancestralidade.
- Perder confirmações em reorganização PoW curta.
- Tratar profundidade fixa como segurança absoluta para todo valor e adversário.
- Confundir tempo decorrido, slots, epochs e blocos produzidos.
- Tratar o head PoS como safe.
- Tratar bloco safe como finalized.
- Não detectar atraso de finalidade enquanto blocos continuam sendo produzidos.
- Tratar execução incluída mas revertida como sucesso da aplicação.
- Confundir logs de tokens ou interface do explorador com o estado resultante.
- Equiparar detecção, crédito, negociação e permissão de saque da plataforma.
- Tratar confirmação na origem como conclusão do fluxo de ponte, emissor ou destino.
## Erros comuns
- Um hash pesquisável ou entrada no mempool local já estão confirmados.
- Uma convenção e o limiar de seis confirmações valem para toda cadeia, valor e serviço.
- Uma taxa maior faz blocos posteriores ou finalidade PoS chegarem mais rápido.
- Uma contagem fixa de blocos ou slots Ethereum equivale a `safe` ou `finalized`.
- Inclusão ou finalidade garante execução correta, destinatário certo, crédito da plataforma ou conclusão da ponte.
## Tópicos relacionados
- [Mempool](/pt-br/crypto/mempool/)
- [Bitcoin](/pt-br/crypto/bitcoin/)
- [Finalidade](/pt-br/crypto/finality/)
## Fontes
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (acessado em: 2026-08-13)
- [Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html) - Bitcoin Developer Documentation (acessado em: 2026-08-13)
- [gettransaction](https://developer.bitcoin.org/reference/rpc/gettransaction.html) - Bitcoin Developer Documentation (acessado em: 2026-08-13)
- [BIP 125: Opt-in Full Replace-by-Fee Signaling](https://bips.dev/125/) - Bitcoin Improvement Proposals (acessado em: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (acessado em: 2026-08-13)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (acessado em: 2026-08-13)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (acessado em: 2026-08-13)
- [Cryptocurrency deposit processing times](https://support.kraken.com/articles/203325283-cryptocurrency-deposit-processing-times) - Kraken Support (acessado em: 2026-08-13)
Source: https://wiki.fcontext.com/pt-br/crypto/block-confirmation/index.mdx