Exchanges Cripto Falham em Velocidade, Não em Criptografia

Vinte minutos. Foi o tempo que, segundo os relatos, os atacantes levaram para tirar US$ 6,3 bilhões da Binance, menos do que a maioria das equipes de resposta a incidentes leva para se reunir numa chamada de vídeo. Se você tirar só uma lição disso, que seja esta: a segurança de exchanges cripto não falha na matemática. As assinaturas provavelmente eram válidas. As chaves fizeram exatamente o que chaves fazem. A falha está na velocidade, no fato de que uma exchange moderna consegue converter uma única credencial comprometida em bilhões de dólares em liquidações irreversíveis mais rápido do que qualquer humano consegue dizer “espera”.

Os primeiros relatos apontam para um dispositivo de funcionário comprometido como ponto de entrada, e a exchange prometeu cobrir as perdas e cooperar com as autoridades. Nada disso deveria tranquilizar você. Um único notebook entre um atacante e US$ 6,3 bilhões não é uma arquitetura de segurança; é uma anedota esperando para acontecer. Passamos uma década reforçando a camada errada dessa pilha, e esse assalto é a conta chegando.

Vinte Minutos São uma Falha de Design, Não um Dia Ruim

A parte sensacionalista da história, vinte minutos!, é justamente a menos surpreendente. Todo grande roubo em exchanges segue o mesmo padrão: meses ou anos de preparação silenciosa, seguidos de uma janela de execução medida em minutos. O roubo ao Bangladesh Bank, em 2016, funcionou do mesmo jeito. Os atacantes passaram meses dentro da rede do banco e depois dispararam mensagens SWIFT fraudulentas em uma única rajada. Queriam um bilhão de dólares e conseguiram US$ 81 milhões, e só porque um funcionário atento de um banco correspondente percebeu algo estranho e barrou o resto. A sorte interveio. Sorte não é controle.

O que torna as exchanges cripto especiais, e singularmente frágeis, é a combinação de três propriedades que quase nunca coexistem nas finanças tradicionais. A liquidação é final, então não existe botão de desfazer. A liquidação é rápida, então não existe janela de revisão. E a liquidação é ao portador, então quem tem a capacidade de assinar tem o dinheiro. Uma transferência bancária pode ser congelada com um telefonema para o banco correspondente. Um lote de transações assinadas na blockchain não pode ser desassinado. Quando um atacante chega ao caminho de assinatura de uma exchange, ele não está roubando dinheiro. Está teletransportando.

Então o número de vinte minutos não é o escândalo. O escândalo é que o design do sistema torna vinte minutos suficientes. Se a sua arquitetura permite que bilhões saiam do prédio em menos tempo que um almoço, o atacante não precisa ser rápido. Você construiu a velocidade para ele.

Por Que Criptografia Melhor Não Teria Salvo a Exchange

Sempre que um roubo de oito ou nove dígitos aparece nas notícias, a reação automática é que o gerenciamento de chaves deve ter sido descuidado: deveriam ter usado HSMs, computação multipartidária ou um quórum multisig maior. A indústria absorveu essa lição tão bem que a maioria das grandes exchanges agora de fato usa HSMs e MPC. E os roubos continuam, porque a premissa está errada. A criptografia responde a uma pergunta: esta requisição é autêntica? Ela não consegue responder à pergunta que realmente importa durante um assalto: esta requisição autêntica deveria acontecer?

Se o ponto de entrada é um notebook de funcionário comprometido, uma sessão com credenciais válidas, tokens MFA válidos e acesso válido à camada de orquestração de saques, então cada assinatura que o sistema produz é criptograficamente impecável. Um HSM não sabe que o humano que o opera está sendo controlado remotamente. O MPC não ajuda quando o atacante compromete endpoints de participantes suficientes, exatamente como funcionou o roubo de US$ 625 milhões da ponte Ronin: cinco de nove chaves de validadores, obtidas por meio de máquinas comprometidas, não matemática quebrada. Até o folclore de que o próprio Bitcoin é “hackeado” tende a desmoronar sob escrutínio, como descobrimos quando analisamos um exploit de Bitcoin em PHP muito falado e percebemos que a criptografia nunca foi o ponto fraco. O ponto fraco é sempre o momento em que um sistema confiável é usado conforme projetado por alguém que não deveria estar no comando.

A criptografia protege a chave. Nada na matemática protege o momento em que a chave é usada exatamente como foi projetada para ser usada.

Monitoramento Não Vence um Relógio de Vinte Minutos

O segundo reflexo é a detecção: monitoramento melhor, detecção de anomalias, uma IA observando as transferências. As exchanges de fato têm isso, e o alarme dispara. É assim que sabemos que o assalto levou vinte minutos. Mas detecção e prevenção são produtos diferentes, com orçamentos de latência diferentes. Num centro de operações de segurança maduro, o tempo entre um alerta de alta confiabilidade e um humano com autoridade para interromper saques é medido em dezenas de minutos num dia bom: acionar o plantonista, verificar se não é falso positivo, escalar para quem consegue puxar a alavanca grande, obter aprovação, puxar. Toda a operação do atacante cabe dentro desse ciclo, com tempo de sobra.

Esta é a assimetria que ninguém quer precificar. Os defensores são dimensionados para o horário comercial; os atacantes atacam em fins de semana e feriados justamente porque os tempos de resposta se degradam. E mesmo quando o alerta dispara instantaneamente, o alerta não é o botão de desligar, um humano é. Já vimos esse filme fora do mundo cripto: o roubo ao Bangladesh Bank foi interrompido por uma pessoa, não por um sistema, e essa pessoa quase não estava lá. Se a sua última linha de defesa é “torcer para que alguém esteja olhando o painel”, você não tem última linha de defesa. O mesmo raciocínio vale muito além das exchanges. Fizemos um argumento parecido sobre por que contenção vence monitoramento para agentes autônomos: observar sem a capacidade de intervir é apenas uma gravação da sua falha.

Cobrir as Perdas É uma Confissão, Não uma Correção

A Binance diz que vai cobrir todas as perdas e, para ser justo, a empresa já fez isso antes: depois do ataque de 2019, que levou 7.000 BTC, seu fundo de seguro SAFU deixou os usuários no zero a zero. O mercado mal reagiu na época e provavelmente não vai reagir agora. Mas sejamos honestos sobre o que “nós vamos cobrir” significa em termos de arquitetura: nada. Seguro é um mecanismo de balanço para absorver falhas, não um mecanismo de engenharia para preveni-las. Ele transforma uma catástrofe em uma linha de despesa, o que é racional para a exchange e irrelevante para o próximo atacante, que enfrenta exatamente a mesma janela de vinte minutos.

Há também um problema de escala que ninguém no setor quer dizer em voz alta. Uma perda de US$ 6,3 bilhões excede em muitas vezes toda a capacidade de seguro disponível para o setor cripto inteiro. Só um punhado de exchanges no planeta consegue se autossegurar contra uma perda dessas. Cada venue menor, e há centenas com fundos significativos de clientes, está implicitamente apostando que não será a próxima. É exatamente a lacuna que o seguro de depósitos e a regulação prudencial existem para preencher nos bancos, e por isso o instinto de perguntar “a Binance não deveria ser processada por negligência de segurança?”, por mais tosco que seja, aponta para algo real. Decidimos há um século que instituições que guardam dinheiro alheio não podem escolher o próprio apetite por risco. O mundo cripto passou quinze anos reabrindo essa decisão, um assalto de cada vez.

Disjuntores: A Solução que os Mercados Já Inventaram

Aqui está a parte frustrante: as finanças resolveram esse problema há décadas, só que em outra direção. Depois da quebra de 1987, as bolsas de valores adotaram disjuntores que suspendem as negociações quando os preços se movem rápido demais. Ninguém diz que as paralisações eliminam fraudes ou quedas; o objetivo é transformar um processo descontrolado em um processo supervisionado, ganhando tempo para o julgamento humano. A mesma lógica se aplica às saídas, e é quase constrangedoramente simples: nenhuma exchange deveria conseguir emitir mais que uma pequena fração de seus ativos em qualquer janela curta de tempo, não importa quão válidas sejam as assinaturas.

Um disjuntor de saques é um motor de políticas que fica no caminho de assinatura e trata a própria velocidade como anomalia. Crucialmente, ele não pergunta se a requisição é autêntica. Ele assume que cada requisição pode ser autêntica e maliciosa, e limita o raio de explosão de qualquer forma:

from dataclasses import dataclass
from datetime import datetime, timedelta
@dataclass
class WithdrawalPolicy:
window: timedelta = timedelta(minutes=30)
max_outflow_pct: float = 2.0      # of hot-wallet balance per window
hard_freeze_pct: float = 5.0      # trip the breaker entirely
large_threshold_usd: float = 1_000_000
large_delay: timedelta = timedelta(hours=24)
class CircuitBreaker:
def __init__(self, policy: WithdrawalPolicy):
self.policy = policy
self.recent: list[tuple[datetime, float]] = []
self.tripped = False
def authorize(self, amount_usd: float, hot_balance_usd: float) -> str:
if self.tripped:
return "REJECT: breaker tripped, manual review required"
now = datetime.utcnow()
cutoff = now - self.policy.window
self.recent = [(t, a) for t, a in self.recent if t > cutoff]
outflow_pct = 100 * (sum(a for _, a in self.recent) + amount_usd) / hot_balance_usd
if outflow_pct > self.policy.hard_freeze_pct:
self.tripped = True
return "HALT: outflow exceeded safety threshold, withdrawals frozen"
if outflow_pct > self.policy.max_outflow_pct:
return "QUEUE: velocity limit reached, withdrawal delayed"
if amount_usd > self.policy.large_threshold_usd:
return f"DELAY: held {self.policy.large_delay} for review"
self.recent.append((now, amount_usd))
return "APPROVE"

Veja o que isso garante com os números deste assalto. Se a hot wallet tiver apenas 10% dos US$ 6,3 bilhões, um congelamento rígido de 5% do saldo quente limita as perdas automáticas em cerca de US$ 31 milhões: um mau dia, não um evento existencial. Mais importante, a corrida de vinte minutos do atacante vira um rastejar de vários dias, o que finalmente dá à equipe de monitoramento a chance de atuar. O objetivo não é superar o atacante em esperteza; é esticar o tempo até que um humano chegue. Isso é engenharia defensiva no sentido clássico: projetar o sistema para que sua pior falha seja entediante.

Atrasos em Saques e o Caso Para uma Banca Entediante

Disjuntores lidam com velocidade; atrasos lidam com volume. O trunfo secreto do sistema financeiro tradicional não é sofisticação, é atrito. Transferências podem ser revertidas. Uma TED ou um DOC levam dias. Movimentações grandes disparam períodos de retenção e confirmações por telefone com contatos conhecidos, por canais separados. O mundo cripto eliminou tudo isso porque a liquidação instantânea e final era o produto. Mas você pode reintroduzir atrito seletivamente, na fronteira de saque, sem mexer na experiência de negociação que os usuários realmente valorizam:

• Saques grandes com bloqueio de tempo. Qualquer valor acima de um limite espera 24 horas numa fila visível. Os usuários se planejam em torno disso; os atacantes não conseguem. Cada hora de atraso é uma hora para a invasão ser descoberta.
• Limites rígidos para a hot wallet. Mantenha online apenas o necessário para 24 horas de saques normais, que, para a maioria das exchanges, fica em percentuais de um dígito baixo dos ativos. Movimentações em cold storage exigem cerimônias multipartidárias de vários dias que nenhuma credencial consegue acelerar.
• Lista de endereços permitidos com alterações atrasadas. Novos endereços de saque só são ativados após um atraso e uma confirmação fora de banda. Isso elimina o movimento clássico de trocar os endereços de destino durante a invasão.
• Autoridade de assinatura segmentada. Nenhum endpoint, papel ou sessão, por mais autenticado que seja, pode movimentar mais que um valor limitado. O ponto de entrada importa menos quando o raio de explosão é pequeno, uma lição que o incidente da cadeia de suprimentos do LiteLLM ensinou ao ecossistema Python sobre as máquinas de desenvolvedores serem o alvo mais fácil.
• Prova pública de reservas com passivos. Não é um controle contra roubo, mas um alarme de solvência que tira a opção de acobertamento da mesa logo no início.

Repare que nenhuma dessas medidas exige criptografia nova, hardware novo ou ciência nova. São políticas. Também são impopulares, porque cada uma delas é um pesadelo para qualquer gerente de produto: atrito, atrasos, limites. E porque a economia das exchanges recompensa throughput e tudo instantâneo. A tensão é real, e a resposta do setor até agora tem sido aceitar um risco de cauda catastrófico em troca de uma UX ágil. Um roubo de US$ 6,3 bilhões em vinte minutos é o que essa troca parece quando a conta chega.

Velocidade É uma Escolha, Então Escolha Deliberadamente

Existe um ditado em resposta a incidentes: quando segundos importam, corrigimos em dias ou semanas. Esse roubo inverte a lógica: quando segundos importam, o dinheiro se move em minutos, e todo o processo dos defensores foi construído para um mundo mais lento. Você não resolve isso com alertas mais inteligentes ou chaves mais fortes, porque o atacante não está quebrando as chaves nem se escondendo dos alertas. Ele está usando o seu sistema do jeito que foi projetado, na velocidade para a qual você o projetou.

Então, a pergunta honesta para cada engenheiro de exchange, e, sinceramente, para cada engenheiro que constrói sistemas que movem valor, não é “como mantemos os atacantes para sempre do lado de fora?”. Você não vai conseguir. Notebooks são comprometidos, pessoas são phisheadas, cadeias de suprimentos são envenenadas. A pergunta é: quando alguém entra, sua arquitetura falha rápido ou falha devagar? Hoje, a resposta do setor é rápida, final e transmitida ao vivo. Limites de velocidade, saques com bloqueio de tempo e limites rígidos na hot wallet são como você muda essa resposta. A tecnologia é trivial. A disposição de aceitar um pouco de atrito não é. E se o setor não escolher esse atrito por conta própria, os reguladores, vendo uma perda de US$ 6,3 bilhões acontecer entre um café e outro, vão acabar escolhendo por ele.