Research: overcollateralization mechanic

[rndquu]

There is only one audit's issue that we haven't fixed yet: sherlock-audit/2023-12-ubiquity-judging#60

This is not critical but during a black swan event it will make the pool insolvent to some extent. We should add the overcollateralization mechanic (similar to DAI, CRVUSD or LUSD) which is much more resistant to sudden collateral depegs.

This is a research issue, as a result we should get a detailed step by step guide of what audited contracts we should fork/revamp and how they fit (i.e. how we should use them) in the overall Dollar protocol architecture.

When the overcollateralization mechanic is implemented we could:

1. Pause the Ubiquity pool used by arbitrageurs (and allow operations with Dollar tokens only on secondary markets)
2. Rely only on the overcollateralization mechanic for the Dollar token USD peg which is much more resistant to sudden collateral depegs

[0x4007]

Any idea on time estimate?

[rndquu]

Any idea on time estimate?

I've updated the description, time estimate is fine

[999bits]

@rndquu So this issue is being caused by sudden price pump?
Like the AMO doesn't sensitively balance the supply for a moment
Would like to hear more about what is the approx depegged price of uAD

[999bits]

@rndquu @pavlovcik To resolve this, we should apply a major change to protocol contracts I guess,
Since the ubiquity idea and the code written somewhat don't align overcollateralized concept,
so what I'm thinking about is introducing the tick on minting (a tick would be 0.001$) and if the current price is out of the tick window(of maybe 10 or 20 ticks for any direction from the highest tick), liquidity pool can reject mint/redeem action temporarily

[0x4007]

we should apply a major change to protocol contracts I guess,

This doesn't seem like a good approach. We should aim to make minimal changes to our protocol, especially because we just paid for an audit.

[molecula451]

Indeed not a good approach

[999bits]

@pavlovcik @molecula451 I understand your concern
So do you have any ideas of which minor change would satisfy our needs?

[molecula451]

This is a research issue with different approaches on how to handle an "overcollateralization mechanic" or a possible exploit of the underlying system that allow us to handle very well own and user assets

[rndquu]

@999bits

So this issue is being caused by sudden price pump?

Yes, check:

• cergyk - UbiquityPool::redeemDollar No guarantees of pool solvency sherlock-audit/2023-12-ubiquity-judging#60
• cergyk - UbiquityPool::mintDollar/redeemDollar collateral depeg will encourage using UbiquityPool to swap for better collateral sherlock-audit/2023-12-ubiquity-judging#17
• shaka - The depegging of the collateral token from the USD could result in the Ubiquity Dollar token being undercollateralized sherlock-audit/2023-12-ubiquity-judging#19
• ...other related issues

Like the AMO doesn't sensitively balance the supply for a moment

We don't use any AMOs right now

Would like to hear more about what is the approx depegged price of uAD

Take the FRAX token to see expected price fluctuations

To resolve this, we should apply a major change to protocol contracts I guess

We should take any audited stablecoin contract with overcollateralization mechanic and apply it to the project

[999bits]

@rndquu @pavlovcik
Afaik, one of the traditional overcollateralized CDP solution is Liquity
And they introduced stablity pool as the first line of defense, where liquidity comes from SP liquidity provider and liquidated troves, fyi
I'm curious if we can approach this way
And their contract have been audited for sure,

[0x4007]

Given that we are not a CDP protocol its not possible

[rndquu]

Given that we are not a CDP protocol its not possible

This issue implies adding CDP mechanic to the protocol, similar to how Maker generates DAI, so LUSD should definitely have related contracts

[0x4007]

I don't understand the issue with FRAX's economic model. I'm also not open to this direction, unless it's intended to be some type of internal mechanism for us to create some type of small "insurance" policy. To be honest I don't really understand the vision here.

Seems useless to only support CDP for a stablecoin

[0x4007]

@rndquu I re-read the original audit proposal and as I understand, we should allow redeems only below $1.00 and mints above $1.00. Wouldn't this be mathematically impossible to have the proposed problem with insolvency? I feel that I am not understanding the problem.

[email protected] -> redeem 10 LUSD using 10 UUSD

or

[email protected] -> mint 10 UUSD using 10 LUSD

If UUSD is worth $0.50, using 10 UUSD to redeem should not give the user 5 LUSD, it should always be 10 LUSD. That's how we keep the peg.

If UUSD is worth $2.00, redemptions should be disabled. Instead the user should sell on the market.

[rndquu]

we should allow redeems only below $1.00 and mints above $1.00. Wouldn't this be mathematically impossible to have the proposed problem with insolvency?

Chainlink oracles update faster than curve's TWAP (that is used for checking UUSD price) hence it is possible in theory to mint with UUSD < $1.00 and redeem with UUSD > $1.00. Although in a very rare case.

unless it's intended to be some type of internal mechanism for us to create some type of small "insurance" policy

We could transfer AMO yield to the pool which could serve as a "small insurance policy".

[rndquu]

Aave solves the same issue of possible insolvency (if liquidations/oracles are late or in case of a smart contract bug) via a safety module.

How it works:

1. Users stake AAVE or AAVE/ETH Balancer LP (for deepening AAVE liquidity) tokens in the Safety Module which basically a staking contract where users get AAVE rewards
2. In case there's an insolvency then up to 30% of staked assets are slashed and sold on a secondary market to cover the protocol insolvency
3. In case step 2 doesn't cover all losses aave has another module called "Recovery Issuance" which simply mints AAVE tokens out of thin air until the protocol is not solvent again

I understand that current issue is improbable but I still don't want to close it since if we acquire a decent amount of liquidity and face a too volatile marker which would make the ubiquity pool undercollateralized then somebody would find this github issue and make another https://rekt.news/ post out of it.

[0x4007]

I think copying AAVE as sort of a "default answer" is acceptable. They have a good security track record.