Temas en tendencia
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Cómo SuperVaults utiliza las pruebas de merkle para bloquear qué código puede afectar tus fondos 🔐
Cada bóveda DeFi necesita interactuar con protocolos externos: depósitos en fuentes de rendimiento, aprobaciones de tokens, redenciones. Pero, ¿cómo se asegura de que solo las operaciones aprobadas puedan ejecutarse?
SuperVaults resuelve esto con una capa de validación de prueba de Merkle.
La idea central—
Cada acción permitida es una hoja en un árbol Merkle: hash(hookAddress + encodedArgs)
¿Quieres depositar USDC en Yearn? Esa combinación exacta —la dirección del gancho de depósito + la bóveda Yearn + USDC— debe existir como una hoja en el árbol.
Sin prueba = reversiones de transacciones.
Pero eso no es todo, los supervaults tienen un modelo de seguridad de dos niveles:
1️⃣ Árbol Global (por cadena) - Operaciones genéricas que puede realizar cualquier bóveda. Depósitos, aprobaciones, swaps. Aquí no hay nada de compex
2️⃣ Árbol de Gestores (por bóveda) - Operaciones específicas de estrategia que pueden mover fondos FUERA. Redenciones, transferencias. Cada bóveda tiene su propio árbol con destinos en listas blancas.
Esta separación significa que, incluso si alguien compromete la configuración global, no puede añadir destinos de retirada arbitrarios. Esos están en árboles de gestión específicos de la bóveda.
Lo que 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 args Merkle son el límite de confianza.
Las actualizaciones de root tienen un bloqueo temporal.
No puedes simplemente empujar una raíz maliciosa y drenar en el mismo bloque. Se proponen cambios → se esperan → se ejecutan. Da tiempo a los sistemas de monitorización para detectar actualizaciones sospechosas.
¿Por qué los árboles merkle?
- Tamaño de prueba O(log n): un árbol con 10.000 operaciones aprobadas solo necesita ~13 hashes para demostrar la pertenencia - Determinista: la misma configuración siempre produce la misma raíz - La verificación on-chain es barata: solo hay que hacer hash en la ruta de prueba y comparar con la raíz almacenada
El resultado: un vault que puede interactuar con decenas de protocolos y miles de combinaciones de token/fuente de rendimiento, pero solo las combinaciones exactas aprobadas en la configuración. Todo lo demás rebota.

Populares
Ranking
Favoritas
