Increase iUSD MCR to ensure protocol solvency

The choice to launch iUSD with 110% MCR was in my opinion highly controversial. In this moment of no competition for Indigo it is paramount that the solvency of the protocol and proving in volatile environment the efficiency of liquidations during large downturns (and congested network).

With this in mind, and knowing that the CDP creation demand balances out upside depeg I don’t believe that 1.10 usd (reasonable upwards bound for 110% MCR) is any cope – and already leaves a mark on the system.

In conclusion – the proposal aims to change MCR on iUSD to 130% with a goal over the next quarter to go to 125% if the system shows remarkable capacity to remain solvent in turbulent (and adversarial) markets. This may not be the safest option still but comparatively leaves much greater room and time for the arbitrage incentives to naturally play out.


Good to see people thinking about MCR, I would vote yes to this proposal to keep it stable. I also believe the proposer has good experience in the space.


The MCR could be raised even higher (140-170) if we wanted to be appropriately hedged given the system constraints – but I do acknowledge the team’s desire to encourage the creation of CDPs and this number seems like a good compromise between ensuring solvency and encouraging the use of the protocol


Please show your evidence


Show your Quant’s analysis that the current number is able to keep the system solvent.


Don’t know if this is possible. But maybe there could be lower positions, like 100% only if the overall collateral is beyond certain thresold. So, for instance, if you want to mint iUSD against 101% collateral, only if by doing so the overall collateral ratio remains healthy.

So, if there is 10M ADA locked in iUSD with overall 300% collateral ratio, you can mint a 1K ADA with 110% collateral. But if you want to mint 30M ADA (pratically a 4x on the ADA locked in iUSD) you must mint with at least 150% collateral.

I suppose a “dynamic” collateral requirement would mean a new iteration of the protocol, but maybe something along these lines? Needing a global information on overall collateral could be an issue, so perhaps something with a similar effect but dealing with “local” information.


this is one proposal ill be tracking

1 Like

I think anyone who has seriously thought through the 110% MCR of iUSD, and why the team chose this controversial threshold understands they did it with the best of intentions. The desire to limit a highly possible scenario of an upside depegging to roughly 1.10.

However, i agree with zygo here. The choice here is between:

  1. higher probability upside depegging …and
  2. The (possible tho less likely) failure of liquidation to occur prior to the 100% boundary. This failure would leave liquidators at a loss.

There r definitely scenarios here that could happen. It feels like the team is highly confident in the liquidation mechanism. Even tho 2 is less likely, it would reslly tarnish the brand/reputation of not only Indigo but all of Cardano defi as Indigp is the first non-DEX DeFi dApp.

Tbh i like what indigo is doing, i like their constitution and governance structure. This is why zygo can publish this. But i do think they made the wrong decision here.

I would support 130, 125, anything above 110. Please keep iUSD safe, we need it.


What are your thoughts on a soft and hard MCR.

Hard MCR can stay at 110% and is exactly what the existing mechanism is.

Soft MCR is > Hard MCR, say 125%. If a CDP falls below the soft MCR, anyone can liquidate that CDP, but at little to no liquidation cost to the CDP. Anyone can liquidate any portion of your CDP.
Liquidators would only do this if iAsset (iUSD) is trading at a discount to the oracle price. So they would by on a DEX at a discount, and liquidate some or all of the CDP. The CDP owner would be made whole with their collateral because they did not breach the hard MCR threshold. The arb’er gets the spread of the discounted iUSD.

This would help protect the downside depegging. If you add a small liquidation fee, it may help with low upward depeggings. but not large ones.

1 Like

110% is pretty low. Issue is we have to make sure everyone knows about the change before making it or a lot of people will get liquidated.


I like your thinking. You’re on the right track here. There are better ways to ensure protocol solvency than to fixate on the specific MCR value (most of which are arbitrarily suggested). However, these features will require significant development effort.


What makes you think this?

Why 130? Why 125? How did you come up with these arbitrary numbers?

We’re in this for the long term. We’ve been building Indigo for almost two years, and would hate for it to be exploited. It’s in all of our best interests for iUSD to be safe.


This can easily be placed as a notice in the web app. Everyone using Indigo should know that MCR can be changed via governance. As for how many people will be liquidated, this is easily measurable, and the number is (currently) very low.

Totally fair. Though i do think that if we believe we as a community need to consider additional ways to ensure safety of liquidators (which im my mind means safety of pegs), we need to find ways to do that.

I dont have the time or resources to model this.

And to be honest i dont think it is modelable. We r talking about edge cases and modeling user behavior which will be irrational. I picked 130 and 125 solely because they r > 110, i dont have any support to back that up.

Honestly i believe the burden of proof is on the owner. I would love to see ur analysis on why 110 is correct.

And i believe all this is an edge case during bear market irrationality.

Zygos example in the discord chat is not impossible. Say even tho aversge CR > 300, someone comes in and enters into a CDP at CR of 110, and the size is > the current stability pool.

Say ADA tanks 20% before the oracle updates or before liquidation csn occur (possible tho unlikely).
The stability pool will not only be wiped out but at a loss (from the liquidation). U need INDY yield to offset this (which means poeple will sell indy to make themselves whole from the loss).
Now we have a bad scenario where stability pool loses money. People will be skeptical to deposit iAsset to the stability pool again now.
Iasset will still be backed by sufficient collateral, but trust in the system has been damsged greatly.

We need to be very careful and preventive of losses to stsbility pools.

Stability Pools are designed to be profitable most of the time at the cost of being exposed to low-risk of losing funds. The edge cases you’re describing are examples of this risk playing out. As in, most of the time a Stability Pool staker should be profitable, and sometimes they’ll lose money. This is by design and we don’t need to ensure that Stability Pool stakers will always make money. It should be well known that Stability Pool stakers are exposed to risk (albeit small).

If these edge case risks become more probable, or even after they’ve been exploited, then I would consider increasing the MCR. By increasing the MCR, profit for Stability Pool stakers is increased, affording them the ability to consume bad debt.

If people leave the Stability Pool, then INDY yield is increased automatically. This of course may create sell pressure on INDY, but it still serves as an incentive to bring liquidity back into the Stability Pool. Ultimately, long term stability of the system is what will lead to buying pressure on INDY.

Confidence in the system is predominantly dictated by iAssets maintaining their pegs. Even in the case of bad debt entering the system, downwards depegging is prevented. As iAsset prices fall, it further incentives CDP owners to close their positions due to increased profit. It further incentives new users to enter the Stability Pool to take on the bad debt. This causes buying pressure on the iAsset to bring it back to its peg.

Increasing MCR at this stage of the protocol’s life isn’t justifiable. What is being proposed here is to increase a known exposure to depeg upwards, and to decrease risk of Stability Pool stakers and possibly minimizing a risk of a recoverable downwards depeg. Therefore, we’d sacrifice trust and longevity in the system by purposefully depegging iUSD for practically no benefit.


Good proposal. I will follow the developments for voting on this proposal.

agreed, some people are equating minimum collateral ratio to the expected collateral ratio of the pool. the stability pools and other mechanisms incentivize the overall collateral to be far greater than 330%.

1 Like

Yes, with an average CR above 330% and a mode CR above 180%, the CDPs are highly stable. If the mode CR dropped to be 135% then we’d definitely need to increase MCR. I’m pulling the 135% number from our CDP risk assessment chart.

As of right now, it’s premature to increase MCR. The INDY incentives haven’t even started yet and we’ve already got good stability pool saturation.


Is there some sort of way to make it impossible to fund below 140% MCR for assets when protocols overall avg MCR is 135% or below? This could help to find a middle ground for incentivizing funding while keeping overall CR of protocol safe