[IP] Collateral Basket Change Proposal #1 Base

Summary

This proposal suggests starting to remove bridged USDC from the collateral basket, due to USDbC eventually becoming a deprecated asset across base.

Current Basket:

50% Compound USDbC.
50% Stargate USDbC

New Basket:

50% Compound USDbC.
50% Aave USDC

Abstract

Aave:
The concerns of USDbC becoming a deprecated asset on Base are approaching. The proposed proposal, if enacted, would swap the Stargate USDbC pool for Aave USDC supply position.

Problem Statement:
The current basket for hyUSD on Base contains 50% of the Stargate USDbC pool. USDbC or the USDC that is bridged from ETH to Base will become deprecated across base, and eventually replaced with native USDC. We are striving to increase the long term scalability of High Yield USD on Base, and thus we believe that removing USDbC would be a wise decision.

Rationale

Aave:
Aave is a decentralized non-custodial liquidity protocol where users can participate as depositors or borrowers. This collateral asset is being used in Vaya and has shown that it is a good choice for a collateral asset. As of writing this proposal the TVL is and APY are both higher in the Aave USDC supply side, compared to the USDbC Stargate pool.

Risks

By removing a soon to be deprecated asset we believe that we are increasing the scalability for a longer term outlook. We believe we are doing so in a way that doesn’t increase the risk profile. We are introducing a new protocol(Aave) into the collateral basket but this protocol has been seen before in another RToken.

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

Hi! Firstly, I wanted to congratulate the High Yield USD 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. We encourage the hyUSD team to adopt this convention 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 and approved by majority here: