﻿---
title: "Um depósito de cripto pode desaparecer após uma reorganização da cadeia?"
description: "Uma reorganização pode remover uma transação de depósito da cadeia canônica. Entenda como confirmações, finalidade e políticas de crédito limitam esse risco."
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.

# Um depósito de cripto pode desaparecer após uma reorganização da cadeia?

> Apenas para fins educacionais; não constitui aconselhamento nem recomendação de investimento. Investimentos podem resultar em perdas.

<a id="answer"></a>

## Resposta direta

Sim. Um depósito pode aparecer em um bloco e depois perder sua confirmação se uma reorganização substituir esse bloco. A transação pode então ser incluída novamente na nova cadeia canônica, voltar ao estado pendente, entrar em conflito com outra transação ou desaparecer do histórico reconhecido pelo destinatário.

O rótulo “confirmada” em uma carteira não significa que uma corretora ou custodiante liberou os fundos. As plataformas definem seus próprios limites de crédito e podem atrasar, suspender ou reverter um crédito provisório quando a rede se reorganiza ou deixa de atingir a finalidade. Consulte sempre a política atual da plataforma receptora para o ativo e a rede específicos.

<a id="mechanism"></a>

## Como funciona

Em uma cadeia de prova de trabalho como a do Bitcoin, blocos válidos concorrentes podem existir na mesma altura. Os nós seguem a cadeia válida com mais trabalho acumulado, e os blocos do ramo perdedor tornam-se obsoletos. Uma transação em um bloco obsoleto não tem confirmação na cadeia selecionada, a menos que seja incluída novamente. Blocos adicionais aumentam o trabalho necessário para substituir o histórico; assim, o risco geralmente diminui com a profundidade das confirmações, mas nunca se torna uma certeza absoluta do protocolo em uma contagem fixa.

Outras redes apresentam sinais de segurança diferentes. A prova de participação do Ethereum combina uma regra de escolha de bifurcação para a ponta da cadeia com checkpoints justified e finalized. Portanto, a plataforma deve alinhar sua política ao modelo real de consenso e finalidade da rede, sem tratar a mesma quantidade de blocos como igualmente segura em qualquer lugar.

Para cada depósito, a operadora deve acompanhar o identificador da transação, o ativo e a rede, o endereço de destino ou memo, o hash do bloco canônico, a profundidade das confirmações e qualquer estado de finalização. O crédito só deve passar de detectado para pendente e depois para disponível após cumprir a política configurada. Divergência entre nós, reorganização inesperada, finalidade atrasada ou produção anormal de blocos devem acionar revisão, limite maior ou pausa nos depósitos.

<a id="example"></a>

## Exemplo

Suponha que uma plataforma detecte um depósito de 1 BTC e exija 3 confirmações. Após 2 confirmações, uma reorganização seleciona um ramo que não contém o depósito. A contagem exibida volta a 0, e a plataforma mantém o depósito pendente em vez de creditá-lo. Se a mesma transação for incluída depois na cadeia selecionada e atingir 3 confirmações, a plataforma poderá creditá-la conforme sua política.

Os valores são ilustrativos, não uma regra universal do Bitcoin nem uma promessa de qualquer plataforma. Os requisitos podem variar conforme o ativo, a rede, o valor do depósito, os controles de custódia e as condições atuais da rede.

<a id="risks"></a>

## Riscos

Creditar cedo demais cria risco de gasto duplo e conciliação. Se os fundos provisórios puderem ser negociados ou sacados antes que o depósito subjacente supere o limite, uma reorganização poderá deixar um déficit na plataforma. Conforme seus termos, a plataforma poderá congelar a conta, reverter o crédito provisório ou pedir reembolso. O usuário não deve tratar uma captura de tela ou a primeira atualização de saldo como liquidação definitiva.

Limites fixos também envelhecem mal. As operadoras devem revisar o histórico de reorganizações, as mudanças de consenso, o desempenho da finalidade, a saúde dos nós e o valor em risco. Depósitos grandes podem justificar uma espera maior. Durante reorganizações profundas, visões conflitantes dos nós, incidentes de segurança ou finalidade paralisada, pausar depósitos e saques pode ser mais seguro do que contar blocos mecanicamente.

<a id="misconceptions"></a>

## Equívocos comuns

- Equívoco 1: Uma confirmação significa que o depósito não pode ser revertido. Ela significa apenas que a transação está atualmente incluída na cadeia selecionada.

- Equívoco 2: Mais confirmações tornam todas as redes igualmente seguras. Profundidade de bloco, tempo decorrido, trabalho ou participação acumulados e finalidade explícita têm significados diferentes entre sistemas de consenso.

- Equívoco 3: Um explorador de blocos ou saldo da carteira prova que a corretora liquidou o depósito. A plataforma receptora aplica sua própria visão dos nós, verificações do ativo e política de crédito.

<a id="related"></a>

## Tópicos relacionados

- [Reorganização da cadeia](/pt-br/crypto/chain-reorg/)
- [Confirmação de bloco](/pt-br/crypto/block-confirmation/)
- [Finalidade](/pt-br/crypto/finality/)
- [Regra de escolha de bifurcação](/pt-br/crypto/fork-choice-rule/)
- [Corretora de criptomoedas](/pt-br/crypto/exchange/)

<a id="sources"></a>

## Fontes

- [Visão geral da tecnologia blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (acessado em: 2026-08-21)
- [Guia do desenvolvedor Bitcoin: blockchain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin.org (acessado em: 2026-08-21)
- [Prova de participação (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - ethereum.org (acessado em: 2026-08-21)
- [Depósito pendente: transação não confirmada](https://help.coinbase.com/en/exchange/crypto-transfers/deposit-pending-unconfirmed-transaction) - Coinbase Help (acessado em: 2026-08-21)

Source: https://wiki.fcontext.com/pt-br/crypto/reorg-deposit-confirmation-policy/index.mdx
