Às uma da madrugada, terminei de ler de uma vez o retrospecto do incidente da ponte Dusk e a análise AEGIS, e antes de fechar a página fiquei de repente um pouco apreensivo: há alguns dias eu também quase aceitei aquela escolha binária tão conveniente — “se não é uma vulnerabilidade L1, então não é nada” ou “a ponte deu problema, então toda a cadeia é insegura”.
A situação real é bem mais complicada do que um slogan. Em 16 de janeiro de 2026, o atacante obteve permissões da carteira de assinatura usada pelo serviço de ponte de Dusk para EVM.
O retrospecto oficial deixa claro que não foi uma falha de consenso, nem o protocolo base de Dusk foi comprometido; o que aconteceu foi a quebra da rota de assinatura da ponte. O design antigo colocava a carteira de assinatura, o processamento de eventos e a conexão de rede na mesma trilha operacional; uma vez perdida a chave, o alcance do atacante era grande demais.
O interessante é que o foco da correção não foi simplesmente “trocar uma chave”. O novo design separa recepção de eventos, persistência de tarefas, liberação de fundos e um assinador dedicado, usando uma máquina de estados como seen, submitted, completed, failed e stuck para gerir as transações; a hot wallet mantém apenas o saldo necessário para o curto prazo, e se faltar fundos a operação é pausada, com reposição manual a partir da cold wallet.
Em resumo, é como transformar um caminhão-forte carregado de dinheiro em compartimentos separados, limites de valor e liberação em camadas.
E o AEGIS é outra coisa: a auditoria interna promoveu ao todo 39 correções, das quais 7 foram classificadas como críticas, envolvendo isolamento de VM, desserialização, vínculo entre taxas e reembolso no Phoenix, falsificação de BLS e outras causas raiz. A divulgação oficial diz que, até o momento, não há evidências de que esses problemas críticos tenham sido explorados anteriormente. O incidente da ponte e o AEGIS não podem ser misturados como se fossem a mesma vulnerabilidade, e também não dá para dizer que o risco zerou só porque ambos foram corrigidos.
Então, minha avaliação agora é: não ser uma vulnerabilidade de consenso não significa que não seja um problema de segurança para o usuário; um retrospecto público merece reconhecimento, mas não substitui estabilidade de longo prazo nem validação de terceiros.
Quando vocês avaliam uma cadeia, incluem a ponte e a operação no escore de segurança do protocolo?
#dusk $DUSK @Dusk
A situação real é bem mais complicada do que um slogan. Em 16 de janeiro de 2026, o atacante obteve permissões da carteira de assinatura usada pelo serviço de ponte de Dusk para EVM.
O retrospecto oficial deixa claro que não foi uma falha de consenso, nem o protocolo base de Dusk foi comprometido; o que aconteceu foi a quebra da rota de assinatura da ponte. O design antigo colocava a carteira de assinatura, o processamento de eventos e a conexão de rede na mesma trilha operacional; uma vez perdida a chave, o alcance do atacante era grande demais.
O interessante é que o foco da correção não foi simplesmente “trocar uma chave”. O novo design separa recepção de eventos, persistência de tarefas, liberação de fundos e um assinador dedicado, usando uma máquina de estados como seen, submitted, completed, failed e stuck para gerir as transações; a hot wallet mantém apenas o saldo necessário para o curto prazo, e se faltar fundos a operação é pausada, com reposição manual a partir da cold wallet.
Em resumo, é como transformar um caminhão-forte carregado de dinheiro em compartimentos separados, limites de valor e liberação em camadas.
E o AEGIS é outra coisa: a auditoria interna promoveu ao todo 39 correções, das quais 7 foram classificadas como críticas, envolvendo isolamento de VM, desserialização, vínculo entre taxas e reembolso no Phoenix, falsificação de BLS e outras causas raiz. A divulgação oficial diz que, até o momento, não há evidências de que esses problemas críticos tenham sido explorados anteriormente. O incidente da ponte e o AEGIS não podem ser misturados como se fossem a mesma vulnerabilidade, e também não dá para dizer que o risco zerou só porque ambos foram corrigidos.
Então, minha avaliação agora é: não ser uma vulnerabilidade de consenso não significa que não seja um problema de segurança para o usuário; um retrospecto público merece reconhecimento, mas não substitui estabilidade de longo prazo nem validação de terceiros.
Quando vocês avaliam uma cadeia, incluem a ponte e a operação no escore de segurança do protocolo?
#dusk $DUSK @Dusk