Ataques de IA Desligam Boltz: Lições para a Segurança em Cripto

Dois fatos do início de agosto pertencem lado a lado em cada documento de design de liquidação escrito a partir de agora.

No dia 3 de agosto, Boltz - o serviço de troca que conecta a mainchain do Bitcoin, Lightning, e a sidechain Liquid - suspendeu todos os seus serviços de troca indefinidamente. A razão não foi um único hack catastrófico. Foi um padrão: meses de ataques automatizados, assistidos por IA, sondando sua infraestrutura mais rápido do que a equipe conseguia responder. O próprio resumo deles é a frase mais importante escrita sobre segurança cripto este ano:

"Cada um foi contido, mas o padrão é claro: os atacantes agora iteram mais rápido do que uma equipe do nosso tamanho consegue encontrar e corrigir."

O segundo fato: fundos dos usuários perdidos, zero.

Leia isso junto. Uma equipe competente analisou a cadência dos ataques impulsionados por máquinas, concluiu que a defesa em velocidade humana se tornara uma corrida perdida e desligou. E eles puderam se desligar de forma limpa, porque sua arquitetura significava que o dinheiro de ninguém estava sentado em seus servidores em primeiro lugar. Dentro de dias, carteiras que dependiam do Boltz - Aqua, Bull Bitcoin, Zeus - perderam a funcionalidade de troca. Uma semana depois, em 10 de agosto, a Blockstream anunciou sua própria versão beta de Swaps para preencher a lacuna. Construído na mesma primitiva: trocas atômicas baseadas em HTLC, auto-custodiais.

O serviço morreu. A camada de script não piscou.

Por que o número era zero

As trocas submarinas do Boltz foram construídas sobre contratos com hash-time-locked. O mecanismo cabe em algumas linhas de script do Bitcoin:

OP_IF
    OP_SHA256 <payment_hash> OP_EQUALVERIFY
    <claim_pubkey> OP_CHECKSIG
OP_ELSE
    <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <refund_pubkey> OP_CHECKSIG
OP_ENDIF

Duas ramificações. A ramificação IF liquida: revela a pré-imagem do hash, prova sua chave, pega os fundos. A ramificação ELSE reembolsa: após o tempo limite, o proprietário original recupera com sua própria chave. Não há terceira ramificação para um operador, um oráculo ou um administrador de emergência - o que significa que, como escrevemos em o artigo de ontem sobre cofres de colateral BTC, não há terceira ramificação para atacar, intimar ou injetar por prompt.

Os servidores do Boltz coordenavam as trocas. Eles nunca as mantiveram. Portanto, quando a camada de coordenação ficou escura, cada troca em andamento foi resolvida pela lógica da ramificação: completada com a pré-imagem ou reembolsada no tempo limite. O pior cenário foi projetado para ser um reembolso antes que o primeiro atacante aparecesse. É por isso que os atacantes, por mais rápido que iterassem, saíram com nada.

A lição errada: muros maiores

Uma leitura inicial do desligamento é que os ataques em velocidade de IA empurrarão as criptos de volta para os grandes custodianos - apenas grandes equipes de segurança podem sobreviver a isso, então os usuários recuarão para os maiores nomes.

A lógica é compreensível e, pensamos, invertida. Um custodiante também é um serviço. É a mesma corrida de correção, conduzida por uma equipe maior, com uma diferença que importa: tudo está concentrado atrás do muro. Um orçamento de defesa maior compra tempo na corrida; não muda o modo de falha, e o prêmio cresce mais rápido do que o muro. Se o ataque agora se acumula em velocidade de máquina, o movimento vencedor não é contratar defensores mais rápido do que o adversário itera. É diminuir o que um atacante bem-sucedido obtém - idealmente para zero.

O zero do Boltz não foi um resultado da vitória de sua equipe de segurança. Foi um resultado de sua arquitetura tornando a luta quase sem sentido. Essa é a parte que vale a pena copiar.

O que isso significa para a liquidação de agentes

Aqui está o momento desconfortável: agentes atacantes apareceram em grande escala antes que agentes comerciantes o fizessem. Enquanto a economia de agentes debate trilhos de pagamento e padrões de intenção, os primeiros adversários autônomos de grau de produção já estão aposentando infraestrutura.

Cada peça da infraestrutura de comércio de agentes é um serviço em funcionamento. Facilitadores de pagamento, livros de RFQ, redes de solucionadores, conjuntos de validadores de ponte - cada um é uma equipe em algum lugar correndo a mesma corrida que o Boltz descreveu, contra a mesma classe de adversário. Portanto, a questão de design para qualquer coisa que liquida valor entre agentes não é mais "o serviço é seguro?" É: o que um atacante obtém ao comprometer totalmente o serviço?

Construímos o Hashlock e operamos um coordenador - um gateway que lida com RFQs de lances selados entre contrapartes. Portanto, a versão honesta deste argumento deve nos incluir. Se um atacante possuísse nosso serviço completamente, aqui está o envelope de danos total:

• Eles não poderiam mover fundos bloqueados. O script on-chain impõe que apenas o detentor da pré-imagem reivindique, e apenas o depositante original reembolse após o tempo limite. O coordenador não ocupa nenhum dos papéis.
• Eles poderiam se recusar a relatar cotações, censurar contrapartes ou derrubar o serviço completamente.
• A consequência de tudo isso é a mesma: as negociações não começam, e cada perna aberta reembolsa por tempo limite. Degradação, não perda.

Esse é o mesmo envelope que o Boltz acabou de demonstrar sob fogo ao vivo, e é toda a razão pela qual ancoramos a liquidação em script em vez de em nossa própria disponibilidade. A perna de liquidação roda ao vivo de ponta a ponta na mainnet do Ethereum hoje. O caminho HTLC do Bitcoin é validado na signet, com a mainnet pendente. Os contratos Sui estão implantados e testados em CLI, com a fiação do gateway em andamento - ainda não ao vivo, e não chamaremos de ao vivo até que esteja.

Os contratos em si enfrentam os mesmos adversários em velocidade de IA, razão pela qual "a garantia vive no script" não pode ser um slogan sem uma história de verificação por trás dele: análise estática Slither, execução simbólica Halmos, fuzzing de propriedades Echidna, testes de mutação Stryker e um monitor de invariantes em tempo de execução, com contratos da V1 na mainnet imutáveis e a V2 condicionada à aprovação de auditoria externa. Nada disso torna os contratos invulneráveis. Isso torna a afirmação precisa: o pior cenário é limitado a um reembolso por construção, não pela rapidez com que nossa equipe pode corrigir.

Para os agentes, isso também é uma propriedade de interface. Nosso servidor MCP (@hashlock-tech/mcp, v0.6.0, seis ferramentas) permite que um agente leia os termos de liquidação contra os quais está prestes a bloquear fundos. A contraparte em quem seu agente confia não é nossa empresa ou nossa disponibilidade - é um script que o agente pode verificar antes que um único satoshi ou wei se mova.

A pergunta a fazer sobre sua pilha

O desligamento do Boltz custou aos seus usuários inconveniência: trocas indisponíveis, carteiras correndo atrás de alternativas, Blockstream intervindo. Irritante, recuperável. Para um serviço que mantém custódia, o mesmo evento custa aos usuários tudo, e o pós-morte é lido de forma muito diferente.

Portanto, a pergunta que vale a pena fazer sobre qualquer infraestrutura de liquidação - a nossa incluída - não é se será atacada. Após o início de agosto, assuma adversários em velocidade de máquina por padrão. A pergunta é: se o serviço for totalmente comprometido amanhã, qual é a pior coisa que acontece com os fundos dos usuários?

Se a resposta for qualquer coisa diferente de "um reembolso", o modelo de ameaça precisa ser atualizado. Os atacantes já atualizaram os deles.

Hashlock é uma camada de liquidação atômica para a economia de agentes: RFQ de lances selados mais liquidação HTLC, sem pontes, sem custodianos. Docs: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-08-25-ai-adversa