notional-labs / UltraStableJuno

Decentralized stablecoin on Juno Network.
MIT License
10 stars 6 forks source link

Oracle Fault Tolerance #10

Open mccallofthewild opened 2 years ago

mccallofthewild commented 2 years ago

Overview

In even of a chain halt, IBC oracle light client expiration, or other information expiration events, how do we expect the system to respond, and how can we design it to respond in anti-fragile ways?

Jammyaa commented 2 years ago

I think the most vulnerable place when unexpected events occur is the logic that determines the price of asset pairs. I think we have to have a backup price source. For example, in case the MAIN oracle fails to respond for more than 2 hours, our system will use a RESERVE oracle source, and if possible, for returning to MAIN oracle if/when it recovers. As a more detailed example, we can let the system determine the price depending on the IBC query from Band Protocol (1), in case (1) error or timeout, the system will automatically get the price from JunoSwap Oracle (2) (backup price source) until (1) resumes operations. Hopefully (2) does not fail concurrently with (1). :))

mccallofthewild commented 2 years ago

Off-thread discussion:

We also need to account for chain halts. During which, the junoswap oracles will also be incorrect

Scenario: chain halts for 3 days. Juno price drops 50%. When the chain goes back online, anyone can take out a loan using 50% of the actual required collateral

Outcomes

1. Oracle Redundancy

Per above and #17, we will use a backup oracle in instances of oracle failure. Scenarios where this could happen include:

TWAPs are manipulable and will be inaccurate upon recovery from a chain halt, so it would be optimal if we had a secondary independent oracle.

2. Hibernation Mode

If the price feed has not received an update from any oracle in 6 (open to discussion) hours, the system enters Hibernation Mode to defend against opportunistic borrowing/redemption/liquidation at inaccurate rates.

The simplest version of hibernation mode just pauses these mechanisms.

A more advanced variant would apply easing functions to exponentially increase/decrease fees and collateral ratios over time as the average time since last oracle update increases/decreases.