Liquidations will be frozen if a token's oracle goes down or chainlink reverts call for any reason
Summary
Hubble only implements chainlink oracles, if any of these oracles goes down or any of the call reverts all liquidations or anything attached to querying chainlink would not possible, potentially DOSing all instances of querying that particular oracle in scope. isn't it reasonable to implement a query to chainlink in a try/catch incase this call is reverted and implement a fallback oracle?
Vulnerability Detail
Chainlink has taken oracles offline in extreme cases, which one could argue is to ensure that it wasn't providing inaccurate data to protocols as at the time they decide to take it down
In such a situation everything pertaining a call to chainlink would be inaccessible, i.e liquidations and every other logic where getting the price of a token is needed.
Impact
Normal operation of protocol can not be guaranteed, multiple DOS could be encountered, in the case of liquidations it could even be worse as these may not be possible at a time when the protocol needs them most. Resulting in the value of user's asset falling way below their debts, i.e in the case where oracle is down while the price of the asset is falling, this easily pushes the protocol into insolvency.
Provide a safeguard, after discussions with the sponsors the idea of a try/catch was accepted, and then an implementation of a fallback oracle in the case where chainlink is inacessible
Bauchibred
medium
Liquidations will be frozen if a token's oracle goes down or chainlink reverts call for any reason
Summary
Hubble only implements chainlink oracles, if any of these oracles goes down or any of the call reverts all liquidations or anything attached to querying chainlink would not possible, potentially DOSing all instances of querying that particular oracle in scope. isn't it reasonable to implement a query to chainlink in a try/catch incase this call is reverted and implement a fallback oracle?
Vulnerability Detail
Chainlink has taken oracles offline in extreme cases, which one could argue is to ensure that it wasn't providing inaccurate data to protocols as at the time they decide to take it down In such a situation everything pertaining a call to chainlink would be inaccessible, i.e liquidations and every other logic where getting the price of a token is needed.
Impact
Normal operation of protocol can not be guaranteed, multiple DOS could be encountered, in the case of liquidations it could even be worse as these may not be possible at a time when the protocol needs them most. Resulting in the value of user's asset falling way below their debts, i.e in the case where oracle is down while the price of the asset is falling, this easily pushes the protocol into insolvency.
Code Snippet
Oracle.sol#L106-L123:
Tool used
Manual Audit
Recommendation
Provide a safeguard, after discussions with the sponsors the idea of a try/catch was accepted, and then an implementation of a fallback oracle in the case where chainlink is inacessible