RFC: Adjust Default RToken Throttles


This proposal seeks to adjust the default throttle limits on RToken issuance and redemptions. Following the recent Curve exploit, we feel that it is prudent to re-evaluate these parameters in order to maximize the security of RToken holders. Specifically, we invite RToken governors to consider the following changes:

Proposed Specification

Issuance Throttle

  • From 2.5% to 5% of RToken TVL
  • From $1 million to $250k

Redemption Throttle

  • From 5% to 7.5% of RToken TVL
  • From $1.5 million to $500k


We recommend these changes to bolster the Reserve ecosystem’s security through more conservative limits, considering recent industry events.

What Happened with Curve and why is it Relevant?

On July 30th, Curve suffered an exploit where attackers took advantage of a technical flaw which allowed attackers to mint infinite pool tokens and fraudulently claim the entirety of the pools’ funds. Fortunately, none of the RToken-related pools were affected.

However, we must reflect on what could have happened in the theoretical case that RToken pools were affected. Notably for hyUSD, which is paired with eUSD on Curve, slowing the rate at which the RTokens (and thus LP tokens) can be minted would inhibit a similar attack by creating a tight bottleneck at key junctions of the exploit. This measure was not present in any of the affected pools from the recent attack - flashloans let the attackers obtain infinite ETH with which they could mint infinite LP tokens.

Understanding the Proposed Changes:

In more general terms, by setting lower throttles on RTokens, we reduce the opportunities and flexibility for an attacker to carry out exploits in size.

  • Issuance Throttle: By decreasing this limit, we make it harder for potential attackers to mint an excessive amount of new RTokens - whether the RTokens are fraudulently minted (exploiting a bug in Reserve) or used externally for carrying out another attack (the example described above with the hyUSD/eUSD Curve pool).
  • Redemption Throttle: Decreasing this limit makes it more challenging for potential attackers to redeem a large amount of existing RTokens in a fraudulent manner.

Weighing the Costs

These modifications are not without trade-offs. Notably, it can become harder for large depositors to enter and exit RToken positions with reduced throttles. We must be wary of creating unnecessary friction. However, an analysis of hyUSD’s 16 minters indicates that only two minted amounts in excess of $250k (both of them Reserve-affiliated), suggesting minimal impact of the proposed change on hyUSD users.

Moreover, recall that the throttle restrictions operate based on the larger of 1) the % RToken TVL, and 2) the absolute amount. Based on the proposed 5% issuance throttle, the percentage calculation takes over above $5M TVL, and at $10M RToken TVL, the issuance throttle becomes $500k. We feel these figures respect an RToken’s ability to grow unimpeded whilst prioritizing safety.


Reflecting on the recent Curve exploit, we believe proactive steps can strengthen the RToken ecosystem. Reducing the default throttles for issuance and redemption can enhance the security of RTokens by limiting any potential harms, both internal and external.

We urge all Reserve RToken governors to review this proposal and provide your feedback or questions. Your participation is vital in ensuring the continued success and integrity of Reserve.


This seems like a good proposal with decent evidence supporting it. There seems to be a small potential negative compared to the potential positives. It is also relatively easy to adjust this in the future if governors decide it needs updating. As such, I am in support of this proposal. Thank you @Larry!


Iam also in support … it is another safety meassure and positive argument for Reserve and for an RToken deployer i think.


I see this as an overall positive. I am for adjusting the Issuance and Redemption Throttles to the specifications described in the proposal for hyUSD.


I think these are sensible values and I like the general direction of allowing the percentage parameters to takeover at an earlier point.


Great proposal, Larry. I’m in favor.