Todo mundo culpou o Kelp até que a “configuração padrão” revelou ser a verdadeira vulnerabilidade.👇

A equipe @KelpDAO divulgou sua análise da exploração.
E, honestamente, a narrativa do CT parece incompleta, culpando-a pelo mau design do Kelp.
Mas, quando você olha de perto, na verdade, não é bem assim.
Primeiro, a configuração que todos continuam mencionando, o DVN 1/1.
Existem partes que as pessoas estão pulando.
> 1/1 DVN é a configuração padrão nos documentos e GitHub do LayerZero
> 40% dos protocolos estão usando exatamente essa configuração
Então, o Kelp não fez nada de exótico.
Eles seguiram o caminho padrão que a maioria dos desenvolvedores seguiria ao integrar.
Acredito que a pergunta que todos deveriam estar fazendo é:
> por que uma configuração assim era padrão em primeiro lugar?
Quer dizer, todo mundo certamente usará a configuração padrão ao implantar, certo?
E isso também é algo que o LayerZero recomenda para outros.
Não foi apenas uma escolha fraca de configuração, ela expôs um modelo de verificação quebrado.
A segunda parte é a conscientização.
O LayerZero conhece muito bem a configuração do seu ecossistema, o que significa:
> eles poderiam ver quais protocolos estavam usando o DVN 1/1
> eles poderiam ver o quão difundida essa configuração era
Se 40% do ecossistema usa uma infraestrutura, ela deve estar sob revisão constante de segurança.
Mas não houve nada disso, sem atualizações ou medidas de proteção.
Sem uma rota de migração obrigatória para sair de defaults inseguros.
Isso vai além de um erro na camada de aplicativo.
Está na hora de os protocolos adotarem verificações de segurança constantes.
A segurança entre cadeias só é tão forte quanto sua suposição de verificação mais fraca.
Então, sim, isso não é uma situação de “Kelp ruim” versus “todo mundo bem”.
Defaults arriscados, ampla adoção e falta de fiscalização finalmente levaram à falha.
A responsabilidade é compartilhada, mas a superfície de risco é sistêmica.
Você pode conferir o relatório completo aqui: