[USDC-B] Proposal for Collateral Onboarding

Given the pre-MIPs extensive community discussions and apparent interest in and request for this collateral type, we are proposing to add a second USDC collateral type to the Maker Protocol (‘USDC-B’). The purpose of this additional variant of USDC is to act as an emergency credit facility during times when keeper liquidity is overwhelmed (such as busy liquidation periods with large amounts of collateral being auctioned). This is in contrast to how USDC-A is currently being utilized (primarily as a tool to arbitrage the Dai price back down to $1.00). Ideally, the USDC-B collateral type should remain unused unless there is a severe and acute liquidity issue in the Dai markets. To incentivize this behavior, an abnormally high stability fee is being proposed to discourage long-term usage.

There have been numerous prior discussions in the community regarding the risks of USDC as a collateral type. Here is a compiled list of prior analysis for governance to review.

Original USDC discussion thread: Onboarding USDC as collateral to mitigate liquidity risk
Original USDC onboarding proposal: Proposal for Collateral Onboarding of USDC
Discussions on the need for both a USDC-A and USDC-B collateral types: USDC: Peg Arbitrage vs. Auction Liquidity
Governance call discussing USDC risk: https://www.youtube.com/watch?v=YZFfGlp01q0
Other related threads: Summary of USDC protocol risk
[USDC plus additional Stablecoins] Risk Parameter Request for Comment
What's the point of adding stablecoins as collateral?

As is the case for USDC-A, liquidations will be disabled for this proposal, and the oracle price would be fixed at $1. Metrics for USDC can be found in our TUSD proposal [TUSD] Proposal for Collateral Onboarding

Risk Parameters

We propose a 120% liquidation ratio for the same reasons as USDC-A. Specifically, the goal is to strike a balance between keeper capital efficiency and debt ceiling abuse through recursive leverage (which is made easier at lower liquidation ratios).

We propose a debt ceiling of 10 million. This number is slightly lower than what we might have preferred, but due to a) the OSM risk, and b) the 20 million debt ceiling of USDC-A, we are wary of the total counterparty exposure towards USDC. Additionally, for the time being the unutilized portion of USDC-A can also be used for emergency liquidity. In the future, the usage of Instant Access Modules will allow governance to keep this debt ceiling low, only to be increased on the go as needed.

We propose a stability fee of 50%. This high stability fee is designed to discourage long term sustained usage of USDC-B. Otherwise, during a liquidity crunch the keeper community may come to find that their emergency credit facility has already been used up for other purposes. At the same time, the stability fee should not be so high such that keepers’ Vaults would quickly become undercollateralized and liquidated. Even though liquidations would be disabled at the start, there is always the possibility that they will be enabled at any moment.

The USDC-A Vault behavior shows a median collateralization ratio of ~125%, implying that Vault owners are targeting roughly a 5% buffer over the liquidation ratio. If we assume USDC-B Vault owners will also keep a 5% buffer, then we would be interested in knowing how quickly Vaults would become undercollateralized at various stability fees.

At the proposed stability fee of 50%, keepers would have roughly 1 month to close out their Vaults before liquidation would occur (assuming they begin with at 125% CR and do not add additional collateral).

This proposal will go up for a governance vote this Monday.


I recommend that this special vault type should be excluded from [Signal Request] Change the Stability Fee Structure

That is, the stability fee should be kept at 50% regardless of where we move the stability fee for other vault types.


I disagree with this. Is 50% really that different from say 55% with a 5% Base Rate? Why make an exception already?

I would also like to add that if the Base Rate is higher than 0% then likely the USDC vaults will be at or close to 0 anyways. USDC only comes into play during bear markets / Dai liquidity crunches.

1 Like

Imo it should be excluded from the base rate changes. Base rate changes are supposed to be monetary policy changes, and this Vault type is not intended to be used to affect monetary policy.

It’s solely designed to be a liquidity backstop in the case of a market crash, so I don’t think it makes sense to have it affected by the base rate. The base rate changes would have little to no affect anyway, and it’ll be an additional line of executive code to validate every time the base-rate changes.


So I think we should be optimizing for governance and not for executive code simplicity. I expect the dev team will be generating fee changes with a script soon if they aren’t already. As you say yourself the Base Rate changes would have little effect, so why make an exception to the rule if we don’t have to?

So @Jiecut had mentioned using an y=ax+b setup for applying base rate changes (x) to collateral total stability fee in percent (y):

I think it would be reasonable for USDC-B to set parameters a=0 and b=50, which would keep this collateral package engaged with the base rate framework without any actual fluctuation from base rate changes.


I made a comment on this earlier in the [Signal Request] Change the Stability Fee Structure post. I’ll paraphrase it here.

For refence, our soon to be system for determining Vault stability fees is:
SFv = Base Fee + Risk Premium

So for USDC-B or any other collateral that we want to remain at a set SF, we could introduce a third parameter to the equation:

SFv = Base Fee * Fixed Rate Factor + Risk Premium

On normal collaterals, FRF would remain at 1. On collaterals where a fixed rate is desired, FRF would be set to 0, and the Stability Fee would rely solely on the Risk Premium.

Innitially I would see the FRF either being set at 0 or 1. But it could be later set to any positive (or negative) value.

Note that this is still a y = ab + x model, just that the a in the equation is usually set at either 1 or 0. When it’s set at 1 the equation becomes SF = base fee + risk premium. When set at 0 it becomes SF = risk premium.

Before going down this rabbit hole of how we implement a fixed Stability Fee, I think everyone should be clear on their reasons for wanting to override the new norm. There is governance overhead in overriding norms, and I want to be sure that making the override is worth it.

Those who voiced support for a fixed 50% Stability Fee regardless of the Base Rate above, what are your reasons?

@LongForWisdom has cited executive contract code reduction. This is true there will be one less line of code to set the USDC-B Stability Fee each week, but it is my understanding that the executive contract team is already using code to generate those contracts to avoid mistakes. (Dev team: correct me if I’m wrong)

I’m curious of the other reasons.

1 Like

My main reason is actually just that it isn’t directly applicable in the same way the base rate is applicable to other collateral packages. It makes sense to use a base rate for packages that are intended to be used to affect monetary policy, less so for anything else.

The USDC-B package is not intended to be used for monetary policy, it shouldn’t really even be considered a collateral package in the same way as the others are. It’s sole purpose is to provide emergency liquidity in the case of a market crash. It has no bearing on monetary policy.

My understanding was always base rate = primary monetary policy lever. There is no monetary policy advantage to modifying the stability fee on USDC-B, nor should there be (because that isn’t its purpose.) For the reason it doesn’t make sense to me to have it affected by the base rate.

What Lev posted in the other thread made sense to me, we’re going to need to move to a world where different collateral packages fall under different categories depending on asset and intention. I don’t think it makes sense to have emergency auction liquidity packages subject to base rate, monetary policy type changes.


So I guess we are looking at the same point of moving the Stability Fee around 50% doesn’t change the behaviour really at all, and taking opposing view points. I’m saying if it doesn’t matter then why care if it moves up 5% or down 5%, and you are saying if it doesn’t matter why bother moving it up and down with the Base Rate changes.

I get your point, and honestly I don’t have strong feelings beyond “let’s not break the governance paradigm until we have to” for this specific case. What may be more problematic is a fixed rate collateral type where the Stability Fee is low enough that the Base Rate overtakes it. We then may get some weird DSR minting behaviour that is undesirable.

1 Like

Pretty much. I actually don’t think it matters a huge amount for that reason.

My feeling towards breaking the governance paradigm is that it makes sense for cases like this in general (packages that aren’t intended to be modified to support monetary policy objectives), but in this specific case it doesn’t actually make a huge amount of difference. Not wanting to change it until we have to is also a reasonable position though.

I still think that it should be exempt, but it’s not going to break my heart if it’s subject to the base rate.


For this reason, I don’t think it is the best idea to add collateral types with a hard coded fixed stability fee.

I also don’t think we should be moving to a SF = ab + x system anytime soon, but see this as a good solution later in time (let’s say 6-12 months from now).

The USDC-B SF can be kept fixed by adjusting the Risk Premium in step with the Base Rate if desired. But I would propose setting the initial SF to 45% and be content as long as it stays between 45% and 55%.