[RFC] Formal deprecation of abandoned DTFs

Governance & Delegates
1

Summary

This proposal from ABC Labs seeks to formally deprecate 17 Yield and Index DTFs that have been effectively abandoned: i.e., no active usage, no governance participation, no one watching them. Rather than leave these products in indefinite limbo, this RFC proposes executing the appropriate onchain deprecation steps for each and tagging them accordingly in the Reserve app.

If you currently hold any of these tokens: redemption remains live throughout this process. You can exit for your pro-rata share of underlying assets at any time. This proposal doesnā€™t change that.

Abstract

Seventeen DTFs across the Reserve Yield Protocol and Reserve Index Protocol are currently listed on the Reserve app despite being dormant. This RFC proposes formally deprecating each by stripping administrative roles and disabling issuance by calling deprecateFolio. Each will be tagged as deprecated in the Reserve app with appropriate context. Governance monitoring via Hypernative will be removed for each.

Yield DTFs to be deprecated: dgnETH, hyUSD (mainnet), hyUSD (Base), MAAT, KNOX, USDC+, BSDX, VAYA, rgUSD

Index DTFs to be deprecated: mvRWA, mvDEFI, AI, VTF, CLUB, MVDA25, SBR, ZINDEX

Problem statement

The Reserve platform is designed for permissionless experimentation. Thatā€™s intentional, but it means thereā€™s always going to be a long tail of products that launch, donā€™t find traction, and quietly go dark without ever being formally wound down.

The DTFs listed above share that profile. They launched. They attracted little or no sustained usage. Their deployers are no longer actively managing them. Governance participation has been effectively zero. In several cases, key roles remain assigned to wallets with no active steward willing or able to use them.

This creates three concrete problems. First, a user browsing the Reserve app today canā€™t tell the difference between an active, well-governed product and one that nobody has touched in monthsā€¦ theyā€™re listed side by side with no distinction. Second, unmonitored smart contracts carrying live governance roles are an unnecessary risk. Third, maintaining governance monitoring infrastructure like Hypernative for products nobody is using is a straightforward waste.

Rationale

ABC Labs is proposing this because weā€™re the ones carrying the ongoing cost of monitoring these products. Each DTF on this list requires active attention (governance alerts, role monitoring, infrastructure overhead) regardless of whether anyone is actually using it. Deprecating the products that arenā€™t going anywhere lets us focus that attention on the ones that are.

The case for formal deprecation comes down to three things.

Focus. These DTFs arenā€™t self-sustaining. They require active monitoring from ABC Labs to remain in a safe and functional state. Thatā€™s a real time and attention cost, and itā€™s better spent on the products with genuine traction and active communities. Reducing the surface area of what we need to monitor, without increasing risk, is the goal.

Hygiene. Dead products create noise for users trying to evaluate whatā€™s actually available on Reserve. A registry that reflects reality is more useful and more trustworthy than one that doesnā€™t.

Clarity. Users browsing the Reserve app today canā€™t tell the difference between an active, well-governed product and one that hasnā€™t seen meaningful usage in months; theyā€™re listed side by side with no distinction. Tagging deprecated products clearly, with appropriate context for any remaining holders, is simply good UI.

If thereā€™s an active community or deployer willing to take on genuine stewardship of any DTF on this list, thatā€™s the better outcome; make that case in this thread before this moves to an IP. Absent that, formal wind-down is better than indefinite limbo.

Risks

Holder impact. Redemption remains enabled throughout the deprecation process. Holders can continue to redeem for their pro-rata share of underlying assets. Before any onchain execution, this RFC and any subsequent IP will be communicated clearly across Reserveā€™s community channels so holders have time to act.

Incomplete role removal. If the required governance actions arenā€™t executed precisely, some administrative surface area could remain. Each step should be verified onchain after execution.

Mistaken deprecation. If any DTF listed here has an active community or steward who simply hasnā€™t been visible in governance, this RFC is their opportunity to come forward. Anyone who believes a specific DTF should not be deprecated should make that case here before this transitions to an IP.

Governance execution risk. Several of these DTFs have very low or zero staked RSR, which may make reaching quorum for the deprecation action difficult through the standard process. Where thatā€™s the case, coordination with known stakeholders or alternative execution paths may be neededā€¦ flagging this now so it doesnā€™t become a blocker later.

Poll: Do you support formally deprecating the DTFs listed above?

  • Yes, proceed to IP
  • No, more discussion needed
  • Yes, but with modifications (comment below)
0 voters
3 Likes
2

Well rationalised proposal @starl3xx.

Even though iā€™m in strong support of the proposal, deprecating dgnETH and rgUSD is a especially sad moment, I had such high hopes for both of them. :frowning:

I think this proposal comes at the right time, in the context of the RSR health discussion and streamlining the protocol while true PMF for DTFs is found. However, at some point in the future I hope weā€™ll be able to enable true permissionless minting of Index DTFs, at which time weā€™ll see the flood gates open. Hopefully, weā€™ll see many success but weā€™ll definitely also see many failures. With this in mind, I wonder if we should work on a formal depreciation framework which streamlines this process, avoids running IPs through forgotten DAOs with low participation rates and the use of alternative execution paths, which I imagine are heavily centralised.

With regard to another risk you mention: Incomplete Role Removal. Iā€™d appreciate if the loop could be closed post-execution with the team returning back here to confirm the roles have been removed appropriately.

3 Likes
3

Happy to see Reserve formally admitting failure with these products. Hopefully we will have less of these in the future.

4

Very interesting question here is - how does Reserve address governance that affects the ecosystem as a whole. Currently thereā€™s no framework for that. Each DAO is itā€™s own microcosm.

We had a decent discussion about some ways to bundle resources, but nothing on the top-level. From a strictly technical perspective itā€™s not possible to do so now. It would also be risky to implement that because it would introduce a ā€œsuperadminā€ role to all DTFs. A massive security risk.

One way to abandon DTFs would be to simply remove all reference to them. This has been done with Aave v1 for instance. The smart contracts are still around, but no frontend references them anymore.

2 Likes
5

Yeah, we often talk about Reserve being very unique given itā€™s DAO factory properties but this is the first time weā€™ve seen the other end of it. It sounds like a vlRSR / RSR DAO is strongly being considered. I feel this DAO would be perfectly placed to depreciate these DAOs but understand your point around introducing a ā€˜superadminā€™. I wonder if having strict parameters i.e the only governance flow the ā€˜RSR DAOā€™ can complete on any DTF is to call deprecateFolio. Iā€™m sure there would still be gov attacks trying to depreciate active DTFs but given there is little to no incentive for the proposer this wouldnā€™t occur too often.

Maybe something to consider once governance is more mature but feels like a much more elegant way to shut these down than mustering the remaining governors of these dead and dying DAOs for one final death march towards deprecation.

Your comments are interesting regarding Aave V1. Do you know roughly how long they weā€™re in the grey area of ā€˜depreciatedā€™ but still accessible on the UI before all front-end references were removed? If I still had funds in Aave V1 today, how could I withdraw them today?

6

You would call the functions via Etherscan or by coding up a small script.

They deprecated the v1 on the frontend within less than a year iirc.

7

I would like to keep the MEV RWA and MEV Large Cap DEFI. I feel with time it will gain some traction just like the Cmc20