Cómo los SuperVaults utilizan pruebas de merkle para restringir qué código puede tocar tus fondos 🔐 Cada bóveda DeFi necesita interactuar con protocolos externos: depósitos en fuentes de rendimiento, aprobaciones de tokens, redenciones. Pero, ¿cómo aseguras que solo se puedan ejecutar operaciones aprobadas? Los SuperVaults resuelven esto con una capa de validación de prueba de merkle. La idea principal- Cada acción permitida es una hoja en un árbol de merkle: hash(hookAddress + encodedArgs) ¿Quieres depositar USDC en Yearn? Esa combinación exacta - la dirección del gancho de depósito + la bóveda de Yearn + USDC - debe existir como una hoja en el árbol. Sin prueba = la transacción se revierte. Pero eso no es todo, los supervaults tienen un modelo de seguridad de dos niveles: 1️⃣ Árbol Global (por cadena) - Operaciones genéricas que cualquier bóveda puede realizar. Depósitos, aprobaciones, intercambios. Nada complejo aquí. 2️⃣ Árbol del Administrador (por bóveda) - Operaciones específicas de la estrategia que pueden mover fondos FUERA. Redenciones, transferencias. Cada bóveda tiene su propio árbol con destinos en la lista blanca. Esta separación significa que incluso si alguien compromete la configuración global, no puede agregar destinos de retiro arbitrarios. Esos viven en árboles de administrador específicos de la bóveda. Qué se valida- No todos los parámetros - solo los críticos para la seguridad. Para un gancho de aprobación, validamos (token, gastador) pero no la cantidad. Los argumentos de merkle son el límite de confianza. Las actualizaciones de raíz tienen un bloqueo de tiempo. No se puede simplemente empujar una raíz maliciosa y drenar en el mismo bloque. Los cambios se proponen → se espera → se ejecutan. Da tiempo a los sistemas de monitoreo para marcar actualizaciones sospechosas. Por qué árboles de merkle- - Tamaño de prueba O(log n) - un árbol con 10,000 operaciones aprobadas aún necesita solo ~13 hashes para probar la membresía - Determinista - la misma configuración siempre produce la misma raíz - La verificación en cadena es barata - solo hash el camino de prueba y compáralo con la raíz almacenada. El resultado: una bóveda que puede interactuar con docenas de protocolos y miles de combinaciones de tokens/fuentes de rendimiento, pero solo las combinaciones exactas aprobadas en la configuración. Todo lo demás rebota.