[CONTRACTS] - Implement Debt Cycle Timeout Condition

[j-dfq]

Ubiquity's algorithmic dollar is not epoch-based, but is built around arbitrarily long or short debt cycles which adaptively modify the stabilization algorithms at play. Currently, the length of debt cycles depends on the TWAP crossing $1, whether decreasing or increasing in price. Because of this, the debt cycle can - in theory - never actually complete, or continue for an arbitrarily long enough time that would ultimately lead to destabilizing downstream effects on the protocol.

Although the epoch-less nature of the protocol offers many potential upsides with respect to adaptively dynamic algorithms acting on an effectively 'continuous' basis. However, the fact that debt cycles are arbitrarily long entails potential stability issues with respect to the debt algorithms that requires the debt cycles to end in order to trigger.

A design for a debt cycle timeout condition should be identified and implemented which would both rectify this potential stability vulnerability, while also respecting the epoch-less and continuous nature of Ubiquity's protocol.

[j-dfq]

Input from Alex: one potential design for the reset condition could use volatility data/analysis, similar to RAI's reflexivity index. Alternatively, it could utilize or compute other parameters that would be positively associated with potentially destabilizing activities.

It is also worth noting that multiple cycle reset conditions could be implemented. For example, a volatility evaluator in addition to a super long-scale timeout (e.g. 30 days).

[hpiyankov]

The core question is the following: when do we want to reset the debt cycle (e.g. mint more tokens outside of our normal process)?

For me the answer is: when our price is stuck above 1 USD for a long time. It does not matter if it oscillates and it does not matter if it is perfectly still.

What we don't want is:

• This to be predictable
• Maybe we don't want to do this if the price is currently changing rapidly

Refleisivty index or volatility one do not solve the issue. What we want is a function which:

• gives PROBABILITY of a debt cycle reset
• the probability goes up as the "time list last mining of uAD"goes up
• the probability goes down as the price slope of the token over period X goes up

The above should sove what we want to achieve. @pavlovcik @j-dfq thoughts?

[hpiyankov]

@pavlovcik ping. Comments on the above?

[0x4007]

That sounds good we just need to figure out the implementation details. For example, should we use Chainlink VRF (Verifiable Random Function) in our probability function or is there a better solution that's on chain? And then we need to figure out what transaction to piggy back off of to invoke this.

Also if the price is below 1.00 then we should have the system buy back with the collateral with some similar probability function.

[hpiyankov]

@pavlovcik those are 2 separate issues. Let's not contaminate the discussion. If you need we can have a separate issue regarding the buyback. @marcomow

Do you need me to work on the function and/or the transaction to piggyback on?

[0x4007]

Yes if you can work on the function and decide the best transaction to piggyback on that would be fantastic. Thanks @hpiyankov!

[hpiyankov]

@pavlovcik did some more research and thinking on this. Let's go over the problem once again.

Problem: if our price hovers above a dollar for a long time, our system can get "stuck" e.g. stop minting.
Proposed solution: after x amount of time above 1 USD, the system is re-set (the block when the last price was 1 is set to the current block so that in the next block we can mint the difference between 1 and the current price), e.g. the mint cycle can begin anew.
Counter argument: we want the protocol to be epoch-less and also we are worried about attack vectors on the protocl if the reset date is known up-front.

We end up with two options:

Option 1: Simple - the protocol can reset the debt cycle after X blocks of no minting & the price being above 1 USD. The reset is done by a person calling a function. Why would the person call the function? Because if he is a debt holder or bonding participant he would get rewarded.

Option 2: Complex - between X and Y blocks of no minting & the price being above 1 USD, we need to come up with a function that represents a probability distribution of the debt cycle being reset. In order to get this, we will need to call Chainlinks verifiable random oracles. Furthermore this function needs to piggyback on another transaction, which brings us to two more scenarios:

1. The price is stuck and we have protocol activity (which is fine)
2. The price is stuck and we have low protocol activity. In which case the price reset might come very late.

Where do we go from here:

To me, it seems that having a continuous probability distribution function is a total overkill in this scenario and serves no other purpose than "being fancy". It is a solution without a problem. I suggest that we go with Option 1 - a simple timeout unless there is a really good argument for overengineering a theoretical situation that we have not even arrived at.

@pavlovcik opinions?