[2609 Grant] Rootstock Yield Vault: immutable ERC-4626 rBTC vault across LayerBank and Sovryn

Grants & Incentives
1

What this vote approves. Strategic tier, USD 25,000 in USDRIF, four on-chain milestones: 5,000 / 10,000 / 2,500 / 7,500. Initial tranche 20%, terminal tranche 30% after a post-completion impact review. The money pays a fixed-price audit at cost and ninety days of audited mainnet operation of an immutable rBTC vault. No further tranche is requested if any gate fails.

Classification: Strategic tier, DeFi / yield infrastructure.
Sanity-check thread: Idea/Sanity Check: Multi-Protocol ERC-4626 Yield Vault for Rootstock, Strategic-tier pre-RFC walkthrough (26 posts, June to September). Where this proposal differs from the opening post there, this proposal governs. The differences are listed in the Differences section.

Summary

An immutable ERC-4626 vault for rBTC that deposits into the LayerBank and Sovryn lending venues, rebalances permissionlessly between them, and cannot be paused, upgraded or patched after deployment. The code is frozen at tag audit-2026-07, the audit firm is selected and its terms are published on its own site, KYB is complete, and a signed integrator LOI is attached. USD 15,000 of the grant is a pass-through to Coinspect at cost. USD 10,000 pays for two mainnet deployments of the audited code, a 60-day capped Phase 0 with public pass/fail gates, ninety days of reporting, and handover. USD 7,500 of that is withheld until a day-90 TVL floor is met and the impact review is done.

Founder

Ivan Ursulović, solo developer. Backend and web3 engineer at DeGenerous DAO (Solidity governance contracts, NFT staking, on-chain/off-chain backend for CoNexus). Before that the Gno.land Student Contributor Program (smart contracts and tooling in Gno), LotusFlare (telecom MVNE orchestration) and TeleTrader (C#/.NET financial-data microservices). Rootstock Builder Rootcamp / Hacktivator Cohort 1. This vault was the capstone.
GitHub: Ursulovic (Ivan Ursulovic) · GitHub. LinkedIn: https://www.linkedin.com/in/ivan-ursulovic/. Forum: @NeznaniJunak.

No team beyond me. The continuity model is built for that: immutable contracts, permissionless rebalancing, an in-kind exit that needs nobody’s permission, and a handover that does not depend on me (see Trust model).

Traction

Testnet vault live on Rootstock testnet since June 2026, Blockscout-verified. External-wallet deposits and withdrawals through the Blockscout wallet on chain: deposit 0xdc21ad33703a2e8797771d1d4c4cc04f7a350c0312b0e467b75932a80b45f239 (block 7841689), withdrawal 0xa6f314259e36d71d391522bec43f1f29935b7aa32d7c31085b42fe151a8772b5 (block 7841699). Repository public with 256 local tests, 9 stateful invariants and Halmos symbolic proofs, frozen at tag audit-2026-07. LOI signed by Blockscout. Audit firm selected with a fixed-price quote published on the firm’s own site.

Media and resources

Demand validation (V3.3 Section 3.1)

Named integrator LOI: Blockscout, letter dated 10 July 2026, e-signed by Dosh (Blockscout) on 13 July 2026, non-binding, archived on IPFS, where the CID is the file’s own hash: https://ipfs.io/ipfs/bafkreicur2zjc2skw5pkvewbh6g3dfnqehryb4vvzbb4hzznjk64tymue4. The integration is not a plan: the vault’s deposit and withdrawal paths have run end to end through the Blockscout wallet on Rootstock testnet, hashes in Traction. The embedded email-wallet path does not work on testnet because the Blockscout wallet service signs against mainnet RPC. That is on their side and does not affect the external-wallet path.

Depositors are reached through three routes: the Blockscout wallet surface; this forum and the Collective’s channels; and direct deposits from Rootstock builders who put in their own funds.

Why rBTC first, when the deeper organic lending demand on Rootstock is in DOC, as @Curia’s numbers in #8 showed: rBTC is the deployment path that is audited, frozen and deployable inside this grant. The DOC vault is separate code and is sequenced after it (see Scope boundary). The rBTC vault’s demand case is distribution, not yield: a wallet-reachable, immutable, audited place to hold rBTC that earns the venues’ rate with no operator in the loop.

Prior security incident disclosure (V3.3 Section 8)

None. No incident on any chain involving me, this codebase, or a codebase it extends. Pre-audit findings from my own review and from an unsolicited automated preview by one bidder are tracked in KNOWN_ISSUES and are in the audit scope. None involved live funds.

Product

What it is. A single-asset ERC-4626 vault, ryRBTC, over native rBTC. Deposits are wrapped to WRBTC and placed into up to two lending venues, LayerBank (an Aave V3 fork, verified on chain) and Sovryn (bZx-lineage iTokens), through thin adapters behind one interface.

The rebalancer, with its numbers. Anyone can call rebalance(). The caller is paid 1% of the realized profit since the last call, under a 5% ceiling that is fixed in the code. Profit vests over three days, so a rebalance cannot pay out on paper gains. Calls are rate-limited to one per hour and only execute when the rate difference between venues is above 0.05% APR. No venue can hold more than 60% of assets, and no deposit enters a venue above 90% utilization, though exits are never blocked by that check. The rebalancer reads each venue’s spot base supply rate and ignores incentive tokens. All of these are immutable values in the audited bytecode.

What it is not. No admin keys, no upgrade path, no pause, no fee switch, no parameter changes after deployment. Anything wrong after deployment is remediated by fork and migrate, documented in NO_PATCH_POLICY.

Exits. withdraw and redeem pull from venues as needed. redeemInKind burns shares and hands the depositor their proportional share of each venue’s receipt tokens directly. It does not depend on any venue’s withdrawal path working. Entry paths are fail-closed when an adapter view breaks. Exit paths are fail-open.

Phase 0 hardening, merged and in audit scope: an immutable tvlCap constructor parameter enforced through maxDeposit and maxMint, and try/catch around every adapter call in totalAssets and redeemInKind (closes KNOWN_ISSUES item 6). A latent profit-vesting accounting issue found in my own review after the testnet deployment is fixed at the audit tag. The testnet bytecode predates the fix, which is one more reason Phase 0 runs on fresh audited bytecode rather than the testnet contracts.

Testing at the tag, from the README: 256 local tests (unit and function-level fuzz), 9 stateful invariants at 128k randomized calls each, Halmos symbolic proofs for the rate and utilization filters, the reward clamp and the donation guard, and mainnet-fork tests against the live venues. Regression tests are mutation-verified.

Lineage note, correcting the opening post. In the opening post of the sanity-check thread I called both venues Compound V2 forks. LayerBank on Rootstock is an Aave V3 fork and Sovryn’s iTokens are bZx lineage, so one shared-fork bug cannot hit both venues at once. The blast radius of a single venue bug is still bounded only by the 60% cap and the in-kind exit.

Trust model

  • rBTC vault: no privileged role at all.
  • 2-of-3 Gnosis Safe on Rootstock. I hold one seat on a hardware wallet. The other two seats are the Collective’s to nominate, delegates or Foundation, as offered in #11. I deploy whatever the Collective settles on. The Safe is created when two signers besides me are confirmed. In this grant the Safe has one job: it receives the M4 operator handover (runbook, dashboard access, monitoring), so continuity does not depend on me. Until the Safe exists, the handover goes to the Foundation contact named in the grant agreement, and the Safe receives a copy when it exists. No milestone waits on the nominations, and the Collective can replace either seat later by asking in this thread. The Factory-owner and ERC-20 Guardian roles described in #11 bind to the same Safe when the DOC deployment ships under its own review. Neither role exists in this grant’s deployment.
  • Third venue: the quarterly re-scan rubric from #11 stands (about USD 250,000 TVL, an independent audit, code lineage independent of both existing venues, the Safe authorizes the add). No Rootstock protocol passes it today. The M4 report carries a readiness assessment against it.

Security review

Firm: Coinspect. Terms as published on their site (link above) and in #23: a one-week fixed-scope, fixed-price engagement, two senior auditors, USD 15,000 all-in with a Rootstock ecosystem discount, scope pinned to audit-2026-07 (YieldVault, both native adapters and their interfaces, deploy script and constructor parameters), one fix-review round within ten business days of fixes being ready, a re-issued report naming the post-fix commit hash, report publishable unredacted and hostable by the DAO, valid through 30 November 2026, engagement slot in October or November 2026. Any finding that forces a material architectural change is quoted separately before extra work starts, and that quote comes back to the forum before anything is signed.

Why this firm: the only bidder that pinned to the frozen tag and read KNOWN_ISSUES before quoting; prior audits of Sovryn’s lending contracts (December 2020, the iToken surface this vault reads) and of the RIF token; eight published audits of Exactly, a live ERC-4626 lending protocol. When I gave them my budget, they declined to stretch the full system into it, on the grounds that the review would be diluted.

Comparison, as committed in #22. I asked four firms for quotes on the same scope document and tag. Three quoted. Names and prices of the other firms are withheld because they did not give permission to publish.

Coinspect Firm B Firm C Firm D
Reduced-scope price USD 15,000 under half under 90% no quote
Engagement length one week, two seniors three days quoted, two seniors; total or per auditor never clarified not stated, asked three times
Pinned to tag audit-2026-07 yes no, repository URL only no, wrong commit
Read scope document and KNOWN_ISSUES before quoting confirmed not confirmed partly, one automated preview
Fix review included yes, one round yes, one round yes, one round
Report publishable, DAO may host yes, in writing yes, in writing not addressed
Payment terms stated yes yes absent
Slot in October or November yes lapsed August slots only none given

For a vault that cannot be patched after deployment, the cheaper bid is not the better deal.

Full-scope reference. Coinspect’s published proposal prices the full system of roughly 1,360 nSLOC, including the ERC-20 vault, factory and extra adapters, at USD 25,000 over about 1.5 weeks. That review is not in this grant (see Scope boundary).

Scope boundary

This grant funds the rBTC deployment path and nothing else: the audit of that path, its two mainnet deployments, Phase 0, ninety days of operation and reporting, and handover.

@DAOstar_gov and @Curia, this walks back what I said in #11 about anchoring the grant to DOC. The DOC vault is written and tested at the same tag: a different vault contract with an ERC-20 money flow and a pause-only Guardian, two further adapters and a factory, together about 690 nSLOC, with its own unit, edge-case and mainnet-fork tests. It reuses the audited allocation logic but not the audited bytecode. The commitment from #19 that nothing unaudited touches mainnet holds, and the rBTC path is the one that is frozen and quoted. The code is written and tested, with no testnet instance. What the DOC vault is missing is an independent review, and every dollar of that review goes to the auditor and nothing to me. The guidelines make an audit mandatory at this tier, and the Collective has said it is not setting up an audit fund for now (@tamlerner, guidelines thread, 3 July), so audit money comes out of the grant itself. A DOC review paid from this grant would add to the funding side of FES with nothing on the value side inside this grant. That is why this ask stays at USD 25,000 and the DOC review is not funded here. If the rBTC vault meets its gates, I will bring the DOC review to this forum as a separate proposal after day 90, sized to the quote at that time, with the audited core, the report and the live numbers behind it. Whether to fund it is the Collective’s call. If the rBTC vault does not meet its gates, the DOC vault does not ship. Coinspect’s published full-scope price is the reference for what that review costs with the same team. Their quote runs to 30 November 2026, so that proposal would carry its own quote.

The rBTC venues at posting, read from the venues’ own contracts on 10 September 2026, re-read at every snapshot:

Venue rBTC supplied Utilization Base supply rate
LayerBank (WRBTC market) 24.4 rBTC 1.6% 0.0025% APR, incentives excluded
Sovryn (iRBTC) 27.6 rBTC 28% 0.92% APR

A 0.5 rBTC Phase 0 instance and a 5 rBTC post-Phase-0 instance sit inside that depth. The M4 metric below is defined on the deployments this grant funds, not on DOC. That changes #11.

Deployments and the cap

The tvlCap parameter is immutable, so the cap is never changed on a live vault. Two instances of the same audited bytecode, at the same post-fix commit:

  1. Phase 0 instance, cap 0.5 rBTC, deployed first. It stays capped for life.
  2. Post-Phase-0 instance, cap 5 rBTC, deployed only after every Phase 0 gate has passed. That is ten times the Phase 0 cap, and below the depth of either venue today. Anyone may move from the first instance to the second. Exits are always open, and the first instance keeps running for anyone who stays.

Both parameter sets go into the deploy script at the post-fix commit, so Coinspect’s re-issued report covers both configurations. If the second instance fills, a third instance is not automatic: its cap is a configuration the re-issued report does not cover, so it is a new deployment and a new proposal.

Risks

The vault is a router. If LayerBank or Sovryn loses funds, the vault loses its share of that venue and nothing else. The 60% per-venue cap bounds it. redeemInKind lets a depositor pull their proportional share of whatever receipt tokens still transfer. Sovryn pauses per function and iRBTC keeps transferring, while a full LayerBank reserve pause blocks its aToken and that slice is skipped and forfeited, as KNOWN_ISSUES item 5 records. redeemInKind cannot recover what a venue has lost. Sovryn’s iToken surface, the one this vault reads, had a USD 1.1 million exploit in October 2022 on legacy code that the 2020 audit had treated as out of scope. That is why this engagement’s scope is the whole rBTC deployment path, pinned to one tag. If a venue is sunset during the grant, its slice is bounded by the 60% cap, and exits from it run through the normal withdrawal path or, if that path is closed, through redeemInKind. The rebalancer does not evacuate a venue on its own: it moves funds only when the best rate beats the active venue’s rate by 0.05%. New deposits go to the other venue up to the cap, and the remainder stays idle in the vault if the sunset venue no longer accepts deposits. Nothing in this grant pays for a third adapter. The M4 readiness assessment says whether one is worth a separate proposal. Still-vesting profit stays behind on an in-kind exit, and an adapter that reverts can delay a normal withdrawal for as long as it keeps reverting. Both are documented in NO_PATCH_POLICY.

Grant request and milestones

Total USD 25,000, requested in USDRIF, one on-chain proposal per tranche. The 30% terminal tranche follows V3.3 and releases after the post-completion impact review.

Thread name On-chain milestone Amount Releases on Deliverables and evidence
M1a Milestone 1 USD 5,000 (20% initial tranche) execution of the Milestone 1 on-chain proposal, with the Coinspect SOW signed and an audit start date scheduled SOW executed (private); start date scheduled by Coinspect in writing; Coinspect’s proposal page (public)
M1b Milestone 2 USD 10,000 delivery of Coinspect’s initial audit report report published unredacted in the repository and hostable by the DAO
M2 Milestone 3 USD 2,500 Phase 0 gates met, day 60 or later after the Phase 0 deployment all critical and high findings closed and re-reviewed by Coinspect; re-issued report naming the post-fix commit; any medium or low finding left open listed with the reason; Phase 0 instance deployed at that exact commit, Blockscout-verified; Phase 0 gates (below) met, with the weekly invariant workflow runs public; integrator package published: the client code used in the Blockscout integration, the ABI and address manifest, and the exit playbook that walks a depositor through redeem, redeemInKind and what each one recovers
M4 Milestone 4 USD 7,500 (30% terminal) day 90 after the Phase 0 deployment, then the post-completion impact review that V3.3 attaches to the terminal tranche post-Phase-0 instance, 5 rBTC cap, deployed at the same post-fix commit, Blockscout-verified; TVL floor (below) met at the day-90 snapshot; final report with the metrics (below); public dashboard; operator runbook and monitoring handed over; third-venue readiness assessment

M1a plus M1b is USD 15,000, Coinspect’s fee, invoiced at cost. If the final invoice is below USD 15,000, that total shrinks to the invoice. The remaining USD 10,000, M2 and M4, is all my work. In rough shares: remediation and re-review handling, a quarter; both deployments, Phase 0 operation and the weekly invariant runs, a third; the dashboard and the integrator package, a quarter; documentation, runbook, monitoring handover and the final report, the rest. Hardening already merged is not billed. M2 and M3 from the opening post are merged into one milestone because neither could release before Phase 0 ends, and a separate on-chain vote for half of USD 2,500 serves nobody. M4 keeps its name because the sanity-check thread refers to it by that name. I receive nothing between the audit report and day 60 after deployment, by design.

If any Phase 0 gate fails, I do not request another tranche. Tranche release is the DAO’s call at every step.

Phase 0 gates

The Phase 0 instance, 0.5 rBTC cap, on the audited post-fix commit. All of the following, measured at weekly snapshots and published on the dashboard:

  • Minimum duration: 60 days.
  • Depositor gate: at least 10 depositors holding at least 0.001 rBTC each at the assessment snapshot, with distinct funding sources (no shared upstream EOA within 7 days of first deposit), and no single depositor above 40% of TVL at any weekly snapshot.
  • Zero critical incidents: no loss of depositor principal beyond ERC-4626 rounding tolerance, no withdrawal blocked more than 24 hours, no reproducible invariant break on mainnet state, no unauthorized state mutation. The pinned invariant suite runs as a public GitHub Actions workflow against a mainnet fork at each snapshot block; anyone can re-run it.

My own deposits, and deposits from any wallet I control or fund, count toward neither the ten depositors nor the M4 TVL floor. The wallets I control are listed on the dashboard.

Performance targets and success metrics

This section answers @LEGOSI’s five questions in #26 and the FES requirement for the Strategic tier in V3.2: 2.0× ecosystem value over funding, measured twelve months after funding. On this grant that is USD 50,000 of measured ecosystem value by month twelve. FES counts TVL attracted and retained, new wallets, transaction volume and DAO engagement. It does not count revenue.

  1. 90-day TVL target. The payment gate is the BEAR floor from #11: USD 10,000 equivalent across the two audited rBTC instances at the day-90 snapshot, BTC/USD at the CoinMarketCap daily close. The targets stay as in #11: BASE USD 50,000 to 150,000, BULL USD 250,000 to 400,000. The BEAR floor is a payment gate at day 90, not the FES measurement, which runs to month twelve. On TVL alone, the BASE lower bound of USD 50,000 sits on the 2.0Ă— line with no margin. BEAR is 0.4Ă—. That is why BEAR gates USD 7,500 and BASE is what the integration is built to reach. The second instance deploys after the day-60 gates pass, so at the day-90 snapshot it has about thirty days of history. The floor is measured across both instances anyway. If the Collective prefers to measure the second instance at its own day 90, say so in this thread and I will move the snapshot.
  2. Organic (direct) versus integrator-routed, and net-new versus rerouted. Every deposit is tagged on the dashboard as integrator-routed (through the Blockscout wallet surface) or direct. Each deposit is also tagged net-new or rerouted: rerouted means the same wallet withdrew rBTC from LayerBank or Sovryn in the 30 days before depositing. All four totals are reported at each snapshot. No target is set for the routing split: an integrator-routed deposit is the product working. The FES TVL component is the vault’s TVL either way. The split is there so nobody has to ask.
  3. Retention and recurrence. Reported at day 90, with targets, not as payment gates: at least half of the Phase 0 depositors still hold shares in either instance; at least half of day-90 TVL has been in the vault for 30 days or more; the number of wallets with two or more deposits; wallets with repeat on-chain activity over 30 days, the V3.3 anti-gaming definition. The M4 gate is the TVL floor plus the qualitative deliverables, with no retention metric added, because a retention gate on a dozen wallets would pay or withhold USD 7,500 on noise.
  4. If the integrator route underdelivers. The LOI is evidence of integrator demand at the time of application. The gates do not depend on that route staying available. The Phase 0 depositor gate and the M4 TVL floor are measured on chain regardless of which route deposits come through. If the floor is not met, M4 is not requested, whatever the reason.
  5. Split of the USD 25,000. USD 15,000 audits the reusable core, the vault design and adapter pattern every later deployment inherits. USD 10,000 delivers the rBTC deployments and their ninety days. USD 0 goes to the DOC deployment in this grant.

Value Commitment Plan (V3.3). Target at month twelve: USD 50,000 or more of TVL attracted and retained across the audited rBTC instances, read from chain by the FES Dashboard, not self-reported. New wallets, transaction counts and stRIF activity from vault depositors are reported monthly from the deployment on, and count toward FES under whatever weighting the Collective publishes; they are not projected here because no weighting is published.

Monthly Activity Reports on this forum between milestones, as V3.2 requires, with TVL delta, transaction count, new wallets and the metrics above.

Payment rail and wallets

Tranches are paid in USDRIF to 0x84f04C662A9973cBdb8d85928F0871640569f29C, the wallet named in the executed grant agreement, the same wallet for every tranche. I submit the on-chain proposals from a separate operational wallet that holds the stRIF; the transfer address in each proposal is the wallet above.

Coinspect invoices in USD, 50% before the audit starts and 50% on the initial report, settled in USDT or USDC on Ethereum. The DAO releases tranches after a seven-day vote and a three-day timelock. If the Collective’s audit-funding workstream reaches a direct-to-auditor rail before Milestone 1 executes, I would rather use it than bridge. That is the rail the Foundation said it leans toward, tied to audit-readiness rather than the initial tranche (@tamlerner, guidelines thread, 3 July). Until then, the fallback stated in #25 stands: the M1a tranche covers USD 5,000 of the USD 7,500 deposit; at SOW I ask for a USD 5,000 / USD 10,000 split; if Coinspect declines, I bridge USD 2,500 from the deposit until M1b, once and at this size. The second installment lands roughly two weeks behind its invoice. Pinning that alignment in the SOW is the one thing still open with Coinspect. Conversion from USDRIF to the auditor’s settlement currency, and its fees, are my cost.

Timeline

Approximate, gated on votes I do not control.

  • September to October 2026: this proposal, community discussion, Initial AMA.
  • October 2026: on-chain vote, SOW, execution, audit start (Coinspect slot: October or November).
  • November 2026: initial report (M1b), fix batch, fix review, re-issued report at the post-fix commit.
  • November to December 2026: Phase 0 deployment at that commit, Phase 0 starts.
  • Day 60 after deployment: Phase 0 gates assessed, M2 requested if met, post-Phase-0 instance deployed.
  • Day 90 after deployment: M4 snapshot, final report, handover, impact review. M4 requested if met.

Coinspect’s terms hold through 30 November 2026. A slip past that reopens the quote. The on-chain vote and the SOW fit inside that date on this timeline.

KYB

Complete. The grant agreement was fully executed on 4 September 2026 (individual applicant).

Reporting, obligations, and after day 90

Monthly Activity Reports during the grant, milestone AMAs, the final retrospective AMA, and the twelve-month ecosystem obligation in V3.2, accepted.

After day 90 the vault needs nobody. It cannot be paused, upgraded or drained by an operator. The dashboard, the monitoring and the weekly invariant workflow stay up through month twelve so the FES numbers can be read by anyone. I will not ask this DAO for a maintenance grant for this deployment. If a corrected version is ever needed, it is a new deployment and a new proposal. The audit report, runbook and dashboard stay public after the grant.

How the Collective can help

If the audit-funding workstream reaches a direct-to-auditor rail before Milestone 1 executes, tell me here and I will use it. Separately, the Safe needs two signers besides me, delegates or Foundation. If you want a seat or want to nominate someone, say so in this thread.

Differences from the opening post and the sanity-check thread

  • Audit firm and terms: fixed (#23, Coinspect page).
  • M1 restructured to match the audit at cost, M1a USD 5,000 / M1b USD 10,000 (#23).
  • M2 and M3 merged into one USD 2,500 milestone releasing after Phase 0. The integrator SDK from #11 ships inside it as the integrator package, the exit playbook stays (this proposal).
  • Phase 0 gates bind M2 and M4, not M1 (#23). Per-depositor minimum (0.001 rBTC, held at the assessment snapshot) added to the depositor gate. Wallets I control or fund excluded from the depositor count and from the M4 TVL floor (this proposal).
  • Two deployments of the same audited code: Phase 0 instance at 0.5 rBTC, post-Phase-0 instance at 5 rBTC (this proposal).
  • Safe timing: #11 put the 2-of-3 Safe live from mainnet day 1. This grant’s deployment has no Factory-owner or Guardian role for it to hold, so the Safe is created when two signers besides me are confirmed and its only job here is the M4 handover (this proposal, changes #11).
  • M4 TVL floor defined on the rBTC deployments, not DOC (this proposal, changes #11). M4 releases after the V3.3 impact review.
  • DOC deployment out of this grant’s funded scope, sequenced after ninety days as a separate proposal (this proposal, #23 promised the RFC would state how it is funded).
  • Personal underwriting of audit overruns withdrawn (#11, #14). Extensions come back to the forum for a decision.
  • Lineage correction: LayerBank is an Aave V3 fork and Sovryn’s iTokens are bZx lineage, not Compound V2 (#11).
  • Denomination: USDRIF (V3.3). FES bar stated as the Strategic tier’s 2.0Ă— over twelve months.

Social

GitHub: GitHub - Ursulovic/rootstock-yield-vault: ERC-4626 rBTC yield vault on Rootstock. Adapter-based routing across LayerBank and Sovryn, permissionless rebalance. · GitHub. Forum: @NeznaniJunak. Telegram: @Ursulovic.

Rootstock - Governance at a Glance 26-10-06
Idea/Sanity Check: Multi-Protocol ERC-4626 Yield Vault for Rootstock, Strategic-tier pre-RFC walkthrough
3

Thanks @NeznaniJunak for the proposal. The technical side and milestone structure are clear, but I’m still not convinced by the economics.

The main question for me is whether a $25k grant is justified for an rBTC vault when the underlying lending yields are currently quite low. In that context, the value proposition seems to depend more on distribution and convenience than on yield itself.

I also think the final success threshold deserves another look. Releasing the last $7.5k at $10k TVL after 90 days feels relatively low compared with the total grant size. I’d like to understand why that is considered enough evidence of adoption.

And on Blockscout: beyond the LOI and testnet work, is there any stronger commitment around actually surfacing the vault to users on mainnet?

4

@Kaf_Anode, thanks. The three in order.

Economics. The venue rates are low. The proposal’s table has LayerBank at 0.0025% APR and Sovryn at 0.92%, read from the venues’ contracts on 10 September. No gate in the ask requires them to rise. USD 15,000 is Coinspect’s fixed fee, passed through at cost, for an unredacted report on the whole rBTC deployment path. Up to $10,000 is my work, two deployments and ninety days. It is the part gated on adoption: $2,500 on the Phase 0 gates, up to $7,500 on the day-90 number.

If the Phase 0 gates fail, M2 and M4 are never requested and the DAO has paid $15,000, all of it to the auditor; what it holds is that report, over code that stays public and frozen. If Phase 0 passes and the deposits stay small, M2 is $2,500 and M4 is nothing below $10,000 of TVL. The demand case is distribution, as the proposal says: a wallet-reachable, immutable, audited place to hold rBTC that earns the venues’ rate with no operator in the loop. Against a direct deposit into either venue, the audited code adds one ERC-4626 surface an integrator wires once, at most 60% of assets in any one venue, no admin key, no pause, no upgrade path, and redeemInKind as an exit that doesn’t depend on a venue’s withdrawal path working. The venues keep their own risks, listed in the proposal.

M4. You’re right. $10,000 was gating the whole $7,500 on a day-90 number the proposal itself puts at 0.4× of the grant, and that was wrong. The proposal edit, dated 16 September, is in the next post in full; my edit window on the opening post has closed, so that post is the edit record and governs where the two differ. Below $10,000 of TVL across the two audited instances at the day-90 snapshot, M4 is not requested. At or above it, the amount is $7,500 × TVL / $50,000, rounded down to whole dollars and capped at $7,500, so $1,500 at $10,000, $3,750 at $25,000, $7,500 at $50,000 or more. The divisor is $50,000 because that’s the BASE lower bound in the proposal. On TVL alone, that is also the point where the whole grant sits on the Strategic tier’s 2.0× line. TVL there is read from the contracts: share balances in both instances converted to assets at a named block, priced at the CoinMarketCap close for that UTC day. Wallets I control or fund are excluded. The block, the close, the per-holder figures and the arithmetic go into this thread before the on-chain M4 is filed, and the on-chain amount is that number. Anything not requested at M4 does not carry over to a later milestone. The 30% terminal tranche is still withheld until the impact review; only the amount released from it changes, and that release is a separate on-chain vote.

Blockscout. No. The letter and the testnet integration are all there is. I left the pilot’s end out of the proposal on 11 September; it’s in the edit, as a dated paragraph under Demand validation. Blockscout’s Global Wallet pilot ended with its final report on 29 July (t/679, post 43): they report challenges attracting dapps to the product, that they are winding the pilot down, and that funding the wallet’s ongoing costs is now the community’s call. The letter predates that report, it’s non-binding by its own terms, and I cannot promise the service stays up. The integration ran the vault end to end through a third-party wallet on Rootstock testnet, hashes in the proposal. The rBTC vault has no privileged role, and the integrator package under M2 publishes the client code, the ABI and the address manifest another wallet would need. Deposits come through three routes in the proposal: the Blockscout wallet surface while it runs, this forum and the Collective’s channels, and Rootstock builders who put in their own funds. No payment gate depends on any of them: the depositor gate and the day-90 TVL figure are read from chain either way.

If any of the three is still open, please say so here.

1 Like
5

Edits to the proposal, 16 September, after #3. My edit window on the opening post has closed, so this post is the edit record: the passages below replace the corresponding ones in the opening post, and where the two differ, this post governs. Two changes: the M4 amount is sized to day-90 TVL instead of all-or-nothing, with the wording that says how the day-90 figure is read and reported, and a dated paragraph on the Blockscout pilot goes under Demand validation. Nothing else in the proposal changes. In the passages below, #3 is @Kaf_Anode’s post in this thread; #11 and #23 are posts in the sanity-check thread linked in the opening post. Once the Milestone 1 on-chain proposal is filed, neither the opening post nor this edit record changes; anything after that goes in a reply, and each on-chain proposal’s text and amount match this thread.

Header block (the first paragraph)

What this vote approves. Strategic tier, up to USD 25,000 in USDRIF, four on-chain milestones: 5,000 / 10,000 / 2,500 / up to 7,500. Initial tranche 20%. The 30% terminal tranche is withheld until a post-completion impact review, and the amount released from it is sized to day-90 TVL (edited 16 September, after #3 in this thread). The money pays a fixed-price audit at cost and ninety days of audited mainnet operation of an immutable rBTC vault. No further tranche is requested if any gate fails.

Summary (the whole paragraph; the last two sentences change)

An immutable ERC-4626 vault for rBTC that deposits into the LayerBank and Sovryn lending venues, rebalances permissionlessly between them, and cannot be paused, upgraded or patched after deployment. The code is frozen at tag audit-2026-07, the audit firm is selected and its terms are published on its own site, KYB is complete, and a signed integrator LOI is attached. USD 15,000 of the grant is a pass-through to Coinspect at cost. Up to USD 10,000 pays for two mainnet deployments of the audited code, a 60-day capped Phase 0 with public pass/fail gates, ninety days of reporting, and handover. USD 7,500 of that is withheld until the impact review is done, and the amount released is sized to TVL at the day-90 snapshot: nothing below USD 10,000 of TVL, the full USD 7,500 at USD 50,000 or more.

Demand validation (V3.3 Section 3.1) (a new paragraph after the LOI paragraph, and the routes line)

Edited 16 September, after #3. The named-integrator evidence Section 3.1 asks for is the signed letter in the opening post, dated 10 July 2026. What has changed since: Blockscout’s Global Wallet pilot ended with its final report on 29 July 2026 ([2512 Grant 1] RootStock Global Wallet by Blockscout - #43 by AndrewG). The report says they faced challenges attracting dapps to the product, that they are winding the pilot down, and that funding the wallet’s ongoing costs is now the community’s call. The letter is non-binding by its own terms, and I cannot promise the service stays up; by that report, whether it does is a funding question for the Rootstock community. The rBTC vault has no privileged role and nothing gates who integrates it: the integrator package under M2 publishes the client code, the ABI and the address manifest another wallet would need. No payment gate depends on this route (question 4 under Performance targets).

Depositors are reached through three routes: the Blockscout wallet surface, for as long as it runs; this forum and the Collective’s channels; and direct deposits from Rootstock builders who put in their own funds.

Grant request and milestones (first paragraph, the M4 row of the milestone table, and the two paragraphs under the table)

Total up to USD 25,000, requested in USDRIF, one on-chain proposal per tranche. The 20% initial tranche and the 30% terminal tranche are percentages of the approved USD 25,000; a smaller M4 reduces what is drawn, not what was approved, and the month-twelve target stays USD 50,000 either way. The 30% terminal tranche follows V3.3: it is withheld until the post-completion impact review, and the amount released from it is sized to day-90 TVL, up to the full USD 7,500 (edited 16 September, after #3).

Thread name On-chain milestone Amount Releases on Deliverables and evidence
M4 Milestone 4 up to USD 7,500 of the 30% terminal tranche, sized to day-90 TVL, see Performance targets day 90 after the Phase 0 deployment, then the post-completion impact review that V3.3 attaches to the terminal tranche; the snapshot block, the close, the per-holder figures and the arithmetic go into this thread before the on-chain proposal is filed, and the on-chain amount is that number post-Phase-0 instance, 5 rBTC cap, deployed at the same post-fix commit, Blockscout-verified; TVL floor (below) met at the day-90 snapshot; final report with the metrics (below); public dashboard; operator runbook and monitoring handed over; third-venue readiness assessment

M1a plus M1b is USD 15,000, Coinspect’s fee, invoiced at cost. If the final invoice is below USD 15,000, that total shrinks to the invoice. The rest, up to USD 10,000 across M2 and M4, is all my work. In rough shares: remediation and re-review handling, a quarter; both deployments, Phase 0 operation and the weekly invariant runs, a third; the dashboard and the integrator package, a quarter; documentation, runbook, monitoring handover and the final report, the rest. Hardening already merged is not billed. M2 and M3 from the sanity-check thread’s opening post are merged into one milestone because neither could release before Phase 0 ends, and a separate on-chain vote for half of USD 2,500 serves nobody. M4 keeps its name because the sanity-check thread refers to it by that name. I receive nothing between the audit report and day 60 after deployment, by design.

If any Phase 0 gate fails, I do not request another tranche. Tranche release is the DAO’s call at every step. If M4 is not requested, the day-90 work is still delivered and still public: the final report, the dashboard, the operator runbook and monitoring handed over as the Trust model section of the opening post describes, and the third-venue readiness assessment. The dashboard and the weekly invariant workflow stay up through month twelve either way; only the payment is conditional (edited 16 September, after #3).

Phase 0 gates (the wallet-exclusion paragraph)

My own deposits, and deposits from any wallet I control or fund, count toward neither the ten depositors nor the day-90 TVL figure, which is the figure tested against the M4 floor and used to set the M4 amount (edited 16 September, after #3). The wallets I control or fund are listed on the dashboard and in this thread; the list in force at a snapshot is posted before that snapshot, and wallets are added to it, never removed.

Performance targets and success metrics (items 1, 3, 4 and 5; item 2 is unchanged)

1. 90-day TVL target. The payment floor is the BEAR figure from #11: USD 10,000 equivalent across the two audited rBTC instances at the day-90 snapshot. The snapshot block is the last Rootstock block of the 90th calendar day after the day of the Phase 0 deployment transaction, UTC, and the price is the BTC/USD CoinMarketCap daily close for that same UTC day. The figure is the sum of convertToAssets(balanceOf(h)) at that block over every share holder h in both instances, excluding wallets I control or fund; the holder list, the per-wallet figures and the arithmetic are published with it. The targets stay as in #11: BASE USD 50,000 to 150,000, BULL USD 250,000 to 400,000. The BEAR floor is a payment floor at day 90, not the FES measurement, which runs to month twelve. On TVL alone, the BASE lower bound of USD 50,000 sits on the 2.0Ă— line with no margin. BEAR is 0.4Ă— against the full USD 25,000. Edited 16 September, after #3: M4 is no longer all-or-nothing at the BEAR floor. Below USD 10,000 at the day-90 snapshot, M4 is not requested. At or above it, the amount requested is USD 7,500 Ă— TVL / USD 50,000, rounded down to whole USD and capped at USD 7,500: USD 1,500 at USD 10,000, USD 3,750 at USD 25,000, USD 7,500 at USD 50,000 or more. USD 50,000 is the divisor because it is the BASE lower bound above, the point where on TVL alone this grant sits on the 2.0Ă— line; above it more TVL adds nothing to the ask. The snapshot block, the close, the per-holder figures and the arithmetic go into this thread before the M4 on-chain proposal is filed, the on-chain proposal carries the same figure in its text and links that post, and the on-chain amount is that number. The snapshot is that one block: TVL moving after it does not change the amount in either direction. Whatever is not requested is not deferred to a later milestone. For the impact review, the targets committed on M4 are this rule and the deliverables in the M4 row above; the month-twelve Value Commitment Plan is measured at month twelve, after this grant closes. BASE is still what the integration is built to reach. The second instance deploys after the day-60 gates pass, so at the day-90 snapshot it has about thirty days of history. That figure, for the floor and for the amount alike, is measured across both instances anyway. If the Collective prefers to measure the second instance at its own day 90, say so in this thread and I will move the snapshot. That is settled in this thread before the Milestone 1 on-chain proposal is filed; after that, the snapshot rule does not move, because under a sized M4 moving the snapshot moves the amount.

3. Retention and recurrence. Reported at day 90, with targets, not as payment gates: at least half of the Phase 0 depositors still hold shares in either instance; at least half of day-90 TVL has been in the vault for 30 days or more; the number of wallets with two or more deposits; wallets with repeat on-chain activity over 30 days, the V3.3 anti-gaming definition; the largest single holder’s share of the day-90 figure, and how much of that figure was deposited in the final seven days. The M4 gate is the TVL floor plus the qualitative deliverables, with no retention metric added, because a retention gate on a dozen wallets would pay or withhold up to USD 7,500 on noise.

4. If the integrator route underdelivers. The LOI is evidence of integrator demand at the time it was signed, in July 2026. The gates do not depend on that route staying available. The Phase 0 depositor gate and the day-90 TVL figure, which sets both the M4 floor test and the M4 amount, are measured on chain regardless of which route deposits come through. If the floor is not met, M4 is not requested, whatever the reason, and above it the amount follows that same on-chain figure (edited 16 September, after #3).

5. Split of the ask, up to USD 25,000. USD 15,000 audits the reusable core, the vault design and adapter pattern every later deployment inherits. Up to USD 10,000 delivers the rBTC deployments and their ninety days, with USD 7,500 of it sized to day-90 TVL. USD 0 goes to the DOC deployment in this grant.

Timeline (the day-90 line)

  • Day 90 after deployment: M4 snapshot, final report, handover, impact review. M4 requested at the amount the snapshot sets, if the floor is met.

Differences (two bullets)

  • Phase 0 gates bind M2 and M4, not M1 (#23). Per-depositor minimum (0.001 rBTC, held at the assessment snapshot) added to the depositor gate. Wallets I control or fund excluded from the depositor count and from the day-90 TVL figure that sets both the M4 floor test and the M4 amount (this proposal).

  • M4 TVL floor defined on the rBTC deployments, not DOC (this proposal, changes #11). M4 releases after the V3.3 impact review. M4 amount sized to day-90 TVL between USD 10,000 and USD 50,000 instead of all-or-nothing at USD 10,000 (edited 16 September, after #3).

6

I think the amount requested is relatively high considering the potential usage of the vault.

Both markets seem to have limited activity. In LayerBank, RBTC is primarily used as collateral, which makes me question how much demand there would be for an additional RBTC yield vault. And given the current situation with Sovryn, particularly the lack of responses from the team to users’ questions, I’m also not convinced that it is currently a clear option to rely on.

Beyond that, and going back to @Kaf_Anode’s earlier point, I’m still not seeing a sufficiently clear benefit to justify an investment of this size. I think the expected usage and value generated should be clearer before allocating this amount of funding.

7

Summary of the proposal

The proposal requests $25,000 in USDRIF to deploy an immutable ERC-4626 rBTC yield vault on Rootstock. The vault would route deposits between LayerBank and Sovryn based on lending rates, with permissionless rebalancing and no upgrade, pause, or administrative controls. The funding is divided into four milestones, with $15,000 allocated to the Coinspect audit and the remaining $10,000 covering deployment, Phase 0 operation, reporting, monitoring, and handover. The proposal also introduces a 0.5 rBTC capped Phase 0 deployment before a larger 5 rBTC instance.

Assessment: strengths and areas of concern

A major strength is the proposal’s emphasis on security and transparency. The code is frozen before the audit, the audit scope is clearly defined, and the proposal provides testing evidence, known issues, risk disclosures, and a no-patch policy. The milestone structure also reduces the risk of releasing the full grant before the product demonstrates real-world operation.

The use of two independent lending venues and the 60% per-venue exposure cap provide some diversification. The redeemInKind mechanism is also a useful consideration for situations where a venue’s normal withdrawal path becomes unavailable.

However, the immutable design introduces a significant trade-off. If an undiscovered vulnerability affects the deployed code, remediation requires a new deployment and migration rather than a direct fix. I think the proposal could make the migration process more concrete, particularly regarding how depositors would be protected and incentivized to migrate if a serious issue occurs.

Another area that could be strengthened is the demand validation. The Blockscout LOI and testnet activity provide useful evidence, but a non-binding LOI does not necessarily demonstrate sustained mainnet demand. Similarly, the $10,000 day-90 TVL floor is useful as a measurable gate, but it would be helpful to explain more clearly how this threshold was selected relative to expected organic demand.

Specific suggestions for improvement

  • Define a clear emergency migration procedure, including how users would be notified, how assets would be migrated, and what happens if the old vault contains impaired assets.
  • Provide a more detailed methodology for distinguishing genuine new users from users simply moving funds between Rootstock protocols, even though the proposal already introduces a rerouted/net-new classification.
  • Consider publishing a predefined response framework for venue failures, including scenarios involving LayerBank or Sovryn insolvency, prolonged withdrawal restrictions, or major rate manipulation.
  • Clarify the assumptions behind the $10,000 TVL floor and the month-12 $50,000 ecosystem-value target, particularly how these targets relate to the current liquidity available in the two venues.
  • For the solo-founder risk, make the proposed 2-of-3 Safe and operational handover a more explicit milestone or deliverable, rather than leaving its creation dependent on future signer confirmation.
  • Since the vault’s rebalancing mechanism pays the caller 1% of realized profit, provide monitoring metrics showing the actual cost of rebalancing versus the additional yield generated during Phase 0.

Overall, the proposal provides substantial technical and security detail. The main opportunity is to strengthen the operational and adoption assumptions around an immutable system, particularly migration, demand validation, and failure scenarios.

8

Adding to @Seviramar and @iamChekwube.

The filter shouldn’t be “does today’s APY justify $25k?”. LayerBank mostly uses rBTC as collateral and Sovryn has weak support right now — that explains low yields and skepticism toward a single venue. That’s exactly why dual-venue + 60% cap + redeemInKind matters more than the spot rate: it’s an exit when a protocol’s withdrawal path breaks.

Where we should push before voting:

  1. Emergency migration. If the vault is immutable and a critical bug shows up, how are users notified, who coordinates the fork/migrate, and what happens if assets are impaired in a venue? That needs a public runbook, not an intention.

  2. Demand. The Blockscout LOI is no longer enough (the pilot wound down). The real case is ERC-4626 distribution builders can integrate + deposits from builders/forum. Fine — then Phase 0 should prove net-new wallets, not just TVL recycled between LayerBank and Sovryn.

  3. M4. Good that it’s no longer all-or-nothing and scales with day-90 TVL. It’s still a soft adoption test; at least the day-90 report should show actual rebalance cost (1% to the caller) vs extra yield generated.

  4. Solo founder. The 2-of-3 Safe and handover can’t stay “when we have signers” — make them an explicit M2/M4 deliverable.

If those four are nailed in the thread (and in the milestones), we’re debating reusable infra. If not, we’re buying an auditor + a small TVL experiment.

9

Thanks for sharing such a detailed proposal.

I think the strongest point is that this vault tries to make rBTC productive without requiring users to manually compare and move funds between different lending venues. The permissionless rebalancing model and the phased deployment approach also make the concept easier to evaluate gradually instead of immediately exposing a large amount of capital.

From a user adoption perspective, however, I think the interface and communication layer will be just as important as the smart contracts.

For a normal rBTC holder, terms such as ERC-4626, venue utilization, adapter failure, in-kind redemption, and rebalancing incentives can be difficult to understand. I would suggest creating a very simple dashboard that clearly shows:

  • where the user’s rBTC is currently allocated,
  • the current net yield after relevant costs,
  • the risk exposure to each lending venue,
  • what happens if one venue becomes unavailable,
  • and the difference between a normal withdrawal and redeemInKind.

I would also like to see the project measure how many users actually understand and continue using the vault, not only TVL.

From a Japanese community perspective, a short visual guide or demo showing the complete user journey — deposit, yield generation, rebalancing, and withdrawal — would make this much easier to explain to new users.

Overall, I think the technical foundation is strong, but clearer user-facing risk communication and education could significantly improve adoption.

10

hey @NeznaniJunak, coming back to the question you asked me on the sanity check thread:

The demand gate. In July I’d have said yes, a signed LOI with a working testnet integration clears it. But two of the things that made me supportive back then have changed. The Blockscout pilot wound down (thanks for flagging it yourself), and DOC, which we all agreed was the real demand case, is now out of this grant. The BEAR/BASE/BULL targets are still the ones built on DOC numbers, just applied to rBTC now.

The rBTC yield math. With two venues and a 60% cap the split is always 60/40, so at your September 10 rates that’s roughly 0.55% blended, less than going to Sovryn directly. I also went through the repo at audit-2026-07 and couldn’t find any way for the LayerBank adapter to claim liquidity mining rewards, and @Curia’s June numbers had LayerBank’s rBTC yield as almost entirely incentives. Since the adapter is immutable, those rewards never reach depositors. Happy to be corrected if I missed it. The engineering and the Phase 0 design are still among the best we’ve seen here, but as scoped I’d have a hard time supporting $25K for an rBTC vault that earns less than its own venues.

1 Like
11

Since my last post on 16 September I let the discussion run and used the time to check every point raised here against chain data and against my own code. My decision is to pause this proposal before any on-chain step. I’m not asking for an AMA or a vote on it.

Below is what I checked and why it leads here. Venue figures are read at Rootstock block 9,275,849 (27 September, 10:19 UTC). The calls are listed at the end so anyone can re-run them.

Yield (@Kaf_Anode #3, @Seviramar #6)

rBTC supplied to lending venues earns close to nothing, and not only on Rootstock. On Aave v3 Ethereum, at block 26,068,186, WBTC suppliers earn 0.0033% APR while USDC suppliers in the same pool earn 3.58%. BTC is mostly posted as collateral and rarely borrowed. On Rootstock, over the last 96 days, suppliers realized 0.49% annualized in Sovryn’s rBTC pool and 0.04% in LayerBank’s. LayerBank’s WRBTC rate today (0.37%) moves with a Merkl campaign that rewards borrowing WRBTC and runs until 11 October.

The vault earns less than its venues (@ChronoTrigger #10)

Confirmed on all counts. With two venues and a 60% cap the split is 60/40, so the vault sits below the better venue by construction. On realized rates over the same 96 days that is about 0.31%, against 0.49% from depositing in Sovryn directly. And the LayerBank adapter has no code to claim incentives or turn them into rBTC, so depositors would never see them. I left claim and swap logic out on purpose, to keep the contract without an operator, and I never put a number on what that choice costs. You did.

Venue health (@Seviramar #6)

Checking your point about Sovryn, I found the part that decides this. Sovryn’s rBTC pool holds 27.62 rBTC of lender claims. One loan in it, opened in February 2022 and past its end date since November 2024, carries 3.67 rBTC of principal, 13.3% of all lender claims, against SOV collateral that Sovryn’s own price feed values at 0.17 rBTC. Liquidating it means paying 3.67 rBTC to receive that 0.17 rBTC, so nobody does, and the pool has no mechanism to write it off. The iToken price, which the vault would use to value its position, keeps counting the loan at face value. Sovryn’s DOC pool shows 12.38 DOC withdrawable against 622,684 DOC of lender claims.

Then my own code. The vault ranks venues by their displayed supply rate: Sovryn shows 0.92%, LayerBank 0.37%, so the waterfall would fill Sovryn to the 60% cap first. Sovryn’s displayed rate includes interest accruing on that 2022 loan, which is not being paid. The default allocation is the worst one the cap allows.

The demand case (@ChronoTrigger #10, @Kaf_Anode #3)

You’re right that the BEAR/BASE/BULL targets were built on DOC numbers: #11 on the sanity-check thread anchored BASE on “the entire LayerBank DOC market is about $135K today”. Between the sanity check in June and now, both places the DOC case rested on changed: Sovryn’s DOC pool stopped being withdrawable (27 August) and Tropykus closed (31 August). With DOC out of this grant and the Blockscout pilot ended, the demand case for the rBTC version rests on less than it did in July.

What this means

The vault is a router. It needs two healthy venues and a yield worth routing, and on Rootstock today there is neither. A smaller ask doesn’t change that. I also looked at rebuilding it as a DOC-only vault, since that is where the borrowing is. It has the same problem the other way round: there is one live stablecoin lending venue on Rootstock right now, and a vault over one venue earns less than depositing there directly. So I’m not going to ask the Collective to pay for auditing a configuration I wouldn’t recommend to anyone.

Two things I missed. The venue table in the proposal showed aggregate supply and borrow, not the loan book behind them. And I never compared the vault’s net yield with a direct deposit, which is the first question a depositor asks.

Remaining points

  • @iamChekwube #7: a migration runbook, a venue-failure framework, the Safe as a deliverable and a rebalance-cost metric go on the checklist for any return.
  • @Mattsanto #8: your four items become that checklist. One correction on redeemInKind: it hands the depositor the venue’s receipt token, so in an impaired venue it hands over the impaired claim, not rBTC.
  • @IBUKI #9: a plain dashboard, risk explained in plain language, and a measure of whether users understand what they hold. Agreed, same list.

What stays, and what would bring it back

The repository stays public at tag audit-2026-07, with the testnet deployment and the docs, and these findings go into KNOWN_ISSUES. The vault comes back only if a second rBTC venue meets the third-venue rubric already in the proposal (about USD 250,000 TVL, an independent audit, code lineage independent of both current venues) and there is a yield worth routing, with the checklist above built in. That would be a new proposal in a new thread, with a new audit quote. The repository also has the ERC-20 variant written for DOC. A stablecoin version makes sense once there is a second healthy lending venue for it on Rootstock, and it would come the same way.

@tamlerner, please treat this proposal as paused in the active-proposals overview. If anyone sees a number I read wrong, say so here.

Thanks

To everyone who shaped this on the sanity-check thread: Curia, DAOstar_gov, SEEDGov, PGov, Eren_DAOplomats, LEGOSI, Kaf_Anode, ChronoTrigger and krngill. To tamlerner for the KYB, the guidelines and the logistics. To Kaf_Anode, Seviramar, ChronoTrigger, iamChekwube, Mattsanto and IBUKI on this thread. To Blockscout for the integration and the letter, and to Coinspect for a quote pinned to the tag.

Reads (Rootstock block 9,275,849, Ethereum block 26,068,186)
  • Sovryn iWRBTC 0xa9DcDC63eaBb8a2b6f39D7fF9429d88340044a7A: totalAssetSupply 27.6234 rBTC, totalAssetBorrow 7.7952, supplyInterestRate 0.9176%, tokenPrice 1.030581 (1.029257 at block 8,973,849, 96.66 days earlier)
  • Sovryn protocol 0x5A0D867e0D70Fcc6Ade25C3F1B89d618b5B4Eaa7, getLoan(0x839c5e3e54c478d5b7b4f07914552f88c7fd974a067045ee20260bfed07b988f): principal 3.666582 rBTC, collateral 613,652 SOV, currentMargin 0, endTimestamp 1731013888
  • Sovryn PriceFeeds 0x437AC62769f386b2d238409B7f0a7596d36506e4, queryReturn(SOV, WRBTC, 613,652 SOV): 0.172751 rBTC
  • Sovryn iSUSD 0xd8D25f03EBbA94E15Df2eD4d6D38276B595593c1: totalAssetSupply 622,684 DOC, marketLiquidity 12.38 DOC
  • LayerBank Pool 0x526D06c65777eA6D56d7a1Dd47cD79230dDf72E9, WRBTC: aToken supply 30.56, variable debt 5.90, currentLiquidityRate 0.368%, liquidityIndex growth over the same 96.66 days 0.040% annualized
  • Merkl (api.merkl.xyz, chainId 30): borrow campaign on LayerBank variable-debt WRBTC, 11 September to 11 October 2026
  • Aave v3 Ethereum Pool 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2: WBTC currentLiquidityRate 0.0033%, USDC 3.58%
3 Likes
12

Hello @NeznaniJunak , thank you so much for the update, and we want to sincerely commend you for this level of thoroughness and intellectual honesty. Pausing the proposal based on deep on-chain due diligence - especially uncovering the nuances in the loan book and realizing the net yield would underperform direct deposits - definately demonstrates your builder integrity and protects the Collective from funding a misaligned product.

This is an exemplar of how the sanity-check and RFC process is supposed to work. You’ve saved the ecosystem time and capital, while leaving behind a hardened, well-documented repository that we can revisit if and when the underlying lending markets mature or a second healthy rBTC venue emerges. Thank you for this!

Wishing you the best, and so appreciate the thoroughness and work you put into this. Tks!

2 Likes