# [IP] eUSD 3.4.0 Upgrade Step 1
[https://forum.reserve.org/t/ip-eusd-3-4-0-upgrade/753](https://forum.reserve.org/t/ip-eusd-3-4-0-upgrade/753)
Upgrade all eUSD core contracts and assets from version 3.0.1 to version 3.4.0 and upgrade to new Governance and
TimelockController instances via a spell contract.
# Unregister Old Assets, Increase Revenue Rates
This proposal aims to Increase “Reward ratio” from 0.0000032090147 → 0.0000064180, as well as Unregister all available assets
# Adjust Default RToken Throttles
**Introduction**
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
**Motivation**
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.
**Conclusion**
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.
# Upgrade eUSD contracts to use version 2.1.0 of the Reserve Protocol
v2.1.0 of the Reserve Protocol contains important bug fixes and improvements to the core implementation contracts. The governance actions in this proposal will:
- Update the eUSD Broker implementation contract to v2.1.0
- Update the eUSD Broker to use the v2.1.0 Trade Implementation contract
- Update the eUSD Basket handler implementation contract to v2.1.0
- Update the eUSD RToken implementation contract to v2.1.0
- Update the eusdRSR implementation contract to v2.1.0
In particular, these updates include a critical fix to the Broker and Trade plug in to better interact with Gnosis EasyAuction and avoid the Broker becoming disabled, requiring a governance action to re-enable, as happened in March of this year.
# Max Trade Slippage Reduction to .5%
Summary
Change Max Trade Slippage from 1% to default value of .5%.
Abstract
Max Trade Slippage is the percentage value the describes the maximum deviation from oracle prices that any trade that the protocol performs can clear at. Slippage permits additional price movement beyond the worst-case oracle price. 1% slippage means if oracles quote the price for USDT at $1.00 per USDT, the protocol will allow an auction to clear at $.99 per USDT, in the current state. I am proposing to half this possible discrepancy, to $.995 per USDT.
Problem statement
Clearing a trade of an asset at 1% deviation from the oracle price allows for those that participate in the auction to, in the limit, extract 1% of the total collateral value being auctioned from the RToken stakers. $3.75 million of USDT (if eUSD is at 7.5 million circulating supply), means that the auction participants can extract $37,500 from the RSR stakers (this is assuming there is no competition).
Rationale
I would like to change the Max Trade Slippage to the default value of .5%. 1% is too great of a value for upcoming eUSD collateral auction.
Risks
It is the default value, proposed by the Reserve team. There should be no risk to this.
# [Correct] Trading Delay Reduction to 2 Hours
Summary
Change the Trading Delay from 6 hours to 2 hours.
Abstract
Change Trading Delay of eUSD to 7200 seconds (2 hours) from 21600 seconds (6 hours). Currently the Trading Delay is an additional buffer of time between an event and when auctions start. When USDC depegged, the protocol initiated a 24 hour “wait-and-see” countdown. This default alarm itself puts the community on high alert to the default, and keeps them on high alert for 24 hours, watching the peg of the asset closely. At the end of the 24 hour period, USDC did not re-peg, and the protocol subsequently allowed for the auctioning of the USDC-denominated collateral. Before the protocol officially allows for the auctioning of the collateral, there is an additional timer, called the Trading Delay, which postponed the auctioning of USDC-denominated collateral for an additional 6 hours. The proposed changed would lessen this additional time, the Trading Delay, to 2 hours.
Problem Statement
The Trading Delay being set to 6 hours is not correct. I believe it should be set to 2 hours, as all events preceding the Trading Delay have sufficient time for the community to become alert. Governance proposals to change the basket of eUSD are one week. Default detections are 24 hours. The Trading Delay of 6 hours is too great of a delay.
Rationale
Both the default “wait-and-see” 24 hour and week long basket change proposal period allow the community sufficient time to be aware of potential impending changes. I do not believe the Trading Delay should be 0 or 1 hour, as I see the Trading Delay to be a planning buffer for teams and individuals. This planning time (Trading Delay) should be sufficient enough to allow some travel and communication for teams and individuals to be present for the auctions.
Risks
It is possible that the Trading Delay being set to 2 hours would cause some issues I am not anticipating.
**Earlier proposal submitted was using incorrect math for 2 hours. My apologies.**
# Trading Delay Reduction to 2 Hours
Summary
Change the Trading Delay from 6 hours to 2 hours.
Abstract
Change Trading Delay of eUSD to 3600 seconds (2 hours) from 21600 seconds (6 hours). Currently the Trading Delay is an additional buffer of time between an event and when auctions start. When USDC depegged, the protocol initiated a 24 hour “wait-and-see” countdown. This default alarm itself puts the community on high alert to the default, and keeps them on high alert for 24 hours, watching the peg of the asset closely. At the end of the 24 hour period, USDC did not re-peg, and the protocol subsequently allowed for the auctioning of the USDC-denominated collateral. Before the protocol officially allows for the auctioning of the collateral, there is an additional timer, called the Trading Delay, which postponed the auctioning of USDC-denominated collateral for an additional 6 hours. The proposed changed would lessen this additional time, the Trading Delay, to 2 hours.
Problem Statement
The Trading Delay being set to 6 hours is not correct. I believe it should be set to 2 hours, as all events preceding the Trading Delay have sufficient time for the community to become alert. Governance proposals to change the basket of eUSD are one week. Default detections are 24 hours. The Trading Delay of 6 hours is too great of a delay.
Rationale
Both the default “wait-and-see” 24 hour and week long basket change proposal period allow the community sufficient time to be aware of potential impending changes. I do not believe the Trading Delay should be 0 or 1 hour, as I see the Trading Delay to be a planning buffer for teams and individuals. This planning time (Trading Delay) should be sufficient enough to allow some travel and communication for teams and individuals to be present for the auctions.
Risks
It is possible that the Trading Delay being set to 2 hours would cause some issues I am not anticipating.
# Update eUSD's primary basket to 25% each of saUSDC, cUSDC, saUSDT, cUSDT
To diversify the pimary basket held by eUSD, and put all of the assets to work generating yield, this proposal replaces the USDT that is 50% of the basket with 25% saUSDC and 25% cUSDC, resulting in a basket that is 25% each:
- saUSDC
- cUSDC
- saUSDT
- cUSDT
These tokens have been selected for:
- 1:1 USD backing of the reference assets USDC and USDT
- High circulating supply of the reference assets
- Sufficient size of and demand for the collateral asset lending pools
# Update emergency collateral settings (re-submit)
This proposal updates the emergency collateral assets to be USDC, USDT, USDP, TUSD, and DAI, in that priority order. Diversity factor remains 2.
First, it adds the replacement USDC and DAI collateral plugins to the asset registery, as well as adding the plugins for USDP and TUSD.
(resubmitting having determined that community support **is** genuinely present)
# Update emergency collateral settings
This proposal updates the emergency collateral assets to be USDC, USDT, USDP, TUSD, and DAI, in that priority order. Diversity factor remains 2.
First, it adds the replacement USDC and DAI collateral plugins to the asset registery, as well as adding the plugins for USDP and TUSD.
# Enable broker for trading
This proposal is to re-enable the trading for Gnosis EasyAuction by setting the disabled flag to false. Once this is done, protocol can resume its operations of recollateralization.