Como os SuperVaults usam provas de merkle para restringir que código pode tocar nos seus fundos 🔐 Cada vault DeFi precisa interagir com protocolos externos - depósitos em fontes de rendimento, aprovações de tokens, resgates. Mas como garantir que apenas operações aprovadas podem ser executadas? Os SuperVaults resolvem isso com uma camada de validação de prova de merkle. A ideia central- Cada ação permitida é uma folha em uma árvore de merkle: hash(hookAddress + encodedArgs) Quer depositar USDC no Yearn? Essa combinação exata - o endereço do hook de depósito + vault do Yearn + USDC - deve existir como uma folha na árvore. Sem prova = transação reverte. Mas isso não é tudo, os supervaults têm um modelo de segurança em duas camadas: 1️⃣ Árvore Global (por cadeia) - Operações genéricas que qualquer vault pode fazer. Depósitos, aprovações, trocas. Nada complexo aqui 2️⃣ Árvore do Gestor (por vault) - Operações específicas de estratégia que podem mover fundos PARA FORA. Resgates, transferências. Cada vault tem sua própria árvore com destinos na lista branca. Essa separação significa que mesmo que alguém comprometa a configuração global, não pode adicionar destinos de retirada arbitrários. Esses vivem em árvores de gestor específicas do vault. O que é validado- Não cada parâmetro - apenas os críticos para a segurança. Para um hook de aprovação, validamos (token, spender) mas não o montante. Os argumentos de merkle são a fronteira de confiança. Atualizações de raiz têm um bloqueio de tempo. Não pode simplesmente empurrar uma raiz maliciosa e drenar no mesmo bloco. As mudanças são propostas → esperadas → executadas. Dá tempo aos sistemas de monitoramento para sinalizar atualizações suspeitas. Por que árvores de merkle- - Tamanho da prova O(log n) - uma árvore com 10.000 operações aprovadas ainda precisa de ~13 hashes para provar a membresia - Determinístico - a mesma configuração sempre produz a mesma raiz - Verificação on-chain é barata - apenas hash o caminho da prova e compare com a raiz armazenada O resultado: um vault que pode interagir com dezenas de protocolos e milhares de combinações de tokens/fontes de rendimento, mas apenas as combinações exatas aprovadas na configuração. Tudo o mais é rejeitado.