Summary
Perform eUSD smart contract maintenance, upgrading to Reserve Protocol v2.1.0
Abstract
v2.1.0 of the Reserve Protocol has been released and it contains an important bug fixes to contracts which control the operation of eUSD. Specifically we propose upgrading the implementation contract for the Broker, upgrading the broker’s Trade Plugin, and upgrading the implementation contracts for the Basket Handler, RToken, and eusdRSR.
Problem statement
The Trade plugin used by the Broker has a safety check which disables the trading if any trade returns less than expected. The version of the Trade plugin current in use in eUSD does not fully anticipate the degree to which Gnosis EasyAuction may defensively round. This caused disabling the Broker during one of the auctions that occurred when USDC defaulted, and required a governance action, taking 8 days, to re-enable trading. The v2.1.0 Trade plugin improves compatibility of the safety check with Gnosis EasyAuction, and the v2.1.0 implementation contract for the Broker adds governance actions to enable the upgrade of the Trade plugin.
v2.1.0 of the Reserve Protocol has additional fixes and improvements in the implementation contracts for the Basket Handler, RToken, and stRSR. A list of changes can be found here.
See also: eUSD Evolved: A Guide to Upgrading
Rationale
We got lucky during the USDC de-peg that the Broker had sold the defaulted primary basket assets before the safety check triggered. Had the auctions happened in the reverse order, the safety check would have triggered on the first action, leaving half of the defaulted assets stuck until governance could re-enable trading. We were further lucky in the being no other practical repercussions from assets not being able to be auctioned during that 8 days period.
Since then, altruistic auction participants have carefully participated in all auctions, providing bids that ensured the safety check would not be triggered again. This is a tedious process and it can not be guaranteed to be available for all auctions in the future.
Updating the Trade plugin and Broker contract implementation is a more sustainable solution. If we were to deploy eUSD today, we would use the v2.1.0 implementations to take advantage of these improvements, and so we propose upgrading not only the Trade plugin and Broker implementation contracts, but all of the core contract implementations across the board, giving eUSD the benefit of all of the v2.1.0 bug fixes and improvements.
Risks
v2.1.0 of the Reserve Protocol, and particularly the improvements to the Trade plugin’s safety check have been tested extensively, and are available for public inspection. However, as always with smart contracts (and code in general) there are risks that new bugs have been introduced.
Community poll
- Yes, I am in favor of this proposal
- No, I am against this proposal
0 voters