How SuperVaults use merkle proofs to lock down what code can touch your funds 🔐 Every DeFi vault needs to interact with external protocols - deposits into yield sources, token approvals, redemptions. But how do you ensure only approved operations can execute? SuperVaults solve this with a merkle proof validation layer. The core idea- Every allowed action is a leaf in a merkle tree: hash(hookAddress + encodedArgs) Want to deposit USDC into Yearn? That exact combination - the deposit hook address + Yearn vault + USDC - must exist as a leaf in the tree. No proof = transaction reverts. But thats not all, supervaults have a two-tier security model: 1️⃣ Global Tree (per chain) - Generic operations any vault can do. Deposits, approvals, swaps. Nothing compex here 2️⃣ Manager Tree (per vault) - Strategy-specific operations that can move funds OUT. Redemptions, transfers. Each vault has its own tree with whitelisted destinations. This separation means even if someone compromises the global config, they can't add arbitrary withdrawal destinations. Those live in vault-specific manager trees. What gets validated- Not every parameter - just the security-critical ones. For an approval hook, we validate (token, spender) but not amount. The merkle args are the trust boundary. Root updates have a timelock. Can't just push a malicious root and drain in the same block. Changes are proposed → waited → executed. Gives monitoring systems time to flag suspicious updates. Why merkle trees- - O(log n) proof size - a tree with 10,000 approved operations still only needs ~13 hashes to prove membership - Deterministic - same config always produces same root - On-chain verification is cheap - just hash up the proof path and compare to stored root The result: a vault that can interact with dozens of protocols and thousands of token/yield-source combinations, but only the exact combinations approved in the config. Everything else bounces.