Chinmay - Oracle timeout will cause liquidations to fail

[sherlock-admin]

Chinmay

medium

Oracle timeout will cause liquidations to fail

Summary

Liquidations, repayments etc. depend on value returned by getCollPrice(). In certain cases, if oracle fails, this function will revert causing grief for users wanting to repay/should be liquidated.

Vulnerability Detail

The implementation of CustomOracleWrapper.sol shows that if the price returned by oracle nodes is older than the oracle timeout (currently 4 hours) , it reverts and thus doesn't allow liquidation/repayments. This will cause grief for the vault/user respectively. The debt will keep accruing on user's position and his position may go more and more underwater before the Oracle resumes.

This is amplified by the fact that the protocol uses custom data provided by its own node setup and we dont know about the number and coverage of these nodes.

Impact

In case of failed repayments, the user's position may keep going underwater increasing the final debt he has to pay. In case of failed liquidations, it adds bad debt for the whole vault and cause a liquidity crunch for withdrawls.

Code Snippet

https://github.com/sherlock-audit/2023-03-taurus/blob/main/taurus-contracts/contracts/Oracle/Wrapper/CustomOracleWrapper.sol#L53

Tool used

Manual Review

Recommendation

Once it is discovered by getCollPrice function that Oracle has timed out, the vault should pause all user positions( at the current amounts) that try to liquidate/repay and prevent accrual of debts for no mistake of theirs.

[Sierraescape]

Debts in Taurus do not accrue; in fact they decrease over time. Additionally, all liquidations and repayments are already paused when the oracle becomes stale.

The greater risk seems to be that if the price of collateral continues to fall while the protocol remains paused, the liquidation discount will continue to increase, and users will be unable to do anything about it. This is a systemic risk to Taurus (which will gain a lot of bad debt in this situation), and is an inherent issue with borrowing protocols in general. The best we can do is ensure that oracles never become stale in periods of volatility. We have done so with the GmxYieldAdapter, whose oracle cannot ever become stale.

In general we consider the risk of a stale oracle causing improper liquidations, or inaccurate liquidation/borrowing exchange rates, to be much greater than the risk that a user's position cannot be liquidated due to a stale oracle.