Aave propõe uma estrutura de risco após o exploit de $292M KelpDAO

Aave está propondo uma estrutura de gestão de riscos para governar os ativos listados entre Aave V3, V4 e Aave Horizon, na sequência do exploit do KelpDAO em abril. O ataque permitiu que invasores cunhassem aproximadamente US$ 292 milhões em rsETH sem lastro via ponte LayerZero do KelpDAO e usassem o ativo como colateral no Aave. A estrutura introduz padrões mais rigorosos para o onboarding de ativos, configuração de pontes, sistemas de monitoramento e implantações de cadeias para endereçar fragilidades na infraestrutura de pontes e em sistemas offchain que podem criar risco de nível de protocolo.

Aave Framework Estabelece uma Estrutura de Risco em Quatro Camadas

A estrutura é organizada em quatro camadas: risco do ativo, risco de bridging, sistemas de monitoramento e oráculo automatizado de risco, e risco da cadeia. Na camada de risco do ativo, cada ativo listado precisaria atender a requisitos ligados a auditorias, cobertura de bug bounty, liquidez, timelocks, autoridade de assinatura, divulgações legais, visibilidade do lastro e operações do emissor. Cobertura de bug bounty ausente ou materialmente fraca, achados de auditoria não resolvidos, ausência de timelocks em caminhos críticos de upgrade, estruturas de signatário não divulgadas ou arranjos de lastro opacos seriam tratados como condições de bloqueio obrigatório. A estrutura define que as revisões de ativos sejam um processo contínuo em vez de uma aprovação única, com cada ativo passando por uma atualização trimestral de diligência prévia. Revisões fora do ciclo seriam acionadas por mudanças materiais como novas implantações de cadeia, upgrades de contrato, alterações de rota de ponte, atualizações de oráculo ou mudanças no lastro das reservas.

Requisitos de Segurança da Ponte Incluem Verificadores Independentes e Limites de Taxa

A camada de risco de bridging do Aave introduz regras para ativos entre cadeias. As rotas de ponte precisariam ter topologia documentada, pelo menos três verificadores independentes, mudanças de autoridade com timelock, caminhos separados para pausa, limites de taxa por rota, cobertura de resposta a incidentes 24/7 e equipes dedicadas de monitoramento. A proposta inclui novos padrões sobre divulgações de pontes, independência dos verificadores, limites de taxa, monitoramento automatizado e mecanismos defensivos de freeze. Rotas que não cumprirem os requisitos obrigatórios de ponte podem enfrentar tetos menores, menores índices loan-to-value ou restrições para expansão entre cadeias. A estrutura também define padrões para as cadeias nas quais o Aave faz deploy, com cadeias que tenham suporte mais fraco de infraestrutura, liquidez, governança ou monitoramento enfrentando limites mais apertados em todos os ativos listados nelas.

Monitoramento Automatizado Permite Congelamentos de Ativos Antes da Resposta de Governança

A estrutura adiciona defesas para riscos que podem se espalhar antes de a governança ter tempo de reagir. O Aave seria capaz de congelar automaticamente os ativos ou reduzir a exposição quando sinais de alerta aparecerem, enquanto qualquer movimento para restaurar limites ainda exigiria revisão humana. Os Risk Stewards do Aave cuidariam da recuperação e das mudanças de parâmetros após um alerta, enquanto a Umbrella atuaria como a camada final de segurança se as perdas ainda atingirem o protocolo.

FAQ

O que motivou a proposta do Aave por uma estrutura de risco mais rígida? O Aave propôs a estrutura na sequência do exploit do KelpDAO em abril, no qual invasores cunharam aproximadamente US$ 292 milhões em rsETH sem lastro via a ponte LayerZero do KelpDAO e usaram o ativo como colateral no Aave. O exploit revelou fragilidades na configuração da ponte e na infraestrutura offchain.

Quais são as quatro camadas da proposta de estrutura de risco do Aave? A estrutura é organizada em quatro camadas: risco do ativo, risco de bridging, sistemas de monitoramento e oráculo automatizado de risco, e risco da cadeia. Essas camadas definem como os ativos são avaliados antes da listagem, como são revisados após o onboarding e quando a exposição deve ser reduzida ou descontinuada.