If enacted, this proposal would swap the Compound USDT V2 market for the Compound USDT V3 market.
Problem Statement:
V2 Compound markets are legacy markets and are no longer earning additional COMP rewards. Additionally, the Compound Community is looking for a progressive way to deprecate all V2 markets.
The USDT V3 market is being incentivized to grow with additional COMP rewards and the USDT V2 market is not. The APY from the V3 market is significantly higher than the APY from the V2 market.
Compound Market
Base Earn APY
Comp Rewards APY
Total APY
USDT V2
7.35%
0%
7.35%
USDT V3
10.58%
2.24%
12.83%
Risks
The risk is in keeping Compound USDT V2 in the basket. eUSD holders and RSR stakers will be negatively impacted if a deprecated asset remains in the basket. While the risk of Compound USDT V2 becoming deprecated isn’t immediate, governors have the chance to get ahead of this potential issue to avoid any conflict in the future.
The initial Compound V3 USDT risk and incentive parameters were put forward by Gauntlet and can be reviewed here:
Thank you very much for bringing this forward Tom. I will for now vote against the proposal. Of course I am generally fully in favor or replacing later-to-be-deprecated assets for their non-deprecated successors, but I would first welcome a thorough analysis of the negative impact the recent basket change of hyUSD had on the hyusdRSR-RSR ratio. Would be great if the results of that can be included in the Risk section of this proposal, either stating that it will not be an issue here f that is the case or the potential impact it could have if this basket change would be executed. If will re-assess my vote if this is done. The deprecation is not imminent so luckily there is time for doing this.
Concerned these proposals jump straight to a poll without “encouraged” discussion on the RFC.
IMO there should be discussion, before a poll. There should be days of discussion before a temp check poll. Sure some savvy governors may know all the angles of discussion and polling possibilities, but jumping to immediate polls incentivizes lazy voting over substantive exploration, discussion and community cohesion. IMO our governance approach polling before discussion is not the correct process.
Every RFC is an opportunity to grow community cohesion and vesting in the RTokens mission. At first it will be a tiny trickle, but can become an unstoppable gusher.
Recommendation: add and “encourage/invite” 7 day discussion period (minimum) before polls are added to RFC. Cc: @rspa_StableLab
From a governance mechanism point of view, prolonging the RFC timeline occurs when discussions are routinely unfinished but still ongoing when the minimum time elapses.
Proposal authors are free to continue the discussion before conducting an on-chain poll, but the minimum must be respected.
A longer minimum slows governance down and can lead to less participation in discussions as people just get bored or lose a sense of urgency.
As governance facilitators I see no need to suggest a change in the minimum RFC time for eUSD at the moment.
But of course eUSD governoors are more than welcome to propose this.
If you want to put this to a poll and need support, please let me know. Happy to help.
More important point I am making is poll should be added to RFC after the 3 day discussion has ensued. Starting an RFC with a poll skips the crucial step of discussion.
Discussion builds community cohesion and inclusivity—areas the Reserve community still struggles with. Not ready to give up on fixing that (just yet).
To implement the suggested change it would require some clarification to this drawing on the “poll at the end” reference, which as I am suggesting should occur after the 3 day period.
That could be an option. Two things that leave me unconvinced this is a must:
Users can change or even undo their vote in forum polls right now.
Adding a poll after the three day discussion period means adding time for polling → slower governance.
What I really like about the RFC process in Reserve at the moment is that it’s a very lightweight way to gather some feedback and get a pulse check.
We’ve seen a couple of times that proposals don’t necessarily pass when they get some buy-in in the RFC phase. I have not seen a DAO where off-chain voting translates to on-chain voting 1:1. It shouldn’t. These are different aspects of the decision-making process.
Off-chain voting or forum polls are a sentiment check, on-chain poll is a permission to execute.
Very different things.
The current RFC process in Reserve achieves all these goals in a very lightweight and natural way with low friction. And governance activity across rTokens is not high.
Adding more friction is not supportive of evolving rTokens currently, in my mind.
Governance is not a goal in itself. Process should only be introduced because it is absolutely necessary. This opinion is probably strange, coming from a governance person, but it’s because I know and love governance that I want to keep it lean and clean.
