Exploit de US$ 820 mil no Hinkal: como uma brecha no ZK Proof esvaziou um protocolo de privacidade

Como o ataque funcionou

O Hinkal usa zkSNARKs para permitir que usuários depositem, troquem e retirem ativos de forma privada. Os depósitos são registrados em uma árvore Merkle on-chain, e as retiradas exigem uma prova de conhecimento zero válida . O endereço do invasor (0xbB3...fc20) realizou um "Depósito Sem Prova" (Proofless Deposit) — um depósito sem uma prova ZK válida — e então executou múltiplas ações de "Transact" para retirar aproximadamente US$ 820 mil em USDC do contrato do Hinkal . Isso indica uma falha na lógica de verificação da prova ZK no contrato inteligente: o contrato aceitou instruções de depósito e saque sem validar corretamente a prova criptográfica, efetivamente permitindo que o invasor forjasse solicitações de retirada .

Pesquisas anteriores já haviam identificado riscos relacionados. Uma auditoria da zkSecurity nos circuitos do Hinkal apontou possíveis problemas com gasto duplo (double-spending) através de falhas no nullifier e validação inadequada de chaves privadas . A auditoria da Quantstamp sinalizou preocupações informacionais sobre nós folha vazios mapeando para compromissos não nulos, embora o protocolo tenha reconhecido o problema antes do ataque . Essas descobertas, combinadas com o exploit ao vivo, destacam a distância entre achados teóricos de auditoria e vulnerabilidades exploráveis on-chain.

Lavagem dos fundos

Após o ataque, o invasor converteu o USDC roubado em Ether e moveu os fundos através do Tornado Cash e da THORChain para obscurecer o rastro . Dados on-chain mostram que 410 ETH (~US$ 700 mil) foram depositados no Tornado Cash, e outros 44,7 ETH foram transferidos (bridge) da Ethereum para um endereço Bitcoin através da THORChain .

Empresas de segurança que confirmaram o incidente

• CertiK sinalizou o ataque primeiro através de seu sistema de alerta on-chain, reportando as transações suspeitas e uma perda estimada em US$ 800 mil .
• PeckShieldAlert confirmou o exploit e o valor estimado de US$ 820 mil .
• O pesquisador de segurança independente Specter também sinalizou o incidente publicamente, e veículos de notícias relataram amplamente a violação .

Até o momento da publicação, o Hinkal não havia divulgado um post-mortem confirmado, uma análise detalhada das transações do ataque ou uma explicação da causa raiz .

Contexto mais amplo de segurança em DeFi em 2026

O ataque ao Hinkal é um incidente em uma onda mais ampla de hacks em criptomoedas em 2026. De acordo com a TRM Labs, o primeiro semestre de 2026 foi o período de seis meses com mais hacks já registrado em número de incidentes: 207 ataques distintos no setor cripto, embora as perdas totais de US$ 972 milhões tenham sido menos da metade dos US$ 2,3 bilhões roubados no primeiro semestre de 2025 . O número absoluto de ataques disparou .

Somente grupos de hackers ligados à Coreia do Norte roubaram US$ 643 milhões no primeiro semestre de 2026, representando cerca de dois terços de todo o roubo de criptomoedas no mundo . O segundo trimestre de 2026 (cerca de US$ 746 milhões roubados em aproximadamente 70 ataques) estabeleceu o recorde de trimestre com mais hacks na história do DeFi em volume de incidentes . O valor total bloqueado (TVL) do DeFi caiu de cerca de US$ 115 bilhões em janeiro de 2026 para aproximadamente US$ 70 bilhões no final de junho, impulsionado em parte pela onda implacável de hacks .

O que isso significa para protocolos baseados em ZK

O ataque ao Hinkal é um exemplo clássico de um bug na lógica de verificação ZK — um tipo de vulnerabilidade que se torna cada vez mais cara à medida que mais protocolos adotam provas de conhecimento zero para privacidade e escalabilidade . Diferente de bugs tradicionais em contratos inteligentes, falhas em circuitos ZK quebram a premissa fundamental de segurança de que provas matemáticas são infalsificáveis . Quando um circuito verificador é mal configurado, ele não cria apenas um exploit — ele cria uma maneira matematicamente válida de mentir para o protocolo . Para desenvolvedores, a lição é que a lógica de verificação ZK requer auditoria especializada, além das revisões padrão de contratos inteligentes, e que mesmo protocolos com múltiplas auditorias prévias podem abrigar falhas críticas de bypass .