Todos culpavam a Kelp até que a “configuração padrão” revelou ser a verdadeira vulnerabilidade.👇

A equipa do @KelpDAO publicou a sua análise do exploit.
E, honestamente, a narrativa do CT parece incompleta, culpando-o pelo mau design da Kelp.
Mas, quando olhamos de perto, na verdade, não é assim.
Primeiro, a configuração que todos continuam a mencionar, o DVN 1/1.
Há partes que as pessoas estão a ignorar.
> 1/1 DVN é a configuração padrão nos documentos e GitHub do LayerZero
> 40% dos protocolos estão a usar exatamente esta configuração
Portanto, a Kelp não fez nada de exótico.
Seguiram o caminho padrão que a maioria dos construtores seguiria ao integrar.
A questão que todos deveriam estar a fazer é:
> por que razão uma configuração assim era a padrão em primeiro lugar?
Quer dizer, todos vão certamente optar pela configuração padrão ao fazer deploy, certo?
E isto é também algo que o LayerZero recomenda aos outros.
Não foi apenas uma escolha fraca de configuração, expôs um modelo de verificação quebrado.
A segunda parte é a consciência.
O LayerZero conhece muito bem a configuração do seu ecossistema, o que significa:
> eles podiam ver quais protocolos estavam a usar DVN 1/1
> eles podiam ver quão difundida era esta configuração
Se 40% do ecossistema usa uma infraestrutura, ela deve estar sob revisão de segurança constante.
Mas nada disso aconteceu, sem atualizações ou medidas de proteção.
Sem uma migração obrigatória para fora de configurações inseguras.
Isto vai além de um erro na camada da aplicação.
É altura de os protocolos adotarem verificações de segurança constantes.
A segurança entre cadeias só é tão forte quanto a sua suposição de verificação mais fraca.
Por isso, sim, isto não é uma situação de “Kelp mau” versus “todos os outros bons”.
Configurações arriscadas, adoção ampla e sem fiscalização levaram, por fim, à falha.
A responsabilidade é partilhada, mas a superfície de risco é sistémica.
Deves consultar o relatório completo aqui: