Bitget pirateada em 351,6 milhões de dólares: estará o Lazarus por detrás?

A primeira transferência foi suficientemente pequena para parecer inofensiva: 0,84 Ether enviados de uma carteira identificada como pertencente à Bitget para um endereço recém-criado. O que se seguiu não foi. Stablecoins, ouro tokenizado, Ether, Avalanche, BNB e possivelmente 93,7 milhões de XRP circularam por várias redes, enquanto as carteiras recetoras convertiam e dispersavam os ativos rapidamente.

Aviso de segurança da CEO da Bitget, Gracy Chen, sobre o incidente de 351,6 milhões de dólares na carteira quente, de X, em 24 de setembro de 2026.

Aviso de segurança da Bitget estima o montante afetado em cerca de 351,6 milhões de dólares. A corretora afirma que os seus sistemas detetaram transferências não autorizadas às 18:31 UTC de 24 de setembro, que as carteiras frias permaneceram seguras, que os saldos dos utilizadores estavam corretos e que os levantamentos foram suspensos durante uma análise de segurança. Estas são divulgações importantes, mas ainda não explicam como um serviço de carteiras produziu transações que a empresa não pretendia autorizar.

Essa explicação em falta é o centro da história. A diretora-executiva da Bitget, Gracy Chen, descreveu um possível comprometimento da cadeia de fornecimento que afetou um serviço de carteiras de backend, em vez de uma chave privada divulgada. Separadamente, o investigador on-chain Specter associou parte do rasto de XRP roubado a fundos relacionados com o ataque à AFX de julho de 2026. Esse caso anterior foi atribuído ao TraderTraitor, um grupo de ameaças ligado à República Popular Democrática da Coreia (RPDC). A ligação é suficientemente específica para ser investigada, mas não é suficientemente conclusiva para afirmar como facto estabelecido que o atacante da Bitget pertence ao Lazarus Group.

O que aconteceu no ataque à Bitget

O rasto público das transações foi sendo revelado por partes, razão pela qual as primeiras estimativas foram muito inferiores ao valor final da Bitget. Os primeiros rastreadores concentraram-se em redes compatíveis com a Ethereum Virtual Machine (EVM) e contabilizaram cerca de 170 milhões a 183,8 milhões de dólares. Mais tarde, a Bitget incluiu um conjunto mais amplo de ativos e redes na sua estimativa de 351,6 milhões de dólares. A diferença aparente não é automaticamente uma contradição, mas ainda não foi publicada uma reconciliação transação a transação.

A sequência inicial mais clara é a seguinte:

• Teste inicial: Uma transferência de 0,84 Ether chegou a um endereço novo aproximadamente no mesmo minuto em que a Bitget afirma que os seus sistemas de segurança detetaram o incidente.

• Saídas de stablecoins: Segundo relatos, o endereço recebeu cerca de 34,75 milhões de Tether, 12,85 milhões de USD Coin e 3.000 unidades de Tether Gold de carteiras identificadas como pertencentes a corretoras.

• Conversão rápida: Na Arbitrum, um novo endereço separado utilizou cerca de 19,67 milhões de USDT0 para comprar aproximadamente 7 111 Ether através da UniswapX e da 1inch Fusion. Segundo relatos, algumas execuções pagaram um prémio de até 5%, o que sugere que a rapidez foi mais importante do que a eficiência do preço.

• Redes adicionais: Foram reportados cerca de 821 012 Avalanche e, posteriormente, uma transferência de 8,2 milhões de USD Coin a partir de infraestrutura identificada como pertencente à Bitget na Avalanche. Também surgiu atividade na BNB Chain na reconstrução mais ampla.

• Componente XRP: Segundo relatos, duas carteiras identificadas como pertencentes à Bitget enviaram um total combinado de 93,7 milhões de XRP para um novo endereço da XRP Ledger. Aos preços citados durante o incidente, essa componente valia cerca de 143 milhões de dólares e poderia explicar grande parte da diferença entre os totais iniciais das redes EVM e a estimativa da Bitget.

A divulgação inicial da Bitget sobre o incidente das carteiras de 24 de setembro de 2026, a estimativa dos fundos afetados e a suspensão temporária de levantamentos da Bitget, consultado em 25 de setembro de 2026, por volta das 02:40 UTC.

Por enquanto, afetado é o termo correto para o valor de 351,6 milhões de dólares. Ainda não se trata de um cálculo final das perdas líquidas. O valor final deverá subtrair quaisquer ativos que tenham permanecido sob o controlo da Bitget, que tenham sido congelados por emissores ou exchanges, que tenham sido devolvidos ou que tenham sido recuperados. Nenhuma dessas categorias tinha sido reconciliada publicamente até ao momento-limite da investigação.

O momento dos acontecimentos também merece atenção. A deteção às 18:31 UTC não interrompeu imediatamente todos os movimentos reportados. A transferência de 8,2 milhões de USD Coin na Avalanche foi reconstruída por volta das 20:55 UTC, mais de duas horas depois. Continuam a ser possíveis várias explicações: as transações assinadas podem já ter sido colocadas em fila, diferentes redes podem ter exigido medidas de contenção separadas ou o percurso comprometido pode ter continuado a conseguir submeter transações. Até a Bitget publicar os registos de assinatura e a cronologia da contenção, a deteção e a contenção não devem ser tratadas como o mesmo evento.

Porque é que as primeiras estimativas das perdas eram mais baixas

Os incidentes de blockchain raramente chegam acompanhados de uma fatura clara. Os analistas veem endereços diferentes em momentos diferentes, as etiquetas das carteiras podem estar desfasadas e um único conjunto de valor pode aparecer várias vezes ao ser convertido ou transferido entre redes. Somar todos os números de um feed em tempo real exageraria, por isso, a perda.

Três problemas contabilísticos influenciaram as estimativas da Bitget:

• As transferências e as conversões sobrepõem-se: Se 19,67 milhões de USDT0 forem convertidos em 7 111 Ether, o valor em dólares de ambos os ativos não pode ser somado como duas perdas separadas.

• As pontes criam duas componentes visíveis: Um ativo pode sair de uma cadeia e aparecer noutra. Contabilizar ambos os lados sem associar o evento da ponte duplica o mesmo valor.

• Os preços oscilaram durante o ataque: O Ether estava a ser comprado agressivamente enquanto os rastreadores avaliavam o fluxo. Um cálculo feito dez minutos depois poderia produzir um total diferente em dólares sem que tivesse ocorrido qualquer novo furto.

A componente de XRP é a maior parcela por esclarecer. Se os 93,7 milhões de XRP estivessem sob o controlo do mesmo atacante, a atividade EVM, juntamente com a transferência de XRP, aproximaria bastante mais a reconstrução externa dos 351,6 milhões de dólares. Se esse destino servisse uma função interna da Bitget ou outra contraparte legítima, a diferença exigiria uma explicação diferente. As etiquetas públicas, por si só, não conseguem determinar a titularidade.

Atividade na Ethereum associada ao principal endereço da Bitget mencionado no incidente, desde Etherscan, consultado em 25 de setembro de 2026. 

Uma autópsia adequada eliminaria grande parte desta ambiguidade ao publicar os endereços afetados, os hashes das transações, as funções das carteiras internas, os ativos transferidos, os ativos convertidos, os montantes congelados, os montantes recuperados e a perda final pendente. Sem esse registo, a estimativa de 351,6 milhões de dólares é credível como total interno da Bitget, mas não pode ser reproduzida de forma independente.

Como uma carteira pode enviar uma transação válida que a corretora nunca autorizou

Uma blockchain apenas verifica se uma transação cumpre as suas regras de autorização criptográfica. Não sabe se a equipa de risco da corretora aprovou o pagamento, se um funcionário viu o destino correto ou se um sistema de back-end comprometido forneceu dados de transferência falsos a um assinante que, de outro modo, estaria a funcionar normalmente.

Essa distinção ajuda a compreender a explicação preliminar de Chen. Ela afirmou que o incidente poderá assemelhar-se a um ataque à cadeia de fornecimento, no qual uma ferramenta de terceiros utilizada pela Bitget afetou um serviço de carteira crítico do back-end. Segundo esse relato, informações de transferência falsificadas chegaram a uma máquina de assinatura, embora o atacante não tivesse extraído diretamente uma chave privada. A possibilidade de um ato interno foi descrita como reduzida, não impossível, e o vetor final continuava sob investigação.

Num processo normal de levantamento, vários controlos devem estar de acordo antes de os fundos serem movimentados:

1. Um cliente ou um processo interno de tesouraria cria um pedido de transferência legítimo.

2. As verificações da conta, do dispositivo, do endereço e de risco determinam se o pedido é permitido.

3. Um motor de políticas verifica o ativo, a rede, o destino, o montante, a frequência e o limiar de aprovação.

4. Um ou mais componentes de assinatura autorizam os dados exatos da transação.

5. Um serviço de difusão envia a transação assinada para a rede.

6. Os sistemas de monitorização comparam o resultado com o pedido empresarial aprovado e interrompem atividades anormais subsequentes.

Comprometer qualquer uma das fases pode não ser suficiente se os controlos restantes forem genuinamente independentes. A preocupação no relato preliminar da Bitget é que um componente de software de confiança possa ter estado suficientemente próximo do fluxo de assinatura para influenciar aquilo que o signatário aprovou. Se o signatário validou apenas que um pedido provinha de um serviço autorizado, em vez de confirmar de forma independente o destino e o montante face a um registo de aprovação imutável, as assinaturas válidas poderiam ainda assim autorizar transferências maliciosas.

Os caminhos mais plausíveis para uma falha de controlo

Nenhum dos seguintes cenários foi provado, mas cada um produz uma conclusão diferente:

• Fornecedor ou atualização de software comprometidos: Um atacante corrompe uma dependência, ferramenta administrativa ou serviço utilizado no fluxo da carteira. A exchange pode confiar nos pedidos provenientes desse componente.

• Roubo de credenciais do backend: Uma conta de serviço, credencial de interface de programação de aplicações, sessão ou token privilegiado permite ao atacante fazer-se passar por um sistema interno autorizado.

• Contorno do motor de políticas: O pedido de assinatura chega ao signatário sem que sejam aplicados os limites normais, as listas de endereços autorizados, as verificações de frequência ou os limiares de aprovação.

• Manipulação da interface de assinatura: Os operadores humanos aprovam uma transação enquanto o sistema de assinatura recebe outra. Isto pode acontecer quando a apresentação e os dados assinados não estão associados de forma independente.

• Comprometimento de partilha de chave ou do signatário: Um sistema de múltiplas assinaturas ou de computação multipartidária (MPC) pode ainda falhar se o atacante comprometer signatários suficientes, o coordenador ou o processo de aprovação que os envolve.

• Acesso privilegiado de um funcionário interno ou contratado: Uma pessoa autorizada, ou um atacante que utilize o acesso dessa pessoa, envia ou aprova transferências maliciosas. Atualmente, a Bitget considera improvável uma ação interna, mas não publicou provas que a excluam.

A descrição da Bitget das carteiras quentes, mornas e frias não esclarece qual caminho falhou. Uma carteira quente foi concebida para transações online frequentes. Uma carteira morna acrescenta normalmente aprovações ou isolamento mais fortes, mantendo-se disponível para operações. Uma carteira fria mantém a autoridade de assinatura offline ou de outra forma separada dos sistemas de rotina ligados à Internet. Estes rótulos descrevem a utilização prevista, não os controlos efetivamente aplicados a cada endereço na noite da violação.

Rastreadores externos também classificaram pelo menos uma fonte como infraestrutura offline, enquanto a Bitget afirma que nenhuma carteira offline foi comprometida. Qualquer dos lados pode estar a utilizar uma classificação diferente. O conflito só pode ser resolvido através do mapeamento dos endereços públicos para as suas funções internas e da explicação de como cada assinante era operado.

Porque é que a velocidade de conversão é importante

O atacante não parecia interessado em manter um conjunto organizado dos ativos roubados. As stablecoins e o ouro tokenizado apresentam um problema óbvio para um ladrão: os emissores podem conseguir congelar os saldos identificados. O Ether é mais líquido nas plataformas descentralizadas e não tem um emissor central com um mecanismo de congelamento equivalente.

Pagar um prémio para adquirir Ether através de agregadores parece, portanto, menos irracional do que aparenta à primeira vista. Um atacante sofisticado pode aceitar uma execução desfavorável quando cada minuto aumenta a probabilidade de um emissor, bridge, exchange ou serviço de validadores bloquear o passo seguinte. O padrão de conversão sugere preparação, acesso a rotas previamente selecionadas e vontade de perder algum valor para melhorar a mobilidade.

Isto não identifica o atacante. A conversão rápida de stablecoins tornou-se um comportamento operacional padrão em muitos roubos de criptomoedas de grande escala. A técnica pode sustentar uma atribuição mais abrangente, mas não é suficiente por si só.

Porque se suspeita de hackers ligados à RPDC

A teoria da RPDC assenta em três tipos diferentes de provas: um comportamento semelhante ao de roubos anteriores ligados a Estados, indicadores técnicos privados descritos pelo diretor executivo da Bitget e uma alegação pública na cadeia que liga parte do rasto de XRP ao exploit anterior da AFX. Esses elementos não têm todos a mesma força, e combiná-los não os transforma automaticamente em prova.

1. O comportamento de branqueamento é familiar, mas não distintivo

A primeira pista é a rapidez do atacante. As stablecoins e o Tether Gold foram convertidos em Ether, os fundos foram divididos por endereços novos e a atividade atravessou várias redes. A notificação do Federal Bureau of Investigation sobre a Bybit descreveu os agentes TraderTraitor a converter rapidamente os ativos roubados e a dispersá-los por milhares de endereços e várias blockchains após o roubo de fevereiro de 2025.

Essa semelhança explica por que razão a RPDC entrou tão rapidamente na conversa. Continua a ser a camada mais fraca. Os grupos criminosos copiam rotas de branqueamento bem-sucedidas, os agregadores selecionam caminhos semelhantes para utilizadores não relacionados e qualquer atacante que detenha tokens passíveis de congelamento tem o mesmo incentivo para migrar para um ativo mais resistente à censura. «Trocaram rapidamente para Ether» é uma correspondência comportamental, não uma impressão digital.

2. A Bitget afirma que os indicadores de IP e VPN se assemelham aos de um grupo da RPDC

Chen também mencionou endereços de Protocolo de Internet (IP) e escolhas de redes privadas virtuais (VPN) que os investigadores associaram a um grupo ligado à RPDC. Os registos internos de acesso poderiam ser relevantes se mostrassem a mesma infraestrutura invulgar anteriormente controlada por um agente conhecido, especialmente quando acompanhados por evidências consistentes relativas a dispositivos, malware, domínios ou autenticação.

O público não viu esse material. Um endereço IP pode pertencer a uma VPN comercial, a um servidor comprometido, a um proxy residencial ou a outra vítima. Vários agentes podem passar pelo mesmo ponto de acesso, e um atacante cuidadoso pode pedir deliberadamente emprestada infraestrutura associada a um rival. Uma correspondência de IP só se torna convincente quando os investigadores explicam como o endereço foi atribuído, quem o controlava durante o minuto relevante e que outros indicadores o acompanhavam.

A hipótese da Bitget sobre a cadeia de fornecimento é compatível com técnicas operacionais conhecidas da RPDC, mas compatibilidade não é atribuição. Um documento conjunto de aconselhamento de cibersegurança TraderTraitor descreve engenharia social e aplicações de criptomoeda trojanizadas utilizadas para chegar aos funcionários e aos sistemas das empresas. Um relato posterior do FBI sobre o roubo da DMM Bitcoin explica como um falso recrutador, um teste de programação malicioso, informações de sessão roubadas e a manipulação de um pedido legítimo de transação foram associados numa única operação.

Esses precedentes mostram que os operadores da RPDC visaram as camadas humana e de software em torno das carteiras de criptomoedas, e não apenas as chaves privadas. Não mostram que o mesmo método de entrada foi utilizado contra a Bitget. A corretora ainda precisa de identificar o componente comprometido, a via de acesso inicial, as credenciais afetadas e a falha da política de assinatura.

3. TraderTraitor é um rótulo específico de ameaça, não um sinónimo de todos os ataques a criptomoedas

TraderTraitor é a designação do governo dos EUA para determinadas atividades cibernéticas maliciosas norte-coreanas dirigidas à indústria da blockchain e das criptomoedas. O mesmo ecossistema mais amplo também pode ser referido por designações como Lazarus Group, APT38, Jade Sleet, UNC4899 ou Slow Pisces, dependendo da agência, da empresa de segurança, da operação e do período.

Estas designações sobrepõem-se, mas não são atalhos intercambiáveis. Dizer que um grupo relacionado com a AFX foi atribuído ao TraderTraitor não prova que todos os endereços ligados sejam operados pelas mesmas pessoas, nem prova que a intrusão na Bitget tenha utilizado o mesmo malware ou a mesma equipa de acesso. Grandes programas ligados a Estados podem envolver diferentes operadores, infraestruturas, intermediários e especialistas em branqueamento.

A terminologia é importante porque “o Lazarus pirateou a Bitget” soa definitivo. As provas disponíveis à data-limite sustentam uma frase mais restrita: Suspeita-se de agentes ligados à RPDC porque um investigador externo associou o rasto de XRP a um percurso de fundos da AFX associado ao TraderTraitor, enquanto a Bitget afirma que os indicadores internos de IP e VPN apontam na mesma direção.

4. O que transformaria a suspeita numa atribuição defensável

Um caso público mais sólido combinaria provas independentes de várias camadas:

• Rastreio reproduzível na blockchain: Hashes exatos das transações de XRP e entre cadeias, eventos de bridge, endereços controlados pelo agente, regras de agrupamento e uma explicação de qualquer exposição através de serviços partilhados.

• Provas relativas à infraestrutura: Domínios, servidores, certificados, contas VPN, histórico de proxies ou erros operacionais associados a infraestruturas anteriormente controladas pelo mesmo agente.

• Provas da intrusão: Malware, scripts, tráfego de comando e controlo, roubo de credenciais, sequestro de sessões ou um pacote de fornecedor comprometido com sobreposição de código ou infraestrutura.

• Coerência cronológica: Prova de que o agente controlava os endereços e a infraestrutura associados no momento de ambos os incidentes, da AFX e da Bitget.

• Análise independente: Uma empresa forense identificada, um consórcio de exchanges ou uma autoridade pública que reproduza a conclusão, em vez de repetir uma designação das redes sociais.

• Atribuição por uma autoridade pública: Uma declaração governamental que identifique o agente e publique endereços ou indicadores técnicos suficientes para que o setor possa agir.

O caso da Bybit em 2025 fornece uma referência útil. Cinco dias após o roubo, o FBI atribuiu publicamente o incidente à Coreia do Norte, identificou o TraderTraitor, descreveu o comportamento de branqueamento e divulgou dezenas de endereços Ethereum relacionados. O caso da Bitget tinha apenas algumas horas no momento-limite deste artigo. A falta de uma confirmação equivalente ainda não é surpreendente, mas significa que a formulação deve permanecer provisória.

5. O que poderia enfraquecer a teoria da Coreia do Norte

A hipótese atual perderia força se a suposta sobreposição com a AFX acabasse por ser um endereço partilhado de uma exchange, bridge ou serviço; se o destino XRP não fosse controlado pelo atacante; se a cronologia mostrasse que a carteira comum mudou de mãos; ou se a própria atribuição à AFX não pudesse ser reproduzida de forma independente. Também ficaria enfraquecida se as provas de backend da Bitget apontassem para um grupo de intrusão diferente ou para um elemento interno motivado financeiramente.

Existe também o risco de uma operação de falsa bandeira. Depois de os padrões de branqueamento do Lazarus serem amplamente documentados, outro grupo pode imitá-los. Copiar uma rota de swap é fácil. Recriar um conjunto de carteiras ativo durante muito tempo, uma infraestrutura privada, uma linhagem de malware e erros operacionais é muito mais difícil.

O veredicto mais justo é, portanto pista credível, atribuição incompleta. A teoria da Coreia do Norte tem mais substância do que um rumor anónimo, porque inclui uma ligação proposta entre fundos de incidentes distintos e um indício separado de infraestrutura do lado da empresa. Continua aquém do padrão necessário para afirmar que o Lazarus Group realizou o ataque à Bitget.

O que a Bitget ainda precisa de explicar

O primeiro comunicado da exchange respondeu às perguntas mais urgentes dos clientes: ocorreu um incidente, os levantamentos foram suspensos e a empresa afirmou que os saldos e as carteiras frias continuavam seguros. O próximo relatório tem de passar da tranquilização para as provas.

Os elementos em falta são concretos:

• Causa principal: Que software, fornecedor, serviço, credencial ou camada de aprovação foi comprometido?

• Processo de assinatura: O atacante produziu novas assinaturas, manipulou os dados das transações antes da assinatura ou abusou de transações já autorizadas?

• Infraestrutura afetada: Que endereços eram quentes, mornos ou frios, e que controlos de carteira se aplicavam a cada um deles?

• Contenção: Por que motivo as transferências reportadas continuaram após a deteção e quando foi efetivamente desativado o percurso malicioso?

• Reconciliação das perdas: Como chega a exchange a $351.6 milhões entre ativos e redes sem contabilizar duas vezes os swaps ou as bridges?

• Recuperação: Quanto foi congelado, devolvido ou recuperado, e quanto permanece fora do controlo da Bitget?

• Acesso dos clientes: Quando serão reabertos os levantamentos, em que redes e com que limites ou condições de fila?

• Remediação: Que controlos foram alterados antes de o mesmo percurso de assinatura ou backend voltar a ser considerado fiável?

• Atribuição: Que provas sustentam a suspeita de envolvimento da RPDC e um investigador externo identificado reproduziu-a?

Por volta das 02:40 UTC de 25 de setembro, os levantamentos continuavam oficialmente suspensos e o relatório do incidente prometido para 24 horas ainda não era devido. O facto de os depósitos e a negociação continuarem operacionais não responde à mesma questão que os levantamentos. Um saldo num livro-razão interno só se torna efetivamente significativo quando o cliente o pode resgatar através de um processo de levantamento funcional e seguro.

O Fundo de Proteção da Bitget pode cobrir a perda?

A Bitget afirma que o seu Fundo de Proteção do Utilizador detém mais de 464 milhões de dólares e cobre integralmente o montante afetado de 351,6 milhões de dólares. Os seus materiais públicos identificam 5 500 Bitcoin como a participação principal. A um preço do Bitcoin de cerca de 84 403 dólares, essa posição valeria aproximadamente 464,2 milhões de dólares.

A aritmética está correta a esse preço, mas a margem é mais reduzida do que o título sugere:

• Cobertura nominal: Cerca de 132% da estimativa dos fundos afetados.

• Bitcoin necessário: Aproximadamente 4 166 Bitcoin para igualar 351,6 milhões de dólares.

• Fundo utilizado: Cerca de 75,7% se a totalidade da perda fosse paga a partir dessa posição em Bitcoin.

• Remanescente nominal: Cerca de 1 334 Bitcoin, antes dos custos de transação, da variação do preço, de outros pedidos elegíveis ou do impacto no mercado.

• Preço de equilíbrio: Cerca de 63 927 dólares por Bitcoin reduziriam 5 500 Bitcoin ao valor da perda reclamada.

Mais importante ainda, o fundo é uma reserva controlada pela empresa, não um seguro de depósitos garantido pelo Estado. As provas públicas ainda não demonstraram se os ativos estão segregados, livres de ónus, imediatamente transferíveis ou formalmente comprometidos com este incidente. A questão útil já não é saber se 464 milhões de dólares são superiores a 351,6 milhões de dólares. É saber se o fundo pode ser verificado e mobilizado sem criar um segundo problema de liquidez.

O setembro relatório de Prova de Reservas (PoR) acrescenta contexto, não uma conclusão. A Bitget publicou um rácio de reservas agregado de 135% em 19 ativos antes da violação. Essa fotografia pode mostrar que os ativos cobertos excediam os saldos correspondentes incluídos no momento da medição. Não pode mostrar a posição após o incidente, provar que todas as responsabilidades foram incluídas ou demonstrar que os controlos das carteiras são seguros.

O que os traders devem verificar após uma violação numa exchange

A segurança de uma corretora não pode ser reduzida a uma única percentagem, certificação, fundo do tipo seguro ou alegação sobre armazenamento a frio. A abordagem útil consiste em analisar várias camadas e compreender o que cada uma pode, ou não, comprovar.

• Comportamento dos levantamentos: Teste se os levantamentos funcionam nos ativos e redes que realmente utiliza. Um pequeno levantamento bem-sucedido é mais informativo do que um saldo apresentado internamente.

• Evidência das reservas: Procure instantâneos recentes de ativos e passivos, provas de propriedade das carteiras, relatórios históricos e uma forma de verificar se o seu próprio saldo foi incluído.

• Segurança operacional: Analise o modelo de custódia, a separação dos signatários, os controlos de endereços, a monitorização, a resposta a incidentes e os testes independentes.

• Divulgação empresarial: Verifique a entidade operadora, a jurisdição, os termos legais, os relatórios financeiros e se os ativos dos clientes são tratados separadamente.

• Histórico de incidentes: Leia as análises pós-incidente, não apenas os anúncios. A qualidade da resposta é visível nos endereços, cronologias, causas-raiz e detalhes das medidas corretivas que publica.

• Controlos da conta: Ative a autenticação de dois fatores (2FA) através de uma aplicação, utilize uma palavra-passe única, ative um código anti-phishing, reveja os dispositivos ativos e aplique listas de permissões para levantamentos, quando disponíveis.

• Limites de custódia: Mantenha numa plataforma centralizada apenas o montante necessário para negociar ou efetuar transferências a curto prazo. A autocustódia elimina o risco de custódia da corretora, mas introduz os seus próprios riscos de gestão e recuperação de chaves.

Comparação da transparência das principais corretoras de criptomoedas

Esta não é uma classificação de segurança. Cada linha descreve uma forma pública de verificação disponível em 25 de setembro de 2026 e a questão que pode ajudar a responder. Nenhuma comprova que uma corretora não possa ser pirateada, que tenha divulgado todos os passivos ou que mantenha os levantamentos abertos durante uma crise.

O que a comparação entre corretoras revela efetivamente

A tabela não produz um vencedor universal, porque as corretoras divulgam diferentes tipos de evidência. A Coinbase fornece informação empresarial convencional através de demonstrações financeiras trimestrais e auditorias independentes anuais. A Binance e a OKX publicam sistemas criptográficos de reservas com dados das carteiras e ferramentas de verificação dos utilizadores. A Kraken combina a verificação ao nível da conta com rácios de reservas para os ativos suportados, enquanto a Bybit e a Toobit fornecem formas baseadas em Merkle para os utilizadores verificarem se os seus saldos foram incluídos num determinado instantâneo de reservas.

Estas divulgações respondem a perguntas relacionadas, mas diferentes:

• Prova de Reservas: A exchange apresentava ativos cobertos suficientes para corresponder aos saldos dos clientes incluídos num determinado momento?

• Verificação da inclusão do utilizador: Pode um indivíduo confirmar que o seu saldo foi contabilizado entre os passivos reportados?

• Prova de propriedade das carteiras: A exchange demonstrou controlar os endereços apresentados como reservas?

• Demonstrações financeiras: Como se apresentam os ativos, passivos, receitas, despesas, riscos e obrigações societárias mais abrangentes da empresa?

• Avaliações de segurança: Especialistas externos testaram partes da plataforma, das aplicações, da infraestrutura de custódia ou dos controlos internos?

• Fundos de proteção: A exchange reservou um fundo separado que possa responder a incidentes de segurança definidos?

Nenhum elemento isolado responde a tudo. Uma exchange pode deter reservas suficientes e, ainda assim, sofrer um comprometimento de uma carteira. Pode passar uma avaliação de segurança e, mais tarde, introduzir uma integração vulnerável. Pode manter um fundo de proteção sem provar a rapidez com que esse fundo pode ser mobilizado. Também pode publicar demonstrações financeiras auditadas sem oferecer aos utilizadores uma forma criptográfica de verificar a inclusão dos seus saldos individuais.

A comparação útil não é simplesmente qual exchange apresenta a maior percentagem. É saber quantas camadas independentes podem ser verificadas, quão atuais são essas camadas e se as provas correspondem ao risco que está a ser avaliado.

Porque é que a Prova de Reservas não pode provar a segurança das carteiras

A PoR pode mostrar que existiam ativos cobertos correspondentes aos saldos dos clientes incluídos num instantâneo definido. Não foi concebida para provar que é impossível comprometer os sistemas que controlam esses ativos.

O incidente da Bitget torna essa distinção particularmente clara. O seu relatório de setembro mostrou um rácio agregado de reservas de 135% em 19 ativos antes da violação. O excedente reportado não impediu que uma via de transação não autorizada movimentasse fundos. O problema sob investigação diz respeito às operações das carteiras, à autorização de transações ou ao software que as envolve, e não simplesmente ao facto de os ativos aparecerem em carteiras de reserva antes do incidente.

Um relatório de reservas pode ajudar a responder:

• Os saldos dos clientes abrangidos foram incluídos no cálculo dos passivos?

• As carteiras divulgadas continham uma quantidade suficiente dos ativos relevantes?

• Os utilizadores podiam verificar a sua inclusão através de um caminho de Merkle ou de outro método criptográfico?

• Existe um histórico de relatórios que possa ser comparado ao longo do tempo?

Em geral, não pode responder:

• Um sistema de backend comprometido pode enviar um pedido de assinatura malicioso?

• As políticas de levantamento são aplicadas independentemente da aplicação que cria a transação?

• Poderia um funcionário, contratante ou fornecedor influenciar várias camadas de aprovação?

• Estão incluídas todas as dívidas empresariais, responsabilidades contingentes, empréstimos e obrigações legais?

• Os levantamentos continuarão normalmente durante um incidente de segurança ou um choque de liquidez?

• Pode um fundo de proteção ser acedido imediatamente e sem restrições?

• A próxima versão do software preservará os controlos testados na avaliação anterior?

A transparência das reservas e a segurança das transações exigem, portanto, avaliações separadas. A PoR trata principalmente da cobertura por ativos num determinado momento. A segurança das carteiras trata da forma como as transações são solicitadas, aprovadas, assinadas, transmitidas, monitorizadas e interrompidas quando algo corre mal.

A Bybit oferece um exemplo histórico útil. A exchange tinha divulgações de reservas e ferramentas de verificação de utilizadores antes da violação de 2025, mas o incidente envolveu um problema diferente relacionado com o fluxo de assinatura. As provas relativas às reservas continuaram a ter valor, mas não funcionaram como proteção contra a manipulação de transações.

A Bitget enfrenta agora um encargo semelhante de explicação. Um novo instantâneo das reservas poderia ajudar a medir o efeito financeiro da perda. Não substituiria a necessidade de uma descrição técnica do serviço comprometido e dos controlos de autorização que falharam.

Como ler os rácios de reservas sem ser induzido em erro

Um rácio de reservas superior a 100% parece tranquilizador, mas o número precisa de contexto. Um rácio de 106% significa que as reservas divulgadas para esse ativo excediam os saldos correspondentes incluídos em cerca de 6% no momento do instantâneo. Não significa que a exchange tenha uma almofada de capital de 6% contra todas as perdas possíveis.

Vários detalhes determinam a utilidade da percentagem:

• Âmbito dos ativos: Um relatório que abranja quatro ativos principais não é equivalente a um que abranja 19 ou 22 ativos.

• Âmbito das responsabilidades: O relatório deve explicar que tipos de contas, empréstimos, posições de margem ou outras obrigações entraram no cálculo.

• Data do instantâneo: Um relatório anterior ao incidente não pode estabelecer a posição financeira da exchange após uma perda avultada.

• Provas relativas às carteiras: Os leitores devem poder ver como a exchange demonstrou o controlo dos endereços divulgados.

• Verificação dos utilizadores: Um rácio de destaque é mais sólido quando os clientes podem verificar de forma independente se os seus saldos foram incluídos.

• Continuidade histórica: Relatórios arquivados regularmente facilitam a identificação de alterações abruptas nas reservas ou na cobertura.

• Revisão externa: Uma verificação independente pode aumentar a confiança, embora o revisor, a metodologia e o âmbito testado continuem a ser importantes.

Uma percentagem mais elevada pode refletir um excedente genuíno, mas também pode ser influenciada por um conjunto restrito de passivos, saldos temporários, movimentos nos preços dos ativos ou pela exclusão de produtos não abrangidos pelo relatório. Comparar percentagens principais sem comparar o âmbito cria uma hierarquia falsa.

Pela mesma razão, uma exchange mais pequena que reporte quatro ativos não deve ser descrita como mais transparente do que uma exchange maior apenas porque uma das suas percentagens é mais elevada. A abrangência do relatório, a metodologia dos passivos, as provas relativas às carteiras, a frequência e o processo de verificação dos utilizadores são igualmente importantes.

Onde se enquadra a Toobit na comparação

As divulgações públicas da Toobit abrangem duas questões distintas. O relatório de reservas de setembro aborda se quatro ativos importantes excediam os saldos correspondentes dos utilizadores num determinado momento. As suas páginas de segurança descrevem como a exchange afirma proteger esses ativos e as contas dos utilizadores durante as operações normais.

Estas divulgações são mais úteis quando analisadas separadamente. Um rácio de reservas pode mostrar a cobertura dos ativos num determinado momento, enquanto uma prova de Merkle pode ajudar um utilizador a verificar se o saldo de uma conta foi incluído no conjunto de passivos reportado. Nenhum dos dois comprova que todas as carteiras, sistemas internos ou transações futuras permanecerão seguros.

Os rácios de reservas da Toobit

Rácios de reservas da Toobit para BTC, ETH, USDT e USDC em1 de setembro de 2026, UTC, de Toobit, consultado em 25 de setembro de 2026.

Os quatro rácios estavam acima de 100% nesse momento. Isto significa que as reservas divulgadas para cada ativo abrangido excediam os saldos correspondentes dos utilizadores incluídos no relatório. O valor acima de 100% diferia consoante o ativo, variando entre uma margem de 2% para Ether e uma margem de 6% para Tether.

Estas percentagens não devem ser somadas nem tratadas como um único rácio de capital de toda a exchange. Cada uma compara a reserva de um determinado ativo com o saldo correspondente dos utilizadores incluídos. O rácio de 106% para Tether, por exemplo, não diz, por si só, nada sobre passivos denominados noutro ativo.

O âmbito é tão importante como as percentagens. Este relatório abrange quatro ativos amplamente utilizados, enquanto as divulgações indicadas para a Bitget e a OKX abrangem um número maior de ativos. O relatório da Toobit é útil para verificar as quatro reservas nomeadas, mas não comprova a cobertura de todos os tokens ou produtos disponíveis na plataforma.

Como os utilizadores podem verificar a inclusão do saldo

Um rácio de reservas publicado continua a ser um valor ao nível da empresa até que os utilizadores possam verificar se os seus próprios saldos foram incluídos no cálculo das responsabilidades. A página de Prova de Reservas da Toobit disponibiliza uma raiz de Merkle e um processo de verificação para esse efeito.

Uma árvore de Merkle converte os registos de contas individuais em hashes criptográficos e combina-os num único valor raiz. Um utilizador pode então verificar se um saldo fez parte do instantâneo sem expor as informações das contas de todos os outros clientes.

Interface da raiz de Merkle e de verificação da inclusão de contas da Toobit para o seu sistema de Prova de Reservas, de Toobit, consultada em 25 de setembro de 2026.

A ferramenta de Merkle resolve uma fragilidade importante de um simples anúncio de reservas. Permite aos utilizadores verificar se as suas contas foram contabilizadas, em vez de lhes pedir que aceitem apenas uma percentagem agregada.

Essa verificação continua a ter limites. A inclusão mostra que um saldo entrou na estrutura de responsabilidades comunicada. Não prova, por si só, que todas as responsabilidades foram incluídas, que os ativos divulgados estavam livres de ónus ou que a exchange manterá a mesma posição de reservas após o instantâneo.

Uma verificação pessoal útil deve responder a três perguntas:

1. O registo de verificação corresponde à data correta da auditoria?

2. Inclui os ativos e saldos que o utilizador detinha nesse instantâneo?

3. A prova pode ser verificada através do processo de verificação fornecido ou de uma ferramenta de código aberto?

Uma verificação de inclusão bem-sucedida reforça a ligação entre a conta do utilizador e o relatório de reservas publicado. Não transforma o relatório numa auditoria financeira completa.

Os controlos que envolvem as reservas

A cobertura das reservas e a segurança das carteiras abordam riscos diferentes. Um instantâneo de reservas pode mostrar se determinados ativos cobriam os saldos correspondentes dos utilizadores num momento específico. A questão seguinte é saber como uma exchange protege esses ativos, controla o acesso às transações e reage quando surge atividade suspeita.

A Toobit organiza o seu quadro Bee-Safe em seis áreas:

• Prova de Reservas: Cobertura de ativos que os utilizadores podem verificar através do sistema de reservas da exchange.

• Infraestrutura resiliente: Infraestrutura multi-nuvem destinada a suportar a disponibilidade da plataforma e a atividade de negociação.

• Salvaguardas proativas: Autenticação multifator, armazenamento a frio e auditorias contínuas.

• Segurança dos dados: Arquitetura de confiança zero, encriptação e controlos de deteção de phishing.

• Privacidade completa: Medidas de proteção de dados que incluem segurança de conhecimento zero e controlos biométricos.

• Defesa ativa 24/7: Monitorização e suporte contínuos destinados a detetar e responder a atividades suspeitas.

O quadro Bee-Safe da Toobit, que abrange Prova de Reservas, resiliência da infraestrutura, salvaguardas de contas, segurança de dados, privacidade e monitorização ativa por parte da Toobit, em 25 de setembro de 2026.

Estas camadas abrangem riscos que um rácio de reservas não consegue medir. A Prova de Reservas aborda a cobertura dos ativos, enquanto os controlos de autenticação e contra phishing funcionam ao nível da conta. O armazenamento a frio diz respeito à custódia, a encriptação protege dados sensíveis e a monitorização contínua destina-se a identificar atividades anormais antes que se propaguem.

O quadro mostra quais as salvaguardas que a Toobit afirma ter implementadas, mas a existência de um controlo não prova que este funcionará perfeitamente em todos os incidentes. O seu valor prático depende da forma como os controlos são implementados, testados, revistos de forma independente e atualizados quando surgem novas vulnerabilidades.

A leitura equilibrada da divulgação da Toobit

A Toobit disponibiliza três camadas visíveis de transparência:

1. Rácios de reservas ao nível dos ativos para quatro ativos importantes no relatório de setembro.

2. Inclusão de saldos baseada em Merkle que os utilizadores podem verificar face ao instantâneo relevante.

3. Controlos de segurança publicados que abrangem o acesso às contas, a custódia, a infraestrutura, os testes e a preparação para incidentes.

Essa combinação dá aos utilizadores mais elementos para analisar do que uma declaração geral de que os ativos estão seguros. O anúncio das reservas fornece dados históricos fixos, o painel de PoR disponibiliza um método de verificação e a página de Segurança identifica os controlos que a Toobit afirma protegerem as reservas.

As limitações devem continuar visíveis juntamente com esses pontos fortes. O relatório de setembro abrange quatro ativos, e não todos os tokens disponíveis na plataforma. A PoR é um instantâneo, e não uma prova contínua de solvência. A inclusão de Merkle não revela todas as responsabilidades da empresa. Os controlos de segurança podem reduzir o risco sem eliminar falhas de software, de fornecedores, operacionais, internas ou dos sistemas de assinatura.

As provas sustentam, por conseguinte, uma conclusão qualificada: a Toobit oferece um processo prático e verificável pelos utilizadores para as reservas de Bitcoin, Ether, Tether e USD Coin, juntamente com vários controlos de contas e de custódia descritos publicamente. Os leitores devem avaliar essas provas dentro do seu âmbito específico, em vez de considerarem a violação da Bitget como prova automática de que outra exchange é mais segura.

O que uma tabela comparativa não consegue captar

Uma tabela pode organizar as divulgações, mas não consegue reproduzir a experiência de utilizar uma exchange durante um período de tensão. A execução de levantamentos, a resposta do apoio, a comunicação de incidentes, as restrições regionais, a liquidez e as revisões de contas podem mudar mais depressa do que um relatório de reservas.

O acesso legal também difere entre países. Dois utilizadores que abram a mesma marca global podem interagir com entidades operacionais, produtos, parceiros de pagamentos, acordos de custódia ou termos contratuais diferentes. Um serviço disponível numa jurisdição pode ser limitado ou não estar disponível noutra.

Antes de escolher uma exchange, os leitores devem verificar:

1. Se o ativo e a rede necessários são suportados.

2. As comissões atuais de depósito, negociação, conversão e levantamento.

3. Os limites de levantamento e os requisitos de verificação da conta.

4. A data e o âmbito dos ativos abrangidos pela divulgação de reservas mais recente.

5. Se é possível verificar a inclusão do saldo individual.

6. O histórico de incidentes da exchange e a qualidade das suas análises pós-incidente.

7. As proteções de conta e os controlos de levantamento disponíveis.

8. Se um pequeno levantamento de teste é concluído com sucesso.

9. Quanto capital precisa realmente de permanecer sob custódia da exchange.

Essa questão final é frequentemente ignorada. Escolher uma exchange não implica manter todos os ativos lá indefinidamente. Os traders podem separar o capital de negociação ativo das posições de longo prazo e decidir quais os riscos que estão preparados para gerir. A custódia centralizada introduz risco da plataforma e da contraparte. A autocustódia retira a exchange do processo de assinatura, mas torna o proprietário responsável pelas chaves privadas, cópias de segurança, segurança dos dispositivos, planeamento sucessório e erros irreversíveis.

A comparação é, por isso, um ponto de partida para a devida diligência. Mostra quais as alegações que podem ser verificadas e onde permanecem as lacunas. Não transforma nenhuma exchange num custodiante isento de riscos.

O verdadeiro teste é o que acontece a seguir

O roubo em si já não está em dúvida. As questões em aberto são saber se a Bitget consegue produzir um registo reproduzível das perdas, repor os levantamentos em segurança, demonstrar a disponibilidade do Fundo de Proteção e explicar como um sistema de confiança enviou transações não autorizadas.

A hipótese da RPDC merece ser investigada porque duas linhas independentes apontam nessa direção: as pistas da infraestrutura privada da Bitget e a ligação proposta pela Specter entre o percurso do XRP e o roubo da AFX. Nenhuma das linhas é suficientemente pública para encerrar o caso. Uma análise pós-incidente sólida deve separar aquilo que a exchange sabe daquilo que suspeita, e uma atribuição credível deve permitir que investigadores externos reproduzam a cadeia.

Até lá, a descrição mais honesta é simples. A Bitget sofreu um incidente grave numa carteira multi-chain, envolvendo cerca de 351,6 milhões de dólares em fundos afetados. Está a ser investigada uma falha de backend ou da cadeia de fornecimento. Suspeita-se do envolvimento de atores ligados à RPDC, mas tal não está confirmado. Os levantamentos, a perda líquida final, a utilização dos fundos e o controlo que falhou são os factos que ainda podem alterar a história.

Faça a sua própria pesquisa (DYOR). Este artigo baseia-se em divulgações públicas sobre o incidente e em informações on-chain disponíveis na data de corte indicada. Não confirma a identidade do atacante nem a solvência da Bitget, não garante a recuperação dos fundos e não recomenda nenhuma exchange específica. Antes de tomar uma decisão financeira, verifique o estado mais recente dos levantamentos, os relatórios de reservas, a disponibilidade na sua região, as comissões e os riscos de custódia.

Como comprar criptomoedas na Toobit

Para comprar criptomoedas na Toobit, crie uma conta ou inicie sessão, conclua a verificação de identidade quando necessário e abra a página Comprar criptomoedas. Selecione a criptomoeda que pretende receber, escolha um método de pagamento disponível e introduza o montante da compra.

Antes de confirmar a transação, reveja a taxa de câmbio apresentada, as comissões de pagamento, os limites de compra e o montante final que irá receber. As moedas suportadas, os métodos de pagamento, os requisitos da conta e a disponibilidade dos produtos podem variar consoante a localização.

Compre criptomoedas na Toobit agora.

Aviso de risco

Os criptoativos são altamente voláteis e podem perder uma parte substancial do seu valor. Negociar e deter criptomoedas envolve riscos, incluindo perdas de mercado, incidentes de segurança e interrupções que podem afetar o acesso aos fundos. A Prova de Reservas e os fundos de proteção podem oferecer transparência e proteção adicionais, mas não eliminam o risco. A negociação com alavancagem envolve riscos adicionais e pode conduzir a perdas rápidas ou à liquidação. Considere sempre a sua situação financeira e tolerância ao risco antes de negociar.