[IP] hyUSD Mainnet 3.4.0 Upgrade

High Yield USD (hyUSD) hyUSD RFC
1

Summary

Upgrade all hyUSD core contracts and assets from version 3.0.1 to version 3.4.0 and upgrade to a new Governance and TimelockController instances via a spell contract.

Abstract

Currently hyUSD is using version 3.0.1 of the Reserve Protocol. There isn’t necessarily a problem with remaining on this version, but there is an upgrade available that will make hyUSD more efficient.

The proposed proposal, if enacted, would use a spell contract prepared by ABC Labs; a contract that will handle the majority of the onchain calls necessary to complete the upgrade. The spell contains 2 steps: (i) an upgrade step; and (ii) a cleanup step. The spell has been audited by ABC Lab’s security partner, Trust Security.

Spell: Upgrade3_4_0 | Address 0xb1df3a104d73ff86f9aaab60b491a5c44b090391 | Etherscan

Problem Statement

Currently, when upgrading any contract tied to the RToken it has to be done manually one at a time in individual governance proposals. The spell contract allows for all the contract addresses to be updated in one governance proposal.

Rationale

There are several improvements made by upgrading all hyUSD core contracts and assets from version 3.0.1 to version 3.4.0. The biggest benefit has to do with RTokenAsset pricing which accounts for all balances of the RToken that are out on trade. Previously this has prevented RTokens from being used as collateral in lending protocols without an oracle.

The spell sets the trading delay to 0, bots seem to be more integrated into auction participation. Setting the trading delay to 0 encourages more participation from the MEV bots.

This upgrade also adds better pricing decay logic that would take over in the case that a chainlink oracle would go offline. Additionally, automatic StRSR drip and Furnace melt after revenue auction ends. Lastly, there are improvements made for mild gas optimizations.

Draft instructions have been provided here by ABC Labs:

Step 1 - Upgrade

To execute step 1 of the upgrade spell, RToken governance should prepare a proposal containing two calls:

  1. main.grantRole(0x4f574e4552000000000000000000000000000000000000000000000000000000, 0xb1df3a104d73ff86f9aaab60b491a5c44b090391)
  2. spell.castSpell1(0xaCdf0DBA4B9839b96221a8487e9ca660a48212be)

As step 1 is executed the spell will revoke its access as well as rotate the TimelockController that admins each RToken deployment.

Step 2 has a number of prerequisites before execution

  1. it must be voted on in the new Governance contract deployed in step 1
  2. all reward token balances should be claimed
  3. all rebalancing auctions must run to completion
  4. all revenue auctions must run at least until all surplus balances are below the minTradeVolume

Step 2 - Cleanup

To execute step 2 of the upgrade spell, RToken governance should prepare a proposal containing two calls:

  1. main.grantRole(0x4f574e4552000000000000000000000000000000000000000000000000000000, 0xb1df3a104d73ff86f9aaab60b491a5c44b090391)
  2. spell.castSpell2(0xaCdf0DBA4B9839b96221a8487e9ca660a48212be)

Risks

By upgrading to the latest version of the Reserve Protocol, the risk lies in keeping the code the same and not moving to an improved version of the RToken. There are technical smart contract risks, but this is mitigated by the Trust Security Audit.

  • Yes, I am for this proposal
  • No, I am against this proposal
0 voters
2 Likes