Idea/Sanity Check: Multi-Protocol ERC-4626 Yield Vault for Rootstock, Strategic-tier pre-RFC walkthrough

[NeznaniJunak]

Hello everyone. I am a Rootcamp Cohort 1 graduate and I would like to turn my capstone into a production product. Before I put a formal proposal on Collective I want to sanity check the idea here. Any pushback is appreciated. I also have a few questions I’m hoping to get answered.

TL;DR

Field	Value
Author	Ivan Ursulovic (NeznaniJunak), solo dev
Background	Cohort 1 Builders Rootcamp graduate, capstone April 2026
Project	ERC-4626 multi-protocol yield vault, Sovryn Lend + LayerBank
Repo	GitHub - Ursulovic/rootstock-yield-vault · GitHub
Demo	https://rootstock-yield-vault.vercel.app
Code state	228 unit + 28 fork + 6 halmos symbolic + 9 invariants × 128K calls; 100% line/statement/function coverage on the three core contracts
Testnet	rBTC vault live on chain 31, all three contracts Blockscout-verified
Tier	Strategic, target $25K within the $10K-$35K band (sizing rationale below)
Structure	M1 audit-anchored and split M1a/M1b (audit money releases on delivery), 30% terminal holdback per V3.2.2 floor, 5 milestones plus 0% Phase 0 gate
Trust model (rBTC vault)	No admin, no upgrade path, no pause
Trust model (ERC-20 vault)	Guardian can pause deposits only; withdrawals always live
Escape hatch	redeemInKind() returns pro-rata adapter receipts; try/catch hardening already merged, audit confirmation in M1
Membership	1,000 stRIF; not a delegate
RFC release	Held until at least one signed integrator LOI is attached

About me

My name is Ivan Ursulović. Currently I work as backend and web3 engineer at DeGenerous DAO, where I built Solidity governance contracts, shipped an NFT staking system, and run the on-chain/off-chain backend that ties NFT trait evolution to AI-driven storytelling (CoNexus). Before DeGenerous I spent a few months in the Gno.land Student Contributor Program working on smart contracts and developer tooling in Gno (a Go-based language). My web2 background is at LotusFlare on a large-scale telecom MVNE orchestration platform, and C#/.NET microservices at TeleTrader on the financial-data side.

I am also pursuing a Master’s in Computational Finance at the School of Computing, Union University in Belgrade. The coursework has been a real help in understanding the DeFi economics the vault is built on top of.

I built the first version of the vault as my Builders Rootcamp capstone (April 2026) and have been working on it since.

What it is

An ERC-4626 vault that routes a single underlying asset across multiple lending venues through per-protocol adapters. Per-adapter caps are immutable at construction. The rBTC vault has no owner, no upgrade path, no admin-side pause.

What happens if a lending protocol breaks or gets exploited? There’s no admin key to trust. The guarantees are enforced in the contract itself. No single adapter holds more than 60% of TVL, so a blowup at one venue cannot take the whole vault. Once an adapter’s view starts reverting, deposits stop accepting new money, so nothing fresh gets trapped in bad accounting. Anybody can call rebalance() to move funds into the healthy adapter; it isn’t gated to me. And if vault accounting itself gets compromised, redeemInKind() hands users their adapter receipt tokens directly, so they can exit straight to the underlying protocol.

The ERC-20 variant adds a Guardian role limited strictly to pausing deposits; withdrawals always work.

The constructor enforces _adapters.length >= 2, _adapterCapBps * _adapters.length >= 10_000, _callerRewardBps <= 500, _maxSaneRate > 0, and _tvlCap > 0. These are hard rules. You cannot deploy a single-protocol vault from this factory.

Why this matters for Rootstock DeFi

Rootstock has BTC-aligned lending primitives but nothing shared sitting on top of them. A wallet or app that wants to offer a passive rBTC or stablecoin product today has to pick one venue and eat its risk. ERC-4626 is the standard tokenized-yield interface on most EVM chains, and Rootstock doesn’t have a solid one yet.

Two things I watched recently pushed me toward this design. When Tropykus shut down in May 2026, TYKORA pivoted to Sovryn without touching its vault contracts because the adapter sat between them. The Yearn yETH exploit in November 2025 hit complex stableswap strategy logic, but the underlying ERC-4626 primitive was never the problem. A small immutable vault with the protocol layer swappable underneath survives both: a venue shutting down, and a strategy getting exploited. Anything fancier is a bug surface waiting to happen.

Differentiation

Project	Trust model	Scope	License
TYKORA	Multisig + emergency cancel	Curated prize-vault product (single-protocol per vault)	Proprietary
Mellow Core / Tyr	Curator-gated, KYC	Institutional only	Mixed
This vault (rBTC)	No admin, no upgrade, no admin-side pause	Multi-venue per asset from day 1 (≥2 adapters enforced at construction)	MIT
This vault (ERC-20)	Guardian for deposit-pause only; withdrawals always live	Multi-venue per asset from day 1	MIT

A few neighbors worth flagging. The Foundation BTC Vault Sandbox is curator-managed and scoped as a pilot. RootstockLabs Vaulted rBTC was announced for H2 2026, still not deployed. Solv sits a layer up and could plug this vault in as a yield source, and Excellar xlBTC isn’t live yet either. I’m open to adapter-level integrations with any of them.

Adapter universe

I looked hard for a third protocol. There isn’t one today.

Tropykus web UI ends 27 July 2026, contracts wind down 1 September 2026. Avalon Labs on Rootstock is dust ($806 across 9 holders) and would need ~130 LOC of custom code for ReserveData revision differences. Segment is EOA-controlled with pause guardian set to 0x0 and $161 TVL; centralization AVOID. Sovryn Zero and MoneyProtocol stability pools break the monotone-balance invariant. MoC BPro and RIF on Chain are leveraged price exposure, wrong primitive. Steer, Oku, Sovryn AMM break single-asset monotone. Bedrock uniBTC/brBTC have async multi-day exits. SolvBTC variants are reserve wrappers, xSolvBTC is an async SFT, SolvBTC.BBN is points-only. Pell is points-only. BabelFish XUSD: zero audits, no bounty, semi-abandoned.

Both adapters (LayerBank, Sovryn Lend) are Compound V2 cToken forks. Multi-venue gives me protection against one venue going down (the other keeps working), but it does not protect against a bug class that hits both at once. If that ever happens, redeemInKind is what gets users out without a write-off.

What I am tracking for next quarter: RootstockLabs vUSD cap-lift, RootstockLabs Vaulted rBTC mainnet, Excellar xlBTC TGE, Avalon crossing $250K, Sovryn DAO listing iUSDRIF or iRIF, LayerBank live-gen listing for USDT/RIF/USDC.e/WETH.

Mainnet deployability

Asset	LayerBank	Sovryn	Verdict
rBTC	WRBTC aToken live	iRBTC live	HIGH, zero new code
DOC	aDOC live (0x3F04…0CaA2, ~135K DOC supplied at recent snapshot; full block + figure re-pinned in formal RFC evidence pack)	iDOC live	HIGH, zero new code
USDRIF	aUSDRIF live	none	BLOCKED, fails _adapters.length >= 2
DLLR	none	iDLLR live	BLOCKED, no second venue
XUSD	none	iXUSD live	BLOCKED, BabelFish underlying = AVOID (security, not adapter count)
USDT	live-gen listing unverified	iUSDT live	PENDING verification before any M-stage commitment
RIF	live-gen listing unverified	none	BLOCKED
USDC.e	live-gen listing unverified	none	BLOCKED
WETH	live-gen listing unverified	none	BLOCKED
BPRO	n/a	iBPro live (RISKY)	BLOCKED; only would-be second venue (Tropykus kBPRO) sunsetting; underlying MoC BPro is leveraged price exposure

HIGH means the market is live and has enough liquidity to matter at this vault’s scale. Balances move with usage and the numbers will be refreshed at formal RFC submission.

Phase 0 gate (self-funded, before any tranche)

Precedent: Andromeda Core #876.

• TVL hard-cap is set by an immutable tvlCap constructor parameter, 0.5 rBTC equivalent for the Phase 0 deployment. The cap is the hard economic gate; even with a sybil bypass, exposure cannot exceed 0.5 rBTC. Diff and Blockscout link posted with the formal RFC.
• Minimum duration: 60 days
• Public dashboard URL committed in the formal RFC, weekly snapshots
• redeemInKind try/catch hardening (closing KNOWN_ISSUES #6) is already merged ahead of the Phase 0 fresh-deploy batch, so the escape hatch is unconditional during the pilot. The asymmetry is intentional: deposit and mint stay fail-closed so a broken adapter cannot trap new money in bad accounting; redeem, withdraw, and redeemInKind are fail-open so users can always get out.
• Pass/fail gating metrics for M1 release:
  • Zero critical incidents. “Critical” here means any of: loss of user principal beyond ERC-4626 rounding tolerance, withdrawal blocked >24h, reproducible invariant break on mainnet state, unauthorized state mutation
  • In operational terms, a reproducible invariant break is: the pinned-Foundry invariant suite at the Phase 0 deploy commit fails when run against a mainnet fork at any block within the Phase 0 window. The suite runs as a GitHub Actions workflow on each weekly snapshot date (pinned Foundry version + commit hash, mainnet fork at snapshot block, 128K calls per invariant); the workflow URL goes on the public dashboard. Any community member can re-run it against the same commit at a block of their choosing. A failed run blocks M1 release.
  • ≥10 depositors with distinct funding sources (no shared upstream EOA within 7 days of first deposit) AND no single depositor >40% of TVL at any weekly snapshot
  • All redemptions honored via redeem() (subject to documented ERC-4626 sub-grain rounding always in the vault’s favor) or redeemInKind() as unconditional escape
• I am funding this myself. I will not request M1 tranche release if any Phase 0 gate fails; tranche release is the DAO’s call.

Phase 0 is me putting my own money on the line on top of a hardened codebase, so the DAO has on-chain evidence to point at instead of taking my word for it.

Proposed milestones

#	Deliverable	Tranche
Phase 0	Self-funded mainnet pilot under the parameters above	$0 (gate)
M1a	Signed audit quote attached + audit kickoff + rBTC mainnet deploy at audited commit	$4,000 (16%)
M1b	Audit report PDF + IPFS CID published in evidence pack + Blockscout-verified post-fix redeploy	$8,000 (32%)
M2	DOC mainnet deploy + post-audit fixes merged + integrator docs	$2,500 (10%)
M3	Invariant suite expansion + formal-spec doc + integrator SDK (framework-agnostic; concrete stack chosen with the first signed LOI partner)	$3,000 (12%)
M4	90-day operational report, TVL/usage metrics, handover docs	$7,500 (30% terminal holdback)

M1 is split into M1a and M1b so the audit-fee tranche releases when the report lands, not when the quote is signed. I cover any audit overrun personally. Clawback: if the signed Coinspect (or community-recommended firm) quote at M1a release comes in under $13K, the M1a+M1b combined tranche drops to (signed quote + $1K deploy labor) and the delta returns to the Foundation treasury or rolls into M2 at the DAO’s discretion. That way the buffer is locked in by the rule, instead of resting on my word.

M2 and M3 are small on purpose. M1 is audit-heavy and M4 absorbs the 30% terminal holdback, so the middle tranches are tight. I am partly subsidizing the work on M2 and M3. They still gate the tranche if I miss a deliverable.

M3 is invariant suite expansion + formal spec + integrator SDK. I looked at two alternatives (Aori intent-deposit hook, RedStone Credora risk-driven caps) and deferred both to post-grant work because they pull in third-party dependencies I would rather not bake into a Strategic-tier scope.

Sizing rationale

Bottom-up build for the $25K total:

• Audit ($13-15K working assumption for Coinspect at this scope; see audit question below)
• Pre-audit redeemInKind + TVL-cap hardening + new invariant + Phase 0 mainnet deploy + Blockscout verification ($2-3K labor)
• DOC mainnet deploy + post-audit fixes + integrator docs ($2.5K)
• Invariant suite expansion + formal-spec doc + integrator SDK ($3K)
• 90-day operational reporting + handover documentation ($1.5-2K labor; M4 also acts as terminal holdback per V3.2.2 floor)

Precedent for cross-check: TYKORA at $20K (Coinspect, single-protocol prize vault) and BΔLT at $20K (Coinspect, single-trust-model custody). This proposal is about double the scope (dual trust model, dual protocol, full Tier 1 ERC-4626 surface, net-new M3 work outside the audit envelope) on ~1.5x the nSLOC. The $25K is the bottom-up sum above; it lands ~25% over the two-protocol Coinspect baseline. I would rather list each line and let delegates push back on the numbers than ship a multiplier that looks reverse-engineered.

Cross-funding disclosure

This work originated as my Cohort 1 Builders Rootcamp capstone (April 2026). I received the standard program-completion stipend and cohort NFT, same as all Cohort 1 participants. I hold 1,000 stRIF per RootstockCollective membership threshold; not currently a delegate. No other DAO, foundation, protocol, or grant program funds the scope this proposal requests, and I have no parallel grant application open elsewhere. If anything changes between this sanity check and the formal RFC I will disclose it inline.

Current state

Done: testnet rBTC vault and both adapters Blockscout-verified at 0x6a20…0cE2, 0xaF57…B37A, 0x722F…bFd0 (full addresses + URLs in formal RFC). Vercel demo live. 228 unit + 28 fork + 6 halmos symbolic + 9 invariants × 128K test layers. 100% line/statement/function coverage on the three core contracts (95% branches on YieldVault, 2 defensive branches uncovered).SECURITY.md documents the trust model and disclosure path.

Merged ahead of the Phase 0 fresh-deploy batch: (1) immutable tvlCap constructor parameter with maxDeposit/maxMint overrides per ERC-4626, enforcing the 0.5 rBTC Phase 0 ceiling; (2) redeemInKind and totalAssets try/catch hardening closing KNOWN_ISSUES #6 by wrapping every adapter getBalance() and transferPosition() call. Entry paths stay fail-closed, exit paths are fail-open. Both diffs in scope for the M1 audit.

Not yet done: mainnet deploy, signed auditor quote, signed integrator LOIs, KYB approval, video pitch.

Release gate for the formal RFC: at least one signed integrator LOI attached to the proposal. Merge Wallet is the most likely first signature given their 9 June public ask; Beexo and Defiant Wallet are next on the outreach list. LOI format default: countersigned PDF on integrator letterhead, IPFS CID published in the evidence pack. I will post a public status update when either (a) the first LOI is signed and attached, or (b) any named candidate declines (with permission to name them).

Audit question for the community

Before I send outreach I want a sanity check on pricing.

The two Rootstock grant audits I can find that actually shipped were both Coinspect engagements at the $20K Strategic-tier total: TYKORA at ~$11K Coinspect quote (topic 738, M1 completed April 2026) and BΔLT at ~$10K Coinspect (topic 348, completed with public report). For ~1240 nSLOC across one ERC-4626 vault + two Compound-V2-fork adapters + the invariant / Halmos / fork / mutation test layers, with Slither clean and AUDIT_SCOPE.md ready, $13-15K from Coinspect feels about right to me: a bit over the TYKORA and BΔLT quotes, for a job that’s close to twice their size. Sherlock’s 2026 timeline guidance suggests 7-9 researcher-days for this kind of scope.

For anyone who has been through a Rootstock audit recently: has anyone engaged Coinspect on a dual-trust-model multi-protocol vault? Is the $13-15K assumption realistic, or am I pricing it too low? If there is a stronger fit at this size (Hacken, Zealynx, OmniscientLabs, Pashov, Cantina solo), I want to hear it. Coinspect is the working assumption pending this thread; the formal RFC will pin the firm and the signed quote before submission. And if the DAO would rather see a boutique firm in the $20-30K band, I will absorb the delta or rescope M2/M3 line items.

Open questions

A few things I would value pushback on.

First, the Phase 0 parameters (0.5 rBTC cap, 60 days, ≥10 distinct-funded depositors, the critical-incident gate above, ≤40% single-depositor concentration, hardening already merged). Does that match the de-risking pattern the DAO settled on after Andromeda Core #876, and does the M1a/M1b split get audit-money-on-delivery right? @tamlerner, @Tane.

On architecture, I’d like a gut check on the split trust model: rBTC fully trustless, ERC-20 with a deposit-pause-only Guardian, plus the pre-Phase-0 hardening. Right trade-off? And is M3 (invariant suite + formal spec + integrator SDK) the right Strategic-tier scope, or should I have kept one of the alternatives I deferred (Aori intent-deposit hook, RedStone Credora risk-driven caps)? @Curia, @ChronoTrigger.

Last one is operational evidence. Between the Phase 0 pass/fail metrics, the public GitHub Actions invariant suite, and the dashboard, is that enough public mainnet proof before you release a tranche? @Kaf_Anode.

Closing

Thanks in advance for any pushback before I write the formal RFC. The KYB inquiry I sent to compliance@ on 17 May has not been answered yet, if there is a better channel to reach the team, I am open to it.

[Eren_DAOplomats]

Appreciate the thoroughness here, Ivan. Structuring the grant with a strict M1a/M1b split for audit delivery directly addresses the administrative bottlenecks we’ve seen in recent proposals.
That being said, we need to stress-test a few assumptions before the formal RFC:

1. Audit Overrun Risk: You offered to personally cover any Coinspect audit cost above the $13k–$15k working assumption. Given the multi-protocol complexity and invariant testing, if that quote comes back closer to $25k, relying on a solo developer to personally subsidize a five-figure delta introduces a massive execution risk.

2. Compound V2 Monoculture: As both LayerBank and Sovryn Lend are Compound V2 forks, capping an adapter at 60% TVL offers limited protection against a core codebase exploit. If the underlying pools are drained, redeemInKind() just hands users an empty receipt.

3. M3 Scope & Integration: I completely agree with keeping M3 focused on the SDK and formal specs rather than pulling in external intent hooks like Aori. However, waiting for an LOI from Merge Wallet might unnecessarily stall this. The DAO shouldn’t have a high-quality yield primitive sitting idle purely because of third-party delays.

[Kaf_Anode]

Thanks for tagging me, @NeznaniJunak

Since you’re asking what kind of proof would be needed before releasing payments, I have a few questions rather than a firm opinion at this stage.

Do you see Phase 0 mainly as a small test to show that everything works properly on mainnet, rather than as proof of real demand? With a 0.5 rBTC cap, it seems useful to show that the system works, but maybe not enough to show that users or wallets actually want to use it.

I also wanted to ask about the integration side. Would the RFC come with a strong LOI, or at least a clear first integrator, before funding the SDK work?

Another question is maintenance. Since this is currently a solo-dev project, what would happen if, for any reason, you couldn’t keep maintaining the vault?

And on the audit: if it ends up costing quite a bit more than the estimated $13k–$15k, would you change the plan, or is there another way to avoid everything depending on you personally covering the difference?

[ChronoTrigger]

hey @NeznaniJunak, thank you for tagging me.

First things first, on your Phase 0, this is one of the best proposal de-risks I’ve seen here, with a self-funded Phase 0, security caps, Phase 0 KPIs gating the first disbursement, and a signed-LOI gate on the RFC itself.
I like the M1a/M1b split getting audit money on report delivery.

On audit pricing: $13-15K for Coinspect at this scope sounds reasonable for roughly 1.5x nSLOC and the dual trust model (referencing TYKORA and BΔLT). That said, I see some colleagues asking for a backup plan in case the values come in higher, and this is a very valid concern worth addressing.

For the rebalance() function, I had to look at the repo to understand it. Ultimately I think it’s very thoughtful, with lastRebalanceTime, maxSaneRate checks, and especially the bestRate > currentRate + rateThreshold check.
My suggestion here is only that you might be selling yourself short by not explaining the rebalancer mechanics at all.
At first, 5% of the yield for every rebalance seemed way too much, but I realized there’s a mechanic to slowly vest yield into share prices, so if I got it right, the incentive will be up to 5% of the last 3 days worth of yield, correct?

a BTC primitive with rBTC fully immutable is a defensible design, and I think immutability is part of the product here, it’s a feature. The same goes for the rebalance reward params, they’re immutable with no setters, so the schedule can’t be changed on depositors after they’re in.

One thing I’d flag though: the “no admin” part holds at the vault level, but at the system level the factory owner is a real admin. it curates trustedAdapters, can delist vaults, and is the Guardian on every ERC-20 vault, so it can pause deposits/mints/rebalancing across all of them at once. and since guardian is immutable, that key can’t be rotated without a redeploy. the pause itself is already scoped right, instant with withdrawals always open, so the only ask is that the key behind it be a multisig from day one and named in the trust model.

As for your specific question to me on M3 scope, I suggest keeping it.
The Credora risk-driven caps would turn your immutable per-adapter caps into dynamic oracle-fed caps, which directly undercuts the no-admin trust story and adds an oracle as a fresh failure point. The Aori hook is a flow feature, not core. The integrator SDK is the right spend because your binding constraint is adoption, not code quality, and the formal spec strengthens the audit narrative. If anything, pull the SDK forward and make it concrete with the first LOI partner.

[SEEDGov]

Hi @NeznaniJunak , thank you for this Idea Check. It’s very well structured!

We have a question: given that the new grant guidelines structure the FES to require the provision of KPIs that demonstrate a positive ROI for Rootstock and verifiable on-chain metrics to unlock milestone payments and the final payment, have you already conducted a preliminary evaluation of what the TVL target should be within 90-days of Milestone 4?

[SEEDGov]

@NeznaniJunak

The KYB inquiry I sent to compliance@ on 17 May has not been answered yet, if there is a better channel to reach the team, I am open to it.

We are tagging @tamlerner here for this topic.

[krngill]

Really like this one. What stood out to me is that you led with the trust model instead of the APY, which is rare for a yield proposal and says a lot about how you are approaching it.

Two small thoughts, trying not to repeat what others said. The redeemInKind escape hatch is a smart idea, but it leans on a regular user knowing what to do once they are holding an adapter receipt. In a stressful moment that is a lot to ask, so it would help to show what the holder actually does next, and whether the SDK covers that exit and not just the smooth path.

The other thing I would love a clear answer on: the whole pitch is diversification, but in practice the vault runs on two venues for most of its life. You explained well why there is no third one today, so what is the actual trigger that adds one later? Something measurable, so it does not just sit at two by default.

[Curia]

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 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:

• 
  
  
  rBTC is deep but the yield is structurally low. On LayerBank it’s ~$1.71M supplied against only ~$25.8K borrowed (~1.5% utilization), so the ~2% APY there is almost entirely incentives, not real lending demand. Sovryn has more genuine borrowing (~29 rBTC supplied, ~28% utilization) but the organic rate is just 0.91% with no incentives. Same story either way: people borrow stables against BTC, not BTC itself, so there’s no real yield to optimize, and a vault that adds supply only pushes the rate lower. The deepest, safest asset is also the one with the least to earn.

• 
  
  
  DOC is the real fit, and the best argument for the vault, deep and working on both venues. Sovryn is the strong side: ~720K DOC supplied, ~90% utilization, ~8.96% lend APR that’s held steady all week, organic borrow demand, not an incentive spike. LayerBank is shallow (~$154K, ~50% utilization) but shows ~19.77% because it’s incentive-boosted. One honest caveat on that spread: the 60% cap forces ≥40% to stay on the lower Sovryn rate, and piling into the shallow LayerBank side dilutes its incentive yield as you size up — so realized blended yield sits well under the 19.77% headline, and the rebalancer’s real job here is enforcing the cap, not capturing a spread.

• 
  USDRIF is worth noting as what you’re leaving on the table: it’s deep and genuinely working on LayerBank (~$370K, ~72% util, 10.65%), but it only exists on one venue, so the ≥2-adapter rule blocks it. The cleanest standalone market is the one the design can’t touch.

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.

[DAOstar_gov]

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!

[PGov]

The trust model layering that @Curia and @ChronoTrigger named is the right frame, and we want to add one point on the adoption side: the LOI gate on the RFC is the strongest structural choice in this whole proposal, because it forces the demand question to be answered with evidence rather than assumption before any funds move. The concern we carry into the RFC is whether Phase 0’s 0.5 rBTC cap is enough to generate the kind of observable user behavior that would make a wallet integrator sign, or whether it just confirms the system runs without confirming there is a market. On audit budget, we agree a contingency path needs to be named explicitly, whether that is a secondary firm, a scope reduction, or a revised milestone split, since a solo developer personally absorbing a cost overrun on a five-figure audit is not a stable foundation for a grant program. We would support a formal RFC once the LOI and the 90-day TVL targets with stated assumptions are both in the document.

[NeznaniJunak]

Thanks @ChronoTrigger, @Kaf_Anode, @Curia, @DAOstar_gov, @SEEDGov, @Eren_DAOplomats, @krngill and @PGov for the close reading and the pushback. Sorry this took a few days, I needed some time to think these through. I put everything in one reply below, plus short direct answers under a few of your posts.

1. Audit contingency: two paths, the DAO picks

if it ends up costing quite a bit more than the estimated $13k–$15k, would you change the plan, or is there another way to avoid everything depending on you personally covering the difference?

That is @Kaf_Anode. @Eren_DAOplomats called a solo developer subsidizing a five-figure delta “a massive execution risk”, @PGov said it “is not a stable foundation for a grant program”, @DAOstar_gov asked for a Plan B, and @ChronoTrigger backed the concern. You are all right. This is my first audit engagement as a solo applicant, and I would rather propose structural transparency than promise to underwrite overruns I cannot cover. Two paths, the DAO picks:

• Path 1. I front the outreach, with radical CC transparency. Every email to an audit firm CCs a Foundation operator and any delegate who wants visibility. Pricing, timelines, engagement letter, scope changes: all in the open. If the quote comes in above budget, that lands here for a decision before anything gets signed.
• Path 2. The DAO holds the auditor engagement contract directly, with Foundation facilitation to structure it. I stay accountable for the code: fixes, deploys, tests. The DAO stays accountable for the audit decisions: firm selection, budget, contract, fix-review scope. This removes my personal overrun exposure entirely and leaves the DAO with a direct auditor relationship it can reuse on future grants.

I hope both paths remove risk you have all flagged.

2. Keys and the trust model

the only ask is that the key behind it be a multisig from day one and named in the trust model.

@ChronoTrigger’s ask, and @Curia made the matching one: “the ask isn’t to add upgradeability back, it’s just to harden and name the one key you do keep.” Both done. Here is the named trust model:

• The vault is immutable. No proxy, no upgrade path. Nobody can patch it, me included.
• The Factory owner and Guardian roles sit behind a 2-of-3 Gnosis Safe on Rootstock, live from mainnet day 1. I hold one seat on a hardware wallet. The other two seats are an open question to this thread. Could be a Foundation operator, a delegate, or an ecosystem builder. If you have a suggestion or want a seat yourself, say so. This is the setup @DAOstar_gov asked for.
• The venues (LayerBank, Sovryn) are external protocols with their own trust assumptions. The docs will state that plainly.

I will publish a public No-Patch Policy document before the formal RFC. It will cover what is frozen forever, what stays actionable (the multisig can delist an adapter from the factory registry, blocking it from future vaults, since live vaults keep their fixed adapter set, and it can pause deposits, mints and rebalancing on ERC-20 vaults; it cannot patch any vault); fork-and-migrate as the only remediation path; the corrected redeemInKind semantics from the next section, and the bug disclosure path. I also looked seriously at a proxy and rejected it. The whole pitch is that nobody can touch a deployed vault. Add an upgrade key and whoever holds it can rug.

While I have you here, @ChronoTrigger: on the rebalancer, you had it right. lastRebalanceTime, maxSaneRate and the bestRate > currentRate + rateThreshold check are exactly the mechanics, and the README gets a section documenting them. One precision: the 5% ceiling is immutable in code, the pilot deploys at 1%.

3. What redeemInKind is and is not, plus the Compound V2 question

it just hands you a claim on an empty pool.

@Curia called this one correctly. redeemInKind is a vault-integrity escape hatch: it gets your position out when the vault’s own accounting breaks. Against a drained venue the receipts it hands you are worthless. The full concession and corrected framing are in my direct reply under their post, and the README and docs get cleaned up to match. @krngill asked what a receipt holder actually does next: that becomes a written exit playbook shipped with the M3 SDK, covering redeemInKind step by step, per-adapter receipt reclaim, a failure-mode decision tree, and honest documentation of partial-recovery cases.

@Eren_DAOplomats raised the sharper structural point:

capping an adapter at 60% TVL offers limited protection against a core codebase exploit

The cap point is correct: it bounds exposure per venue and does nothing against a bug in a venue’s core codebase. One correction on the lineage though, and it is a correction of my own OP, which sloppily called both adapters Compound V2 forks. The deployed contracts say otherwise: LayerBank on Rootstock is an Aave V3 fork (rebasing aTokens, Aave’s ReserveData layout, verified on-chain, and documented in my ILayerBankPool interface), and Sovryn’s iTokens are bZx lineage. Two different codebases, so a single shared-fork bug cannot hit both at once. That said, the real version of the concern stands: with only two venues, the blast radius of any one venue bug is still large. What actually helps:

• A per-venue utilization ceiling (around 90%) added to the code and the audit scope, before the Phase 0 deploy since vaults are immutable. It stops the vault adding funds to a market that is too thin to exit or is being actively drained; a drain in progress pushes utilization toward 100%.
• The M4 report will include a third-adapter readiness assessment against the rubric below. I commit to shipping a third adapter from a codebase independent of both existing venues as soon as the first qualifying protocol on Rootstock passes that rubric. I won’t promise a date I don’t control. And because live vaults keep a fixed adapter set, an added adapter ships in a new factory vault with a documented migration path, the same fork-and-migrate lane the No-Patch Policy names.
• A written quarterly re-scan rubric (@krngill, this is the measurable trigger you asked about): ~$250K TVL, an independent audit, code lineage independent of the existing adapters, and the multisig authorizes the add. Today no protocol on Rootstock passes the bar. I commit to adding the first one that does.

4. rBTC and DOC: split roles

we would suggest sharpening your proposal to position this vault specifically for the DOC market.

@DAOstar_gov’s suggestion, and @Curia’s version of it: “the demand case rests largely on one asset.” I agree with the market read, and I am adopting Curia’s on-chain numbers with credit: about $720K of organic DOC on Sovryn plus a shallow incentive-fed LayerBank pool. So the roles split. rBTC goes first because it is the cheapest thing to pilot on mainnet and because that vault is the one with no admin at all, not because I think it is the bigger market. It isn’t. The demand is DOC, and every TVL target below points there: it carries Phase 1 and the M4 numbers.

5. Demand, Phase 0, and the LOI gate

With a 0.5 rBTC cap, it seems useful to show that the system works, but maybe not enough to show that users or wallets actually want to use it.

@Kaf_Anode, yes, and it is deliberate. Phase 0 is a mainnet-viability and safety step; the demand signal comes from the LOI, the Phase 1 open cap, and the M4 TVL targets, not from the 0.5 rBTC ceiling. @PGov read the LOI gate as doing exactly the job it was built for: no signed LOI, no formal RFC. @PGov raised the same doubt about the cap producing integrator-grade behavior; the same answer applies. And @Kaf_Anode, this also answers your integration question directly: funding only starts after the RFC, and the RFC does not go up without the signed LOI, so no SDK money moves before an integrator commits.

@Eren_DAOplomats pushed from the other side, that M3 should not stall on a partner’s signature, which is also fair. @ChronoTrigger endorsed keeping the SDK as the right M3 spend, which I appreciated; Aori and Credora stay cut. Interfaces, typed contracts and reference tests ship on the M3 timeline regardless of partner status; the wallet-specific integration example ships when the LOI signs. Either way the SDK lands on schedule.

Two more things on the gate itself, since Eren’s stall concern applies to the RFC gate as much as to M3. The gate is satisfied by an LOI from any qualifying integrator; Merge Wallet is the current conversation, not a requirement. And if nothing signs within 90 days of Phase 0 completing, I bring the go/no-go question back to this thread instead of letting the proposal idle.

6. The 90-day numbers

Four of you asked for these in different shapes: @SEEDGov directly, @Curia wanted them sized before the RFC, @DAOstar_gov asked for the breakdown, and @PGov expects stated assumptions.

have you already conducted a preliminary evaluation of what the TVL target should be within 90-days of Milestone 4?

Here they are, built on Curia’s on-chain data:

Scenario	90-day TVL	Integrators	Anchor
BEAR	$10-25K	1	Beefy on Rootstock holds ~$37K after almost two years with no marketing
BASE	$50-150K	2	the entire LayerBank DOC market is about $135K today
BULL	$250-400K	3+	Mellow reached ~$830K in about 6 months, discounted here for no fund-manager backing

The assumptions behind the table: the whole DOC lending market sits around $860K today, so BULL stays below $500K. A new vault on a quiet chain accrues TVL slowly without incentives, and integrations move these numbers more than marketing does. BEAR is deliberately set below its comparable, it is a floor for the M4 gate rather than a forecast. The M4 tranche gates on the BEAR floor plus the qualitative deliverables (final report, public dashboard, operator handover) and nothing else. Integrator adoption count is a co-primary KPI alongside TVL.

One more thing on what the number buys, since a table capped below $500K next to a $25K ask invites the question. Most of the $25K goes into things that outlive the first market: the audit, the adapter framework, the ERC-4626 primitive and the SDK all carry over to whatever asset comes after DOC. The audit prices the codebase, and the same audited framework carries every asset that follows.

7. Continuity

Since this is currently a solo-dev project, what would happen if, for any reason, you couldn’t keep maintaining the vault?

@Kaf_Anode, the honest answer is that the system is designed not to need me:

1. The vault is immutable, so no code sits waiting on my keyboard.
2. Rebalancing is permissionless. Anyone can call it.
3. The 2-of-3 multisig holds the Factory, so my absence does not equal the admin’s absence.
4. Everything is MIT licensed in a public repo, with KNOWN_ISSUES, AUDIT_SCOPE and SECURITY docs already written. Anyone can fork it.
5. M4 includes a handover deliverable: an operator runbook and a dashboard, handed to the Foundation and the multisig.

If I vanish tomorrow, depositors can exit, rebalancing keeps running, and the multisig can still pause ERC-20 vault entry and keep bad venues out of future vaults.

Next steps

• Request the Coinspect quote once this thread signals which audit path it prefers, with the chosen transparency structure applied from the first email.
• Write and publish the No-Patch Policy document before the formal RFC.
• Update README and docs: scrub the redeemInKind venue-safety framing, add the rebalancer mechanics section @ChronoTrigger asked for.
• Collect suggestions and volunteers, in this thread, for the two open seats on the 2-of-3 Safe.
• Hold the formal RFC until the LOI signs.

Thanks again everyone. @Curia, @DAOstar_gov, @PGov and @SEEDGov, short replies coming under your posts in a few minutes.

[NeznaniJunak]

@DAOstar_gov thank you for the structured review.

On economic utility and demand:

we would suggest sharpening your proposal to position this vault specifically for the DOC market.

Agreed, and the RFC will say so explicitly: rBTC is only the pilot, DOC is the market this is aimed at and the TVL targets are built on it. The 90-day breakdown with bear/base/bull assumptions is in my main reply above. On the user base, the concrete profiles: wallet integrators (the Merge Wallet type, one ERC-4626 interface instead of two venue integrations), apps and small treasuries sitting on idle DOC, and individual DOC holders who want spread across LayerBank and Sovryn without managing two positions.

On audit budgeting and contingency:

Does your budget account for potential overruns, or is there a “Plan B” if the initial quote comes in higher?

I put two options for the audit engagement in section 1 of my main reply and left the choice to the DAO. I have not contracted an audit before, which is exactly why I want the structure to carry the overrun risk instead of my wallet. On backup firms: I have not locked a shortlist, and I would rather not name firms I have not spoken to yet. Vetting one or two comparable-tier backups is part of the pre-RFC auditor outreach under whichever path the DAO picks, and the shortlist goes into the RFC document next to the written Coinspect quote. Which also answers the timing question: the quote lands before I submit the formal RFC, not after. And thank you for the JXLabs/TYKORA pointer: a direct reference from a team that has been through a Coinspect engagement on this same forum is exactly the kind I meant, and I will start there before signing anything.

On the Guardian key:

Utilizing a 2-of-3 or similar multi-sig setup would provide the necessary checks and balances that institutional users expect

Committed. 2-of-3 Gnosis Safe on Rootstock, live from mainnet day 1, holding the Factory owner and Guardian roles, with my seat on a hardware wallet. Who holds the other two is an open question I put to the thread in the consolidated reply; if you have candidates in mind, name them there please.

On risk disclosure:

A clear “No-Patch Policy” document would be a valuable addition to your evidence pack for delegates to review.

The No-Patch Policy will be public before I submit the RFC. I sketched what it covers in section 2 of the main reply, and it will include the redeemInKind correction I conceded to @Curia.

[NeznaniJunak]

@Curia.

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.

You are right and I oversold it. What redeemInKind actually neutralizes: a broken exit path, a dark adapter freezing the vault’s accounting view, venue-side pauses, exit-path griefing; any case where the venue interaction, not the share math, is the failed component. What it cannot do: recover value from a drained venue. Those receipts are impaired or worthless, and nothing in the design changes that. One line I will keep though: a market sitting at 100% utilization is a different case. There redeemInKind is exactly the right tool: you exit the vault now, hold the receipts, and redeem as borrower repayments restore liquidity, earning the elevated rate meanwhile. KNOWN_ISSUES item 7 already documents that as the intended fallback. The venue-safety framing still comes out of the README and docs before the formal RFC; the honest sentence is that redeemInKind protects depositors from vault-level failures, and nothing in the design recovers a drained venue.

That’s the one risk nothing in the current design covers.

On lineage, one thing to fix before I concede the rest, and the mistake is in my own OP: I labeled both adapters Compound V2 forks there, which turned out wrong once I went back through the deployed contracts. LayerBank is actually an Aave V3 fork and Sovryn’s iTokens come from bZx, so a shared-fork bug taking out both venues at the same time is off the table. Your wider point survives anyway: the 60% cap does nothing about a bug inside either venue’s own code, and two venues is a thin base. What changes because of it: a utilization ceiling (around 90%) that keeps the vault from allocating into near-drained markets, in the code and in the audit scope; a third-adapter readiness check in the M4 report, plus I build one as soon as any protocol here clears the rubric (not promising a date when another team has to ship first); and the tracking list turns into a written quarterly rubric, so it stops being a vibe and becomes a document. The master post has the full detail in section 3.

On USDRIF: it is the most alive market on LayerBank right now, no argument there, and yes, the two-adapter minimum is what blocks it. That rule stays hard. A single-venue vault is just a wrapper that adds my code as an extra risk layer on top of one protocol, and the whole pitch here is diversified exposure. The moment a second venue lists USDRIF it becomes eligible under the same rubric, and it would likely be the first asset I bring to the multisig.

On the market data: thank you for pulling the live numbers. I am adopting them in the proposal with credit. You read the asset question the same way I do: the pilot runs on rBTC because it is the cheapest mainnet viability test, but the demand case and the TVL targets are DOC.

On whether ~$860K of addressable DOC justifies Strategic-tier scope, since you asked both halves: the scope is sized to the deliverables, and the same point I made in the master applies here, almost everything the grant pays for outlives DOC. If the DAO reads the tier differently, that is a legitimate call for it to make, and the 90-day table exists so that call gets made on stated numbers.

immutable also means no patch. If the audit misses something, no one can pause or fix it.

Agreed, and depositors should get that in writing. The No-Patch Policy is one of the pre-RFC deliverables now, outline in the master post section 2, and the redeemInKind correction above goes into it too. On the Guardian key itself, the Factory and Guardian roles move to a 2-of-3 Gnosis Safe from mainnet day 1, with seat composition an open question in the master post. Your 90-day TVL ask is answered there as well, one bear/base/bull table with assumptions, built on your numbers.

[NeznaniJunak]

@PGov thank you, in particular for this line.

the LOI gate on the RFC is the strongest structural choice in this whole proposal

That was the intent. Claiming demand in a thread is easy. Getting a wallet team to put a signature on it is not, and the RFC does not go up without one.

whether it just confirms the system runs without confirming there is a market

You are right that the 0.5 rBTC cap cannot prove a market, and it is not asked to. The demand proof lives in the LOI, the Phase 1 open cap and the M4 targets, measured against the BEAR floor in the master reply. The 0.5 rBTC cap was never meant to carry it.

What the cap does buy is material for the LOI conversation itself. An integrator deciding whether to sign can point at live deposits, rebalances and withdrawals on mainnet, plus a public dashboard, instead of testnet claims. On the asset choice: rBTC got picked for the pilot because it is the cheapest thing to test on mainnet; every demand number in the proposal is DOC.

a solo developer personally absorbing a cost overrun on a five-figure audit is not a stable foundation for a grant program

Agree completely. The master reply, section 1, lays out two structures for the audit engagement and asks the DAO to pick one. Under neither of them am I underwriting a five-figure delta.

On your two conditions for a formal RFC: both are already commitments. The LOI gates the RFC itself, and the 90-day TVL table with stated assumptions and anchors sits in the master reply. If either is missing from the RFC document, that is a fair reason to vote it down.

[NeznaniJunak]

@SEEDGov thanks for the connect, appreciated. @tamlerner, I have the full email thread with compliance@ from 17 May. I can forward it as-is, or re-send the whole KYB package fresh to whatever channel you prefer, whichever is faster. Everything on my side is ready.

[DAOstar_gov]

@NeznaniJunak

asks the DAO to pick one. Under neither of them am I underwriting a five-figure delta.

On your two conditions for a formal RFC: both are already commitments. The LOI gates the RFC itself, and the 90-day TVL table with stated assumptions and anchors sits in the master reply. If either is missing from the RFC document, that is a fair reason to vote it down.

Hello @NeznaniJunak , I believe I saw a message that @tamlerner is OOO until July 17th. Apologies for the delay. When she returns to the office, we’ll make sure that she sees your message.

[NeznaniJunak]

Thanks for the update @DAOstar_gov , no rush. The 17th doesn’t block anything on my side, KYB just has to clear before the formal RFC. In the meantime I’ve started the integrator outreach.

[Curia]

@NeznaniJunak One more thing we’re curious about is how rebalance() actually reads the rates. Does it look at the current APY, or the rate you’d actually get once the vault’s own money is in?

The good rates here sit on really thin pools. DOC’s ~19.77% is on only ~$154K of LayerBank liquidity, so a decent-sized deposit drags that rate down just by entering. If the logic is chasing the headline number, it’s chasing something that mostly disappears the moment the money lands, and in practice the vault ends up just filling LayerBank to the 60% cap and earning whatever’s left, which is well below what the screen shows.

Does the rebalancer account for its own impact on the rate, and does it count the incentive rewards as part of what it’s comparing, or leave them out?

[NeznaniJunak]

@Curia.

Which rate it reads: the spot one. getRate() returns the venue’s current supply rate straight from the protocol, LayerBank’s currentLiquidityRate and Sovryn’s supplyInterestRate, both at present utilization. It does not model the rate after the vault’s own deposit lands, so it doesn’t price its own impact, as you said. That spot number is only a selection input. The rebalance switch fires when bestRate > currentRate + rateThreshold and _sortedSaneAdapters ranks venues by it, and that is all it is used for. What reaches the share price is the real on-chain balance delta the vault checkpoints against the adapters, vested linearly over 3 days. The price can lag actual earnings, it never runs ahead of them. No modeled or projected rate ever touches it.

The incentives are where your LayerBank example changes: the contract can’t see them. currentLiquidityRate is the base lending rate, borrow interest times utilization times (1 minus reserve factor), nothing else. The liquidity mining that lifts the screen number to the ~19.77% you cited is paid through a separate rewards path, one the reserve’s interest accounting structurally excludes, so it never enters what getRate() reads. I pulled the DOC reserve just now and the base currentLiquidityRate is about 2% right now, roughly a tenth of that headline. The vault ranks on the base rate only and has no way to chase the boosted number.

On “fills LayerBank to the 60% cap”: half right. Allocation is a rate-ordered waterfall with a per-venue cap. It sorts venues by base rate high to low, fills the top one to the 60% cap (adapterCapBps = 6000), then spills the remainder to the next. With two adapters and a 60% cap that is a structural 60/40. So yes, the higher-rate venue gets filled to 60% and the other ~40% always sits in the lower-rate one, by design. The rate decides nothing except the fill order. Where filling stops is the cap.

Reading spot instead of marginal means a large deposit into a thin pool realizes less than the rate it compared against, because its own arrival lowers utilization and the rate with it. What bounds that today:

• the 60% cap bounds concentration, it doesn’t eliminate it. 60% into a thin market is still real exposure, and the cap only binds at allocation time; holdings can drift past it between rebalances.
• the allocation logic is immutable, no setter and a fixed adapter set, so I can’t retune it on a live vault.
• a utilization ceiling that refuses allocation into markets already near fully borrowed, which is where the spot-versus-realized gap is worst. That one is not in the deployed bytecode yet. It is a commitment I am putting in before the Phase 0 deploy, and it has to go into both vault contracts because the rBTC and ERC-20 vaults are separate code. Nothing is live on mainnet yet, so the audit reviews it with everything else and it is in the audited bytecode before any funds move. Nothing gets bolted on after.

On scale: Phase 0 is the rBTC vault only, 0.5 rBTC cap. The two rBTC pools it touches hold roughly 20 (LayerBank) and 29 (Sovryn) rBTC supplied right now. The whole cap is about 2-3% of a single pool, and with the 60% per-venue limit any one venue takes at most ~1.5% of a pool. At pilot scale the utilization move is minor. It grows with TVL. But this is the rBTC pilot, and the DOC market you are looking at is a different deployment entirely. DOC is not in Phase 0. A DOC vault would come later, with its own DOC-denominated cap, and a thin DOC market is where I would want that utilization ceiling in from day one.

Modeling the post-deposit marginal rate is a fair improvement. On an immutable vault it can only go into a future deployment. This one has no knobs.

[NeznaniJunak]

Milestone update, and a question for the delegates who raised the LOI gate.

Blockscout signed a Letter of Intent for the integration between their Rootstock Global Wallet and the vault. I wired their Global Wallet SDK into the vault demo, so Global Wallet users can connect and use the vault through the standard wallet flow. I ran the full flow on Rootstock testnet with an external wallet connected through their Global Wallet: connect, deposit, withdraw, all mined. Tx links and the repo are in the letter. Once the vault is on mainnet after the audit, the same integration is expected to carry over so their users can deposit for real.

The letter also notes Blockscout supports apps integrating the Global Wallet SDK and is open to technical guidance. It is non-binding by nature. I read it as the integration being real and on record, not a promise of listing or volume.

Disclosure, since it matters here: Blockscout is also a RootstockCollective grantee (Global Wallet, grant 2512). I did the integration work myself. Dosh, their wallet integration liaison on that grant, reviewed and signed on Blockscout’s side. No money moves in either direction and neither of us touches the other’s grant vote. Posting this on both threads for transparency.

The signed PDF is attached, with Blockscout’s e-signature audit trail from their blockscout.com address. Also pinned on IPFS, where the CID is the file’s own hash so anyone can check it is unaltered: https://ipfs.io/ipfs/bafkreicur2zjc2skw5pkvewbh6g3dfnqehryb4vvzbb4hzznjk64tymue4

My question, @PGov @Kaf_Anode @ChronoTrigger, since the LOI gate came up directly in what you asked: does a signed LOI from a named integrator, with a working and verifiable integration behind it, meet what you had in mind for the demand gate? My read is it clears the named-integrator bar. The stronger signal, a wallet featuring it to users and real deposits, comes as the vault hits mainnet and more integrators land. I don’t want to assume the answer, so I’m asking you.

@tamlerner, same question from the guidelines side: the V3.2.2 demand-validation gate is where the named-integrator LOI comes from, so does this clear it at the application stage?

Thanks to the Blockscout team, @dosh especially, for moving fast on it.