# Idea/Sanity Check: Multi-Protocol ERC-4626 Yield Vault for Rootstock, Strategic-tier pre-RFC walkthrough **URL:** \ **Category:** Grants & Incentives\ **Created:** [June 27, 2026, 2:03pm UTC](https://gov.rootstockcollective.xyz/t/idea-sanity-check-multi-protocol-erc-4626-yield-vault-for-rootstock-strategic-tier-pre-rfc-walkthrough/894 "2026-06-27T14:03:08Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![Curia](https://yyz2.discourse-cdn.com/flex030/user_avatar/gov.rootstockcollective.xyz/curia/32/943_2.png) [@Curia](https://gov.rootstockcollective.xyz/u/Curia)\ **Post date:** [June 30, 2026, 4:42pm UTC](https://gov.rootstockcollective.xyz/t/idea-sanity-check-multi-protocol-erc-4626-yield-vault-for-rootstock-strategic-tier-pre-rfc-walkthrough/894/8 "2026-06-30T16:42:44Z")
Thanks for the tag @NeznaniJunak As you’ve already framed the trust model as layered, we just want to make that split explicit, because immutability only does its job on one of the two layers, and “human monitor vs. fully immutable” is a real trade-off with pros and cons on each side, not a clear win either way. **Vault layer** (your contract) Immutability is great here. It kills the lever behind most DeFi rugs: a stolen or rogue admin key pushing a bad upgrade. No upgrade path, no setters, so a compromised key has nothing to pull. We back this fully. **Protocol layer** (LayerBank and Sovryn) Immutability does nothing here, and the writeup blurs it a bit. If a venue gets exploited, a frozen vault doesn’t undo the loss. What protects users here is the ≤60% cap, fail-closed deposits, and `redeemInKind`, not immutability. And `redeemInKind` is really a vault-failure escape hatch, not a venue-failure one: if the vault accounting breaks but the venues are fine, it works and you exit to healthy protocols; if a venue gets drained, it just hands you a claim on an empty pool. @Eren_DAOplomats already flagged that both venues are Compound V2 forks, and that’s the case worth naming in the trust model: one bug hitting both at once, where the diversification doesn’t help (same code, same weakness) and the exit hatch returns two empty claims. **That’s the one risk nothing in the current design covers.** **Our suggestion on the design** We’d echo @ChronoTrigger on the Guardian/factory key being a multisig. Your design is actually already running a partial hybrid, immutable vault, pause-only guardian on the ERC-20 side — so the ask isn’t to add upgradeability back, it’s just to harden and name the one key you do keep. The other side of the trade is worth saying plainly to depositors: **immutable also means no patch. If the audit misses something, no one can pause or fix it.** That’s a fair call for a vault this simple, but it makes the audit the whole safety story, not just a milestone. The architecture is genuinely well done. Where we’d push is demand, and this ties to something we reviewed earlier. [TYKORA Prize Vaults](https://gov.rootstockcollective.xyz/t/2602-grant-tykora-prize-vaults-for-doc-usdrif-tropykus-yield-on-rootstock/738/49) was a no-loss lottery: deposit and earn a chance at the pooled yield. We supported the concept but landed on wrong timing for Rootstock, because the lending base wasn’t deep enough to make it work. Looking at the live LayerBank and Sovryn numbers, the two assets you can actually deploy (both venues live) tell different stories: - - - So it’s not uniformly thin, DOC genuinely fits, and that’s a real point in the vault’s favor. But it also means the demand case rests largely on one asset: DOC’s ~$720K organic base on Sovryn plus a shallow incentive-fed LayerBank pool, alongside rBTC where the depth is real but the yield isn’t. That sharpens rather than settles the question — is DOC alone a big enough base to justify Strategic-tier scope, and what’s a realistic 90-day TVL it can pull? That’s what we’d want sized before the RFC, and it’s the same thing @SEEDGov is pointing at. --- _[View the full topic](https://gov.rootstockcollective.xyz/t/idea-sanity-check-multi-protocol-erc-4626-yield-vault-for-rootstock-strategic-tier-pre-rfc-walkthrough/894)._