Debt Ceiling Mechanics

At the present the collateral debt ceiling is absolute. Example: ETH has a USD100m debt ceiling, irrespective of the USD value.

My question is: Would it not be better to have a relative debt ceiling expressed as a percentage and linked to the marketcap?

Example: ETH has a marketcap of USD 20 billion. Instead of a absolute debt ceiling of USD100 million, we could give it a floating debt ceiling of 0.5% of market cap?

The debt ceiling would be the same using both systems but the relative debt ceiling would be much more flexible. If ETH doubles in value, the debt ceiling measured i USD doubles automatically. Same if the price of ETH drops. In this way the debt ceiling for Vault collateral would be adjusted to market circumstances without increasing the Maker governance workload.

Are there any strictly technical reasons this would not work? Possibly too high reliance on oracles?

1 Like

First thing that comes to mind, you would need to replace the word ‘ceiling’ with something else.

Anyhow:
You cannot lower the ceiling below the current debt.

You would not need to lower the debt ceiling under total amount of current debt. Example: the ETH debt ceiling is USD100m and total debt for this asset is USD100m - it is in other words maxed out. During an event the price drops significantly (let’s say 20%), resulting in multiple Vaults being bitten. This will lower the total debt for this asset class. If debt ceiling mechanics (which may lag the price by a week or two) kicks in the debt ceiling is adjusted to lets say USD80m after a week or so unless the price has recovered in the meantime.

The above system will reduce the governance burden associated with having tens or even hundreds of assets types and manually having to adjust the debt ceiling for each of them as the assets grow or fall in value.

I don’t think it makes sense for the debt ceiling to fluctuate with market caps of the collateral since the borrowing collateral value is only relevant against the debt value (which is intended NOT to fluctuate via the PEG).

This unnecessarily complicates the contract for exactly what benefit?

1 Like

Can you really assume this step?

It is an assumption. It should however be fully possible to simulate it.

Very naive question here[Apologies if addressed in previous thread]:
Is it possible to denominate the ceiling in absolute nominal units of ETH [or in units of each type of collateral]?

Main thought was to eliminate rates of exchange and global supply of money.

Actually based on SCD actions during the last drop I can say for sure the following two things.

  1. Most people who actively manage their vaults don’t want to be liquidated
  2. Due to (1) what will happen is either a) more collateral will be deposited b) Debt will be paid down.

2b would be a case where one might want to lower the DC
2a would be a case where one WOULD NOT want to lower the DC

Personally I have advocated elsewhere a kind of floating rate based on the Debt utilization and the community voting for a SF target based on a 50% Debt utilization. My proposal suggested the Debt Utilization curve for the SF should be ~.5*SFtarget if the utilization is < 20% or 2xSFtarget if the utilization is > 80%. This would allow for a kind of floating rate that would manage utilization and the rates bounded by the debt utilization curves. It would also allow the rate to move towards the existing market via users.

Having a fixed rate for whatever amount of debt utilization leads to the need to unecessary management of the DC by the community. Same thing applies to the DSR. I would rather something like a fixed percentage of the incoming interest (say 50% for example) be set aside for the DSR again giving a kind of utilization curve payout to depositors since it guarantees MKR holders get a return, and DSR holders will self manage to match best available market rates for the risk exposure.

If one sets up a system to manage itself via proper feedback mechanisms - it will. Right now every parameter in the Maker system is fixed and is requiring constant community votes to adjust. I think in time this will lead to voter and community exhaustion for very little reward. It also leads to Maker rates being inflexible to market conditions and being used to arbitrage rates against other platforms.
The added bonus is that having utilization curve based rates will allow enough data to be collected regarding what the market thinks the risk exposure is for Maker compared to other platforms both on the borrow and supply side of the rate equations and will always allow for liquidity to be available (at some price) and to have utilization actively managed by users.

There are other issues here in relation to how quickly and accurately Maker can adapt their business model to the now fast changing DeFI space.