[RFC] ETH+ Issuance and Redemption Throttle Changes

[0xSleepy]

Summary

This RFC suggests a change that would increase the issuance and redemption throttle for ETH+. The goal of this proposal is to enhance the user experience for large capital allocators who are looking to mint ETH+ in size. We are seeking the community’s feedback on whether this should be implemented.

Background

Currently, the ETH+ issuance throttle is set to whichever is higher: 250 ETH or 5% of the ETH+ market cap. Similarly, the redemption throttle is determined by the higher value between 500 ETH or 7.5% of the ETH+ market cap. In discussions with large minters, the feedback we’ve received indicates that the current offering is too limiting because they wish to mint and redeem in as few transactions as possible.

Specification

This proposal aims to adjust the issuance throttle to the higher of either 500 ETH or 10% and the redemption throttle to the higher of either 625 ETH or 12.5%

Following is a comparison of the proposed changes:

Throttle	Current Cap	Proposed Cap
Issuance	250 ETH or 5%	500 ETH or 10%
Redemption	500 ETH or 7.5%	625 ETH or 12.5%

Rationale

Issuance and redemption throttling are important mechanisms designed to safeguard RToken & $RSR stakers from being drained from malicious actors attempting to drain funds or inject large amounts of defaulting collateral into the protocol.

However, the current throttle settings are too restrictive. Whales are dealing with long wait times for minting and unnecessary gas fees. These limits worsen the customer experience for RToken issuance and slow down the growth of Total Value Locked (TVL). We need to adjust the issuance and redemption throttles to make the process smoother, and to more easily integrate large users into Reserve.

Risks

Increasing the throttles can result in more volatility for ETH+ TVL figures, however, contributors believe that throttle levels can be increased while still remaining conservative. These changes would result in improved user experience while maintaining safety and security.

Conclusion

This proposal aims to raise the issuance and redemption thresholds for ETH+, to enhance the platform’s efficiency and user satisfaction. In doing this, there are potential risks as well as opportunities to grow the Reserve vision further. We are asking the community to provide their feedback, supporting or critiquing, to ensure these changes meet our collective goals and standards.

• I support the proposal to adjust the issuance and redemption throttle
• I do not support the proposal to adjust the issuance and redemption throttle

[0xTomSawyer]

I voted in favor of this proposal, I think that as we continue to see growth in ETH+ it makes sense to allow for movability within the asset for some of the bigger holders.

[Mallo]

I voted in favour too - if the protocol is to get to where it wants to be it must deal with large inflows and outflows safely. This might spark further conversation about the smart contracts.

[lucas_ITB]

We’re in favor of this proposal at IntoTheBlock (ITB). Our institutional clients are interested in minting ETH+ with size and the current cap is too restrictive and cumbersome, requiring multiple transactions.

This would make the process significantly faster and more whale-friendly without sacrificing risk management.

[RyanTreeFiddy]

I’m all for large capital allocation. I support this.

[Smeddy]

Lower limits were great as a starting point, and now it’s time for the next chapter.

[Geraldine]

Given protocol testing and history of functionality under duress, I fully support higher volumes of capital allocation

[Jose_StableLab]

Hi! Firstly, I wanted to congratulate the ETH+ team for the high quality of their written communications. In an effort to help governance proposal clarity and following the reccommended naming conventions published in the forum by StableLab, we modified the title of the proposal to clearly display [RFC] (between square brackets) at the beginning of the title. In addition, we tagged the post in the subcategory ETH+ RFC to make it clearer for new users. We encourage the ETH+ team to adopt these conventions to keep a good [RFC] and [IP] record track.

Reccommended proposal guidelines: Naming convention for RFCs and IPs

In addition, this proposal has been published for onchain voting twice but could not reach the quorum here:

Reserve Register - Reserve Protocol Interface

And here:

Reserve Register - Reserve Protocol Interface

[0xSleepy]

Would love to here community feedback on this. Generally I like the changes

[nevin.freeman]

I would propose increasing the issuance and redemption throttle minimums even further, to ≈$5M and ≈$6M, respectively.

Issuance: 1,7000 ETH or 10%, whichever is greater
Redemption: 2,000 ETH or 12.5%, whichever is greater

I propose this because:

• For redemption, I think the probability of an exploit from a bug that makes use of redemption is low enough that risking up to 2,000 ETH or 12.5% is an acceptable risk
• For issuance, the throttle is meant to protect from an attacker minting while collateral is mid-default and benefitting from RSR-funded recapitalization, but ETH+, by design, does not have much RSR collateral, so it’s not a very attractive target for someone to try to exploit this way, and the total loss that could be taken by ETH+ holders in this case is low anyways, as there is not much RSR to cover them in the event of a default and thus not much to lose

These numbers would presumably make minting and farming ETH+ more convenient and attractive, which seems worth the small tradeoff in risk.

@0xSleepy, what do you think of this approach?

[0xSleepy]

I agree with the rationale for adjusting the issuance and redemption thresholds. It’s a strategic move to enhance user experience and attract more activity by making ETH+ minting and farming more convenient.

Even with multiple audits reducing the risk of exploits—especially those conducted by reputable firms like TOB—the system’s resilience is not just about the direct risks but also the vulnerabilities in the underlying protocols that could potentially impact the RToken.

In your proposal, increasing the redemption threshold to ≈$6M (2,000 ETH or 12.5%) is based on the low probability of exploit risk, which seems justifiable given the demonstrated in past audits. On the other hand, increasing the issuance threshold to ≈$5M (1,700 ETH or 10%) because of minimal RSR collateral in ETH+ suggests a lower risk exposure, which might facilitate more activity without significantly compromising safety.

Is there a way we can test how the parameter adjustments could alter the risks if underlying collateral is exploited? Understanding these dynamics will help ensure that the system remains secure even as it becomes more accessible and appealing to users.

Overall, I support the proposed changes, given the considerations are met and the system continuously adapts to new security findings and market conditions.

[Crypto_Goku]

It is regrettable that the last two governance proposals were not successful. The high gas fees on Ethereum are too burdensome for those staking on ETH+, especially since their profits are already minimal due to the 5% cap. Moreover, only two RSR auctions have been conducted and paid out since the inception of ETH+, which is insufficient to legitimize a voting process. Essentially, the stakers are incurring losses.

As a result, the next amendment must be genuinely sustainable, which is why I support the proposal to significantly increase the minting limit, finding Nevin’s arguments very compelling. The redemption cap should also be raised accordingly.

Today → In the last three hours alone, over three million dollars in ETH+ were minted, indicating a demand for a more efficient and cost-effective minting process that could also benefit larger investors.

I hope enough volunteers will altruistically participate in the next voting process and bear the costs of the election.

RESPECT TO YOU ALL!

[0xSleepy]

GM

I plan to resubmit the proposal onchain within the next few days, as it did not reach quorum previously. The feedback from the forum has been overwhelmingly positive. When this proposal goes onchain again, I will take steps to ensure it meets the quorum and secures approval.