Research: overcollateralization mechanic

[rndquu]

There is only one audit's issue that we haven't fixed yet: https://github.com/sherlock-audit/2023-12-ubiquity-judging/issues/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?

[ubiquibot[bot]]

! action has an uncaught error

[0x4007]

It said it can't find you under memberships which caused the issue with the labels. I'm not sure why that would be.

! action has an uncaught error

{ "handlerType": { "type": "post", "actions": [ null ] }, "activeHandler": "onLabelChangeSetPricing", "error": { "name": "HttpError", "status": 404, "response": { "url": "https://api.github.com/orgs/ubiquity/memberships/ubiquity", "status": 404, "headers": { "access-control-allow-origin": "*", "access-control-expose-headers": "ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset", "content-encoding": "gzip", "content-security-policy": "default-src 'none'", "content-type": "application/json; charset=utf-8", "date": "Tue, 05 Mar 2024 20:45:39 GMT", "referrer-policy": "origin-when-cross-origin, strict-origin-when-cross-origin", "server": "GitHub.com", "strict-transport-security": "max-age=31536000; includeSubdomains; preload", "transfer-encoding": "chunked", "vary": "Accept-Encoding, Accept, X-Requested-With", "x-accepted-github-permissions": "members=read", "x-content-type-options": "nosniff", "x-frame-options": "deny", "x-github-api-version-selected": "2022-11-28", "x-github-media-type": "github.v3; format=json", "x-github-request-id": "80F0:1594:C4C476:17BF07B:65E78473", "x-ratelimit-limit": "7150", "x-ratelimit-remaining": "6923", "x-ratelimit-reset": "1709672691", "x-ratelimit-resource": "core", "x-ratelimit-used": "227", "x-xss-protection": "0" }, "data": { "message": "Not Found", "documentation_url": "https://docs.github.com/rest/orgs/members#get-organization-membership-for-a-user" } }, "request": { "method": "GET", "url": "https://api.github.com/orgs/ubiquity/memberships/ubiquity", "headers": { "accept": "application/vnd.github.v3+json", "user-agent": "probot/12.3.3 octokit-core.js/3.6.0 Node.js/20.11.0 (linux; x64)", "authorization": "token [REDACTED]" }, "request": {} } }, "caller": "renderCatchAll", "revision": null }

[molecula451]

It said it can't find you under memberships which caused the issue with the labels. I'm not sure why that would be. I have notice this error comes when altho members try to perform the actions they can't see the

I have notice altho members the bot does not react to member users that can't see the settings on x repo, e.g i can see the settings at audit.ubq.fi so the bot reacts to me

Cannot see this in dollar:

[0x4007]

Perhaps it's a weird permissions inheritance issue. You were added directly to the repo but you also are added to the org. I just removed you from the repo so now your permissions should be "normal" inherited from the org like the rest of us.

[molecula451]

Perhaps it's a weird permissions inheritance issue. You were added directly to the repo but you also are added to the org. I just removed you from the repo so now your permissions should be "normal" inherited from the org like the rest of us.

Even tho im added, looks like an issue indeed, hopefully we find that fix!

[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:

• https://github.com/sherlock-audit/2023-12-ubiquity-judging/issues/60
• https://github.com/sherlock-audit/2023-12-ubiquity-judging/issues/17
• https://github.com/sherlock-audit/2023-12-ubiquity-judging/issues/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.

UUSD@0.99 -> redeem 10 LUSD using 10 UUSD

or

UUSD@1.01 -> 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.