Hello @NeznaniJunak , this is really strong proposal idea, thank you for posting this sanity check. We also really appreciate the professional approach, particularly the emphasis on a “Phase 0” self-funded pilot to demonstrate operational viability before requesting DAO capital. This aligns well with the accountability standards the Collective is looking to foster.
We have a few points and questions, that focuses on the economic and operational side for further clarification:
1. Economic Utility and Demand: We support the feedback raised by @Curia regarding the “yield” thesis. While the vault architecture is technically sound, we are concerned about the long-term organic demand. In DeFi, vaults often compress yields rather than generating them.
-
Your assessment that DOC is the primary fit is compelling. we would suggest sharpening your proposal to position this vault specifically for the DOC market.
-
When you publish a RFC, we recommend that you provide a more detailed breakdown of your 90-day TVL targets. Who is the specific user base (e.g., wallet integrators, institutional liquidity providers) you expect to onboard?
2. Audit Budgeting and Contingency: We also echo @ChronoTrigger concerns regarding the audit budget. Relying solely on a single firm’s quote at the $13K - $15K band leaves little room for maneuver.
-
Given the complexity of a dual-trust-model vault, audit costs can often escalate if findings require re-audits or deeper scope. Does your budget account for potential overruns, or is there a “Plan B” if the initial quote comes in higher?
-
Have you identified alternative firms in the same tier that could serve as a backup if Coinspect’s capacity or pricing changes?
-
You also mentioned in your proposal that you questioned about if anyone had experience using Coinspect? Check out this TYKORA grant who recently completed their audit with Coinspect (we recommend that you connect with the JXLabs Team on their experience of using Coinspect). You could also get a quote from Coinspect to ensure that your budgeted costs are more accurate (such as JXLabs Team team did for their grant).
3. The Guardian Key: Regarding the Guardian role, we agree with the suggestion to move toward a multi-sig structure for the deposit-pause key.
- While the vault is “immutable” by design, the Guardian key remains a critical control point. Utilizing a 2-of-3 or similar multi-sig setup would provide the necessary checks and balances that institutional users expect, without sacrificing the security benefits of your immutable architecture. Identifying this now before it goes to a RFC reduces your risk exposure.
4. Risk Disclosure: As this vault is designed to be immutable, it inherently lacks a “patch” mechanism. Please explicitly address this in your documentation: if a bug is discovered post-deployment, what is the exact communication and exit strategy for users? A clear “No-Patch Policy” document would be a valuable addition to your evidence pack for delegates to review.
We look forward to your thoughts on these points. Your technical foundations are strong, and if we can refine the economic and contingency planning, this could be a very valuable addition to the Rootstock DeFi landscape. Tks!