The protocol uses the WiseOracleHub contract to compute the value of each token by calling the getTokensInETH function. Inside there, the high overview is that it takes the Chainlink price feed for the token in terms of ETH and a TWAP computation of the price of the asset. Having these 2 results, the difference is calculated and if it is greater than 2.5% the call is reverted.
Chainlink price feeds have a parameter called deviation threshold, depending on the asset and its volatility, it is greater or smaller. Normal values are 0.5% - 2%. This parameter determines the threshold in which the price feed will update his current price or not. For example, if a price feed has a deviation threshold of 1%, it means that if the current price is 100 ETH, if the price does not go higher than 101 or lower than 99, the price will not be updated. From the assets in scope, there is the BTC/ETH price feed which has a 2% deviation threshold.
This feature can collude with the 2.5% price discrepancy and bring an asset pool into a DoS during a whole hearthbeat. That is because the price feed will not update if the price has not change in a range of [-2%, +2%]. For price feeds with a 1% deviation threshold, a 2.5% discrepancy price fits good, however, for higher deviation thresholds can often lead to a denial of service of the token pool.
Tools Used
Manual review
Recommended Mitigation Steps
From my point of view, the discrepancy price should be variable depending on the asset. For low volatility assets, it is good if it is low, however, for more volatile assets it can often lead to DoS. For this reason, I would recommend to adjust this parameter on pool creation time depending on the asset. For the price feeds with a deviation threshold of 2% I would recommend a minimum of 5% price discrepancy.
Lines of code
https://github.com/code-423n4/2024-02-wise-lending/blob/main/contracts/WiseOracleHub/OracleHelper.sol#L131-L174
Vulnerability details
Impact
The protocol uses the
WiseOracleHub
contract to compute the value of each token by calling thegetTokensInETH
function. Inside there, the high overview is that it takes the Chainlink price feed for the token in terms of ETH and a TWAP computation of the price of the asset. Having these 2 results, the difference is calculated and if it is greater than 2.5% the call is reverted.Chainlink price feeds have a parameter called deviation threshold, depending on the asset and its volatility, it is greater or smaller. Normal values are 0.5% - 2%. This parameter determines the threshold in which the price feed will update his current price or not. For example, if a price feed has a deviation threshold of 1%, it means that if the current price is 100 ETH, if the price does not go higher than 101 or lower than 99, the price will not be updated. From the assets in scope, there is the BTC/ETH price feed which has a 2% deviation threshold.
This feature can collude with the 2.5% price discrepancy and bring an asset pool into a DoS during a whole hearthbeat. That is because the price feed will not update if the price has not change in a range of [-2%, +2%]. For price feeds with a 1% deviation threshold, a 2.5% discrepancy price fits good, however, for higher deviation thresholds can often lead to a denial of service of the token pool.
Tools Used
Manual review
Recommended Mitigation Steps
From my point of view, the discrepancy price should be variable depending on the asset. For low volatility assets, it is good if it is low, however, for more volatile assets it can often lead to DoS. For this reason, I would recommend to adjust this parameter on pool creation time depending on the asset. For the price feeds with a deviation threshold of 2% I would recommend a minimum of 5% price discrepancy.
Assessed type
Oracle