Add delay before price update triggers Liquidation

[Chris-Hibbert]

What is the Problem Being Solved?

Vaults currently get added to the liquidation queue as soon as a triggering price update is received. There are several reasons why it would be better to wait and at least one reason not to.

This price must be usable elsewhere in vaults on checks against MCR and Liquidation.

Benefits

• the vault owner would have more time to rescue their vault (add collateral or pay back their debt). Avoiding liquidation should always be our preferred choice.
• It would reduce having the protocol overreacting to temporary price movements. This allows us to respond less often to transitory changes.
• It gives the protocol time to identify and mitigate oracle manipulation attacks. Oracle manipulation is a major attack vector, which is aggravated by reacting immediately to a price change.
• It reduces gas and oracle fees since we don't need to update the oracle price as often.

Limitations

In a rapidly declining market, liquidations occur at lower prices than if the response was quicker.

Description of the Design

UPDATES from COMMENT
After discussion with @rowgraus, the current design is that there will be a governed parameter PRICE_LOCK_PERIOD defining a time before the start of each auction at which the oracle price will be locked for purposes of liquidation. This will not be referenced by the auction. If auctions are scheduled to run every hour, and PRICE_LOCK_PERIOD is 20 minutes, then at 20 minutes before the hour, the oracle price will be captured (and published). At the top of the hour (or a few minutes earlier to allow the work to be complete before the auction starts) the vaultManagers will liquidate vaults according to that locked price and send the resulting collateral to the auction.

All of the prices used as the triggers are from oracles reporting averages over observations from multiple sources. The locked price is neither more nor less reliable than the momentary observation of the "current" price. The lock price is neither more nor less manipulable.

Security Considerations

Has economic implications, but not much security relevance.

Test Plan

In addition to unit tests, we should include this functionality in our economic exercises.

[Tartuffo]

One possible default value for delay time: 1 hour. Per new MD oracle network liquidation default.

[dtribble]

The security relevance is that it protects against oracle bugs/attacks because it gives time to respond to incorrect oracle signals. However that also requires hooks to allow such response (e.g., preventing inappropriate liquidation)

[Chris-Hibbert]

After discussion with @rowgraus, the current design is that there will be a governed parameter PRICE_LOCK_PERIOD defining a time before the start of each auction at which the oracle price will be locked for purposes of liquidation. This will not be referenced by the auction. If auctions are scheduled to run every hour, and PRICE_LOCK_PERIOD is 20 minutes, then at 20 minutes before the hour, the oracle price will be captured (and published). At the top of the hour (or a few minutes earlier to allow the work to be complete before the auction starts) the vaultManagers will liquidate vaults according to that locked price (unless the current price at the liquidation deadline is higher, in which case the higher price will be used) and send the resulting collateral to the auction.

A case can be made that the locked price should be used regardless of rising prices, but this is the default approach.

All of the prices used as the triggers are from oracles reporting averages over observations from multiple sources. The locked price is neither more nor less reliable than the momentary observation of the "current" price. The lock price is neither more nor less manipulable.

[rowgraus]

Updated description to be clear we are using the locked price for liquidation regardless of whether price has recovered. We need a clear signal to the market.

[Chris-Hibbert]

As of #7000 and #7047, the auction has a governed param PriceLockPeriod. It controls how long before each auction starts that VaultManagers should capture a price from the oracle.