Por Joey Awwad | Usuário da Binance desde 2019 | Anjo da Binance
Há momentos em que você para de rolar a tela, lê algo duas vezes e realmente precisa de alguns segundos para processar o que acabou de ver. 29 de outubro de 2026 foi um desses momentos. A Binance, plataforma que uso desde 2019 e onde comecei minha jornada no mundo das criptomoedas com apenas 20 dólares que meu primo me deu, havia sofrido um grave incidente de segurança. Os números eram quase impossíveis de compreender. Aproximadamente 6,34 bilhões de dólares em ativos digitais haviam sido afetados. Seis bilhões. Trezentos e quarenta milhões. De dólares. Deixe isso cair a ficha.
Enquanto utilizador, investidor, trader e Binance Angel, esta não foi apenas mais uma manchete sobre outra corretora a sofrer um problema de segurança. Foi diferente. Passei anos a aprender através da Binance, a fazer trading na Binance, a participar na sua comunidade, a assistir a eventos, a partilhar conteúdos educativos e a incentivar as pessoas à minha volta a compreender as oportunidades e os riscos deste setor. Também passei anos a explicar às pessoas por que razão confio nesta plataforma. Por isso, naturalmente, acompanhei atentamente cada atualização. Mas quero deixar algo claro desde o início: não ia fingir que o incidente era insignificante. Foi grave, preocupante e merecia responsabilização. No entanto, estar preocupado com um incidente de segurança e perder imediatamente a confiança numa plataforma são duas coisas diferentes.
Não entrei em pânico. Não decidi de repente que oito anos de experiência não significavam nada. E certamente não vi motivos para abandonar uma plataforma antes de perceber o que tinha acontecido e, mais importante ainda, como iria reagir. O que se seguiu foi um incidente de segurança, uma investigação complexa, uma corrida contra o tempo, a reposição de milhares de milhões em ativos, a reconstrução da infraestrutura e uma operação de recuperação que merece ser devidamente documentada.
Esta é a história do que aconteceu, de como aconteceu, do que a Binance fez a seguir e da razão pela qual, enquanto utilizador e Binance Angel, esta experiência reforçou em mim algo importante sobre responsabilização.
Não começou a 29 de outubro. Uma das coisas mais interessantes sobre este incidente é que o ataque não começou no dia em que os fundos foram transferidos. De acordo com a investigação inicial da Binance, os atacantes preparavam há meses a sua entrada na infraestrutura da empresa. O primeiro acontecimento relevante remonta a junho de 2026. Um engenheiro da equipa Wallet DevOps da Binance, identificado na investigação como Engenheiro A, descarregou uma instalação adulterada do Homebrew enquanto procurava uma ferramenta popular de programação com IA. A instalação comprometida foi concebida para introduzir atividades maliciosas no ambiente de desenvolvimento. A equipa de segurança da Binance detetou uma anomalia, substituiu o dispositivo afetado e, por precaução, alterou as credenciais relacionadas. No entanto, os atacantes já tinham obtido informações valiosas sobre a função do engenheiro e os colegas ligados à equipa de infraestrutura das carteiras. Depois chegou setembro. Um segundo funcionário, o Engenheiro de Software B, foi abordado através de uma plataforma legítima de procura de emprego. Alguém que se fazia passar por diretor de projeto contactou-o a propósito de uma possível oportunidade numa empresa fictícia. A abordagem foi cuidadosamente preparada. Primeiro, houve uma entrevista com alguém que dizia ser representante dos recursos humanos. Foi realizada através de uma videochamada em direto. Para ganhar credibilidade, o entrevistador partilhou uma conta de redes sociais com fotografias e vídeos pessoais, criando a aparência de uma pessoa real com presença online estabelecida. Depois veio a segunda entrevista. Desta vez, a conversa decorreu através de uma aplicação popular de mensagens. Perto do fim da entrevista, pediram ao Engenheiro B que descarregasse um exercício de programação. Esse exercício era a armadilha.
O repositório continha código malicioso que era executado durante o processo de configuração no computador de trabalho do engenheiro. O malware utilizava técnicas sofisticadas de ofuscação, substituía um componente legítimo de uma ferramenta de desenvolvimento por uma versão maliciosa e estabelecia comunicação com um servidor externo controlado pelos atacantes. Tratava-se de uma ameaça de dia zero que não foi detetada pelas ferramentas de segurança de terminais que estavam implementadas na altura. Por outras palavras, não foi alguém a adivinhar uma palavra-passe ou a explorar uma vulnerabilidade simples num sistema de levantamentos. Os atacantes combinaram engenharia social, software malicioso, dispositivos comprometidos e acesso interno para avançarem até um alvo muito mais sensível. E esse alvo era a infraestrutura das carteiras.
20 de outubro: os atacantes avançam mais profundamente. A data importante seguinte foi 20 de outubro de 2026. De acordo com a investigação da Binance, os atacantes usaram o computador comprometido do Engenheiro B e uma ferramenta interna de IA para assumir o controlo das contas e dos acessos de outros dois funcionários: o Engenheiro A, da equipa Wallet DevOps, e o Engenheiro de Software C. Durante este processo, os atacantes descobriram que o Engenheiro A tinha no computador um token de permissão de implementação de contentores. Esta foi uma descoberta crucial. Um token de implementação pode proporcionar acesso a sistemas responsáveis pela execução de software e serviços. Nas mãos erradas, esse acesso pode tornar-se uma ponte para a infraestrutura, que nunca deveria estar sob o controlo de uma pessoa não autorizada. Os atacantes tinham agora um caminho até às operações de assinatura das carteiras.
29 de outubro: o dia em que tudo aconteceu. A fase final começou a 29 de outubro. Entre as 17:15 e as 19:56 UTC, os atacantes acederam ao computador do Engenheiro de Software C, usaram credenciais roubadas ao Engenheiro A, implementaram um contentor e ativaram um script malicioso. O ambiente comprometido deu-lhes acesso não autorizado a um serviço interno de assinatura de transações de carteiras. É aqui que a parte técnica se torna particularmente importante. Um serviço de assinatura de carteiras é responsável por autorizar transações em blockchain. É um componente de segurança crítico, porque as transações têm de ser assinadas antes de poderem ser transmitidas para uma blockchain. Os atacantes abusaram deste acesso para iniciar transações fora do processo normal de levantamento da Binance. Por volta das 20:05 UTC, começaram as movimentações suspeitas de ativos. Entre as 20:05 e as 20:09 UTC, cinco hot wallets da Binance transferiram aproximadamente 233.46 milhões de XRP para um endereço controlado pelos atacantes. Os atacantes também transferiram aproximadamente: 970,500 SOL através de hot wallets da Binance na Solana. 44.2 milhões de OP através de hot wallets da Binance na Optimism. 18,270 BTC de uma hot wallet da Binance. O incidente envolveu várias redes e diferentes ativos, e o impacto total foi estimado em aproximadamente 6,34 mil milhões de dólares. A Binance recebeu um alerta interno sobre transferências de grande volume e iniciou imediatamente uma investigação. Mas os atacantes ainda tinham outro truque.
A exploração técnica: como o EIP-7702 foi abusado. Um dos elementos técnicos mais importantes deste incidente envolveu o mecanismo de autorização EIP-7702 da Ethereum. Para quem não conhece, o EIP-7702 é uma melhoria da Ethereum que permite que uma conta controlada externamente delegue temporariamente certas capacidades de execução a código de contrato inteligente. Não exige que a chave privada da conta seja exposta. Neste incidente, os atacantes abusaram do serviço de assinatura para criar delegações EIP-7702 maliciosas, dando a um contrato inteligente que controlavam direitos de execução parciais sobre uma hot wallet da Binance. Submeteram 50 transações de assinatura para manipular o nonce da conta e estabelecer estas autorizações maliciosas. Isto criou um problema de contenção particularmente difícil. Porquê? Porque parar o sistema normal de levantamentos não era suficiente. As autorizações maliciosas já existiam na blockchain e podiam operar independentemente da infraestrutura habitual de levantamentos da Binance. A Binance podia suspender os levantamentos, encerrar os serviços de hot wallet e restringir o processamento normal de transações, mas essas ações não invalidariam automaticamente autorizações já estabelecidas na blockchain. Havia ainda outra complicação: a hot wallet afetada utilizava computação multipartidária, ou MPC. A MPC distribui o processo de assinatura por várias partes, em vez de depender de uma única chave privada. Este é um modelo de segurança importante, mas também significava que a Binance não podia simplesmente usar uma única chave privada para revogar imediatamente as autorizações maliciosas. A equipa de engenharia teve de desenvolver e executar um procedimento especializado para remover essas permissões através de transações adicionais na blockchain. Isto explica por que razão o incidente não foi contido simplesmente carregando num botão ou suspendendo temporariamente os levantamentos. Foi necessária uma resposta técnica coordenada.
A última transferência não autorizada: 23:56 UTC. De acordo com o relatório da Binance, a última transferência não autorizada, no valor de 2,961.9 ETH, foi finalizada na blockchain às 23:56 UTC de 29 de outubro. A transação tinha sido transmitida mais cedo e permaneceu pendente antes de ser confirmada. A Binance informou que não houve mais transferências não autorizadas depois dessa transação.
Às 00:10 UTC de 30 de outubro, a Binance executou uma nova autorização da hot wallet Binance14 para o endereço zero, eliminando o código de delegação malicioso EIP-7702. A movimentação não autorizada imediata dos fundos tinha sido travada. No entanto, parar o ataque foi apenas o início. O desafio seguinte foi, sem dúvida, igualmente importante: proteger os utilizadores, repor os ativos afetados, reabrir os levantamentos e demonstrar que a empresa podia absorver o impacto financeiro.
A primeira decisão que importou: os utilizadores não pagariam por isto. É aqui que considero que a resposta merece especial atenção. A Binance comprometeu-se publicamente a absorver o impacto financeiro dos fundos roubados, em vez de transferir essas perdas para os seus utilizadores.
Deixem-me repetir.
A empresa não anunciou que os clientes teriam de aceitar uma redução dos seus saldos. Não anunciou que os utilizadores seriam responsáveis por cobrir os ativos roubados. Comprometeu-se a cobrir o incidente com os seus próprios recursos.
A 30 de outubro, a Binance explicou que já tinha reservado mais de 6,34 mil milhões$. Aproximadamente 5 mil milhões $ estavam nos próprios tokens afetados, tendo a empresa adquirido os ativos restantes através de compras no mercado e de canais de balcão.
A cobertura envolveu duas fontes principais:
1. SAFU: Secure Asset Fund for Users. O SAFU é a reserva de proteção de emergência da Binance, criada para ajudar a proteger os utilizadores em circunstâncias extremas. Não é uma conta de trading normal nem uma carteira pessoal pertencente a um executivo. É um fundo dedicado à proteção dos utilizadores.
2. Recursos empresariais da Binance. A Binance também comprometeu os seus próprios recursos e fundos de tesouraria para cobrir o incidente.
Esta distinção é importante porque a responsabilidade foi assumida ao nível da empresa. Não houve qualquer anúncio oficial de que a recuperação tenha sido financiada através da conta pessoal de Richard Teng, da conta pessoal de CZ ou do património privado de outro executivo. As fontes de financiamento comunicadas foram o SAFU e os recursos empresariais da Binance.
Enquanto utilizador, esta foi uma das partes mais importantes de toda a história para mim. O ataque foi grave, mas a empresa estava a assumir a responsabilidade pelas consequências financeiras, em vez de as transferir para as pessoas que confiaram os seus ativos à plataforma.
A operação de recuperação: milhares de milhões, parceiros de blockchain e uma corrida contra o tempo. Enquanto se organizava a cobertura financeira, a Binance também trabalhava para recuperar e repor os ativos afetados. A primeira prioridade era rastrear os fundos roubados e impedir que o maior montante possível continuasse a ser movimentado. A Binance coordenou-se com autoridades policiais, empresas de inteligência de blockchain, emissores de tokens e parceiros do setor. No momento da publicação do seu relatório de investigação, a 3 de novembro, a Binance afirmou que tinham sido congelados ou intercetados ativos no valor de aproximadamente 2,85 mil milhões$. Este valor estava sujeito a reconciliação e à volatilidade dos preços de mercado. Congelar fundos e repor fundos são dois processos diferentes. Os ativos congelados são fundos que foram impedidos de se movimentar ou de chegar ao destino pretendido através da coordenação com as redes e os parceiros relevantes. A reposição, por outro lado, significa que a Binance adquire ativos substitutos para restaurar os saldos dos tokens afetados. A Binance recorreu a compras no mercado e a canais OTC para adquirir os ativos necessários, incluindo tokens com menor liquidez e, por isso, mais difíceis de obter em grandes quantidades. E foi aqui que os números da recuperação começaram a avançar rapidamente.
30 de outubro: mais de 6,34 mil milhões$ reservados. A Binance confirmou que tinha alocado mais de 6,34 mil milhões $ em recursos da empresa para cobrir o incidente, tendo aproximadamente 5 mil milhões $ já nos ativos dos tokens afetados. A empresa também trabalhou com parceiros do setor para congelar ativos e conter o incidente.
31 de outubro: aproximadamente 90% repostos. A Atualização de Recuperação n.º 3 da Binance informou que aproximadamente 90% dos ativos roubados tinham sido repostos. A empresa também disponibilizou uma captura do Proof of Reserves como parte dos seus esforços de transparência.
1–2 de novembro: os levantamentos começam a ser reabertos. Depois de proteger a infraestrutura afetada e concluir as verificações necessárias, a Binance começou a reabrir os levantamentos por fases. Não se tratava de simplesmente voltar a ligar tudo de uma só vez. Diferentes ativos e redes precisavam de verificações individuais de segurança e prontidão. A 2 de novembro, a Binance confirmou também que a captura do Proof of Reserves de 31 de outubro já podia ser totalmente verificada através da sua prova de conhecimento zero. Isto deu aos utilizadores outra forma de verificar de modo independente a cobertura dos seus saldos abrangidos.
3 de novembro: a investigação torna-se pública. A Binance publicou as suas conclusões iniciais detalhadas, explicando como os atacantes entraram no ambiente, comprometeram dispositivos de funcionários, exploraram o acesso interno e abusaram do EIP-7702. Divulgou também as melhorias de segurança já implementadas. Estas incluíram: reconstruir o sistema de carteiras afetado num novo ambiente; reconstruir a ferramenta interna de IA afetada e os respetivos controlos de acesso; substituir os dispositivos afetados; desativar credenciais e tokens associados aos engenheiros afetados; realizar análises de segurança reforçadas nos dispositivos dos funcionários; reforçar os controlos de risco dos serviços de carteiras; expandir a deteção de anomalias comportamentais baseada em IA.
A Binance anunciou também que estava a contratar especialistas independentes em cibersegurança para rever o incidente e validar as suas conclusões. A empresa afirmou que as informações mais recentes do FBI atribuíam o ataque à República Popular Democrática da Coreia (Coreia do Norte).
4 de novembro: 98% repostos. O marco mais recente da recuperação disponível no momento da redação foi publicado a 4 de novembro. A Binance informou que aproximadamente 98% dos ativos afetados tinham sido repostos. Os 2% restantes envolviam tokens com menor liquidez, e a Binance afirmou que continuava a comprá-los através de canais de mercado e OTC. A empresa também publicou uma nova captura do Proof of Reserves, datada de 4 de novembro, expandindo a cobertura de 10 para 44 tokens. Previa-se que a geração da prova de conhecimento zero completa demorasse aproximadamente 50–60 horas. Este é um pormenor importante: a Binance já tinha reservado mais de 100% da cobertura financeira necessária, mas a reposição efetiva dos ativos dos tokens afetados ainda estava nos 98%. Prefiro explicar isso com rigor a afirmar que todos os tokens já tinham sido repostos.
5 de novembro: reabrem mais levantamentos. A recuperação prosseguiu. Na Atualização de Recuperação n.º 8, publicada a 5 de novembro, a Binance anunciou que os levantamentos de ativos adicionais começariam a ser reabertos a partir das 04:00 UTC. A reabertura estava a ser implementada progressivamente, com cada ativo e rede a passar por verificações de segurança e prontidão.
E é esta a situação no momento em que escrevo esta história. O ataque foi contido, a empresa cobriu financeiramente um montante superior às perdas estimadas, aproximadamente 98% dos ativos dos tokens afetados foram repostos e os serviços de levantamento continuavam a ser restabelecidos por fases.
A Binance cobriu mesmo as perdas? De onde veio o dinheiro? Acho que este tema merece uma secção própria, porque provavelmente será uma das primeiras perguntas que as pessoas vão fazer. Onde é que uma empresa arranja 6,34 mil milhões $? A resposta não é que um CEO abriu uma conta bancária pessoal e transferiu milhares de milhões de dólares. A Binance afirmou que o impacto financeiro seria coberto pelo SAFU e por outros recursos da empresa. O SAFU existe especificamente como mecanismo de proteção de emergência para os utilizadores, enquanto os recursos de tesouraria da empresa proporcionam capacidade financeira adicional. A Binance afirmou que já tinha reservado mais de 100% do montante necessário. Na prática, isto significa que a empresa comprometeu os recursos financeiros necessários para garantir que os saldos dos utilizadores afetados poderiam ser cobertos sem pedir aos clientes que suportassem as perdas. O co-CEO Richard Teng também falou publicamente sobre a situação financeira da empresa na Hong Kong FinTech Week, a 3 de novembro. Descreveu a Binance como estando numa situação financeira muito sólida e afirmou que a empresa tinha capacidade para cobrir o incidente. Confirmou também que o SAFU e outros fundos da empresa estavam a ser usados para cobrir as perdas. É esta distinção que quero que os leitores compreendam: tratou-se de uma responsabilidade financeira da empresa, não de um donativo pessoal de um executivo.
A parte que mais importa para mim: nunca senti necessidade de fugir. Agora, deixem-me voltar à minha própria experiência. Entrei na Binance em 2019. A minha jornada começou com 20$. Nada de extraordinário. Nenhuma carteira de investimentos enorme, nenhuma conta de trading institucional, nenhuma estratégia de investimento complicada. Apenas uma prenda de aniversário do meu primo que me apresentou a um mundo financeiro completamente novo. Ao longo dos anos, aprendi, fiz trading, cometi erros, explorei diferentes produtos e acompanhei a evolução do setor. Acabei por criar uma relação com a Binance que foi além da simples utilização de uma corretora. Tornei-me Binance Angel. Comecei a participar em atividades da comunidade, debates educativos, AMAs, criação de conteúdos e iniciativas em toda a região MENA. Participei na Binance Blockchain Week no Dubai em 2025, juntei-me à comunidade Angels e tive a oportunidade de contribuir para o ecossistema de diferentes formas. Isso torna este incidente pessoal num sentido diferente. Quando uma empresa que apoiamos há anos passa por uma crise desta dimensão, é natural que prestemos atenção. Queremos respostas. Queremos transparência. Queremos saber se a empresa pode cumprir o que prometeu. E eu acompanhei. Segui os anúncios, li as explicações técnicas, acompanhei as atualizações sobre a recuperação e observei o que a empresa estava realmente a fazer. Não me interessava uma lealdade cega. Queria provas. E o que vi foi uma empresa que reconheceu o incidente, investigou os pontos de entrada, explicou o mecanismo técnico, disponibilizou os seus próprios recursos, trabalhou com parceiros do setor, repôs os ativos afetados e restabeleceu gradualmente os serviços. O ataque poderia ter sido evitado? Essa é precisamente a questão que a Binance tem de continuar a investigar. A resposta poderia ser melhorada? Sem dúvida. A própria Binance reconheceu que o seu processo de resposta a incidentes e os controlos das carteiras precisam de ser reforçados. Mas um incidente de segurança não deve ser avaliado apenas pela dimensão dos danos que causa. Deve também ser avaliado pela forma como a organização reage, pela sua transparência, pela maneira como protege os clientes e por assumir ou não a responsabilidade pelas consequências. Para mim, a resposta foi importante. Não me esqueci subitamente dos motivos que me levaram a começar a usar a Binance em 2019. Não deixei de acreditar na plataforma porque um dos ataques mais sofisticados da sua história teve êxito. Acredito que a confiança se constrói ao longo do tempo, mas também é posta à prova nos momentos difíceis. E esta foi uma prova séria.
Da recuperação ao agradecimento: a campanha comunitária da Binance. Aconteceu mais uma coisa enquanto a Binance trabalhava na recuperação. A 2 de novembro, a Binance lançou a sua Campanha de Agradecimento à Comunidade, que decorre até 21 de novembro de 2026. Achei isto particularmente interessante porque a campanha não era simplesmente uma promoção de trading genérica. Foi apresentada como uma forma de agradecer à comunidade pela sua confiança e apoio contínuos. A campanha inclui duas atividades principais:
1. Um voucher de reembolso de 100 USDC das comissões de trading Spot: Os utilizadores elegíveis com identidade verificada podem receber um voucher de reembolso de 100 USDC das comissões de trading Spot através do Rewards Hub. Há uma distinção importante: trata-se de um voucher de reembolso de comissões de trading, não de uma oferta em dinheiro de 100 USDC sem restrições. O reembolso é distribuído de acordo com as regras da campanha. O voucher proporciona um reembolso diário de 30% das comissões de trading Spot elegíveis restantes, após a dedução das comissões de referência, sendo os reembolsos creditados em USDC na Conta Spot. Os utilizadores têm de resgatar o voucher através de Perfil > Rewards Hub, e é importante ter em conta os períodos aplicáveis para o resgate e a validade.
A campanha inclui ainda um fundo de prémios de 20.000.000 USDC. Os utilizadores que negoceiem pares de trading Spot, Margin, Convert, USDⓈ-M Futures, COIN-M Futures, bStocks e Stock elegíveis e atinjam pelo menos 10,000$ equivalentes em volume de trading efetivo acumulado durante o período da campanha podem qualificar-se para receber uma parte do fundo. A recompensa individual é calculada de acordo com a parte do volume total de trading efetivo que cabe a cada utilizador elegível, com uma recompensa máxima de 4,000 USDC em vouchers de tokens por utilizador elegível nesta atividade.
2. Até 10% de TAE através de produtos Earn elegíveis: A segunda atividade oferece aos utilizadores elegíveis a oportunidade de obter até 10% de TAE através de produtos selecionados. Estes incluem: USDC Simple Earn Flexible, USDT Simple Earn Flexible, RWUSD e BFUSD. A TAE exata depende do produto, da elegibilidade do utilizador, do montante detido, do nível VIP, quando aplicável, e do escalão de bónus correspondente. Por exemplo, os utilizadores não VIP elegíveis que detenham menos de 50.000 USD equivalentes em USDC podem receber uma TAE de bónus de 7% no escalão aplicável, além da TAE base em tempo real. Para o USDT Flexible, a campanha oferece uma TAE de bónus de 8% no escalão elegível, além da TAE base em tempo real. O RWUSD e o BFUSD também têm as suas próprias estruturas de bónus. É importante compreender que até 10% de TAE não significa que todos os utilizadores recebam um retorno fixo garantido de 10% sobre cada dólar detido. As taxas são específicas de cada produto, variam por escalão e estão sujeitas a alterações.
A campanha decorre de 2 de novembro, às 11:30 UTC, até 21 de novembro, às 23:59 UTC, sujeita a elegibilidade e disponibilidade regional.
Para mim, esta é mais uma parte da história que vale a pena mencionar. A Binance continuava a restabelecer os serviços e a reforçar a sua segurança, ao mesmo tempo que reconhecia a comunidade que se manteve ao seu lado durante todo este período difícil. Naturalmente, uma campanha promocional não substitui a segurança, a transparência ou a responsabilização. Estes elementos têm de se sustentar por si próprios. Ainda assim, tendo em conta tudo o que aconteceu, continua a ser uma iniciativa comunitária significativa.
O que este incidente me ensinou sobre confiança. Se há uma coisa que quero que as pessoas retirem desta experiência, é que confiar nunca deve significar ignorar os factos. Sou Binance Angel, mas isso não significa que deva evitar fazer perguntas. Sou utilizador há muito tempo, mas isso não significa que deva fingir que um incidente de segurança não é nada. E acredito na plataforma, mas continuo a esperar transparência, responsabilização e melhoria contínua. O incidente expôs vulnerabilidades que precisavam de ser resolvidas. Também demonstrou porque é que a segurança nunca é um projeto concluído. A tecnologia evolui, os atacantes tornam-se mais sofisticados e até as organizações estabelecidas têm de desafiar continuamente os seus próprios sistemas. Para a Binance, o trabalho não termina com a reposição dos ativos. A empresa tem de continuar a melhorar os seus controlos internos, as revisões de segurança independentes, a infraestrutura das carteiras, a segurança dos dispositivos dos funcionários e os procedimentos de resposta a incidentes. Para os utilizadores, a lição é igualmente importante: protejam bem as contas, ativem as proteções disponíveis, mantenham-se atentos à engenharia social e nunca descarreguem ficheiros suspeitos nem partilhem credenciais sensíveis. E, para o setor, este é mais um lembrete de que a segurança não se resume a proteger chaves privadas. Diz respeito às pessoas, aos dispositivos, às cadeias de fornecimento de software, às permissões internas, aos procedimentos operacionais e à capacidade de reagir quando algo corre mal.
Oito anos depois, continuo aqui. Quando olho para trás, para a minha jornada desde 2019, lembro-me de começar com 20$, de aprender o que eram as criptomoedas, de fazer as minhas primeiras transações, de descobrir novos produtos e, por fim, de me tornar parte de uma comunidade global. Nunca imaginei que um dia estaria a escrever sobre um incidente de segurança de 6,34 mil milhões$ envolvendo a plataforma que me apresentou a este setor. Mas aqui estamos. E se há uma coisa que posso dizer depois de acompanhar toda esta situação, é que valorizo a diferença entre uma empresa que simplesmente promete proteger os seus utilizadores e uma empresa que assume a responsabilidade financeira quando algo corre muito mal. A Binance ainda tem muito trabalho pela frente. Os ativos restantes ainda têm de ser repostos, os serviços de levantamento têm de continuar a ser restabelecidos em segurança e as revisões de segurança independentes têm de produzir melhorias significativas. Mas não perdi a confiança na plataforma. Comecei esta jornada em 2019 com 20$. Continuo aqui em 2026, não porque acredite que alguma empresa é imune a ataques, mas porque acredito que a responsabilização se demonstra através de ações, não de slogans. O incidente de 6,34 mil milhões $ foi um capítulo doloroso na história da Binance. Nunca deve ser minimizado, e as lições nunca devem ser esquecidas. Mas também se tornou um teste à responsabilidade financeira, à resiliência operacional e à relação entre uma plataforma e os seus utilizadores. E, pessoalmente, não vou embora por causa de uma manchete. Estou aqui desde 2019. Vi o ecossistema crescer, fiz parte da sua comunidade e acompanhei a Binance a enfrentar um dos seus maiores desafios até à data. A minha confiança continua intacta. Mas, mais importante, continuarei a exigir a transparência e a responsabilização que essa confiança merece. Porque manter-se SAFU não significa acreditar que nunca pode correr nada mal. Significa saber o que acontece quando corre.
Sempre acreditei na Binance, mas esta experiência reforçou ainda mais essa crença. Acredito na minha equipa, nesta comunidade incrível e em todos os utilizadores que estão do nosso lado. Vocês são a minha segunda família. Estamos juntos, apoiamo-nos mutuamente e contamos uns com os outros. O meu sincero agradecimento a @CZ , a toda a equipa de segurança da Binance, aos programadores, engenheiros e a todos os que trabalharam incansavelmente nos bastidores para proteger os nossos fundos. Estarei para sempre grato, primeiro como utilizador desde 2019 e agora como Binance Angel.@Binance MENA @Binance Angels Talvez isto seja mais pessoal do que as pessoas imaginam. O meu país, o Líbano, passou por um colapso financeiro que fez desaparecer as poupanças de uma vida inteira e deixou muitos de nós com pouco ou nada a que recorrer. Sei o que é ver anos de trabalho árduo desaparecerem e questionar se o nosso dinheiro está realmente seguro. A Binance proporcionou-me uma experiência diferente e, quando surgiu outro grande desafio, voltou a apoiar os seus utilizadores. Circunstâncias diferentes, proteções diferentes, mas uma coisa permaneceu igual: não tive de enfrentar a perda sozinho.
Binance, obrigado por estarem ao nosso lado. Obrigado por protegerem aquilo por que tanto trabalhámos e por me darem mais um motivo para acreditar. Serei eternamente grato.🙏🏼