Closed c4-submissions closed 11 months ago
raymondfam marked the issue as sufficient quality report
raymondfam marked the issue as duplicate of #32
raymondfam marked the issue as not a duplicate
raymondfam marked the issue as duplicate of #843
fatherGoose1 marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2023-11-kelp/blob/c5fdc2e62c5e1d78769f44d6e34a6fb9e40c00f0/src/interfaces/IPriceFetcher.sol#L1-L10 https://github.com/code-423n4/2023-11-kelp/blob/c5fdc2e62c5e1d78769f44d6e34a6fb9e40c00f0/src/LRTOracle.sol#L1-L110
Vulnerability details
Impact
The
IPriceFether.sol
interface and theLRTOracle.sol
will be, as described by the sponsors, provider agnostic, meaning it should be able to be integrated with any oracle service to provide up-to-date prices. But also, as mentioned by the sponsors, initially Chainlink's pricing oracles will be used, which sometimes can come with unexpected behaviors, depending on token pairs.Proof of Concept
The problem arises from the oracles stETH/ETH, cbETH/ETH and rETH/ETH, that would be the ones in use, since these are the main LSTs that will be compatible with the protocol. The minting mechanism of rsETH is highly dependent on the answers from these oracles and having them provide data every 24 hours opens the possibility of stale data, impacting how much rsETH a user could mint
Tools Used
Manual Review
Recommended Mitigation Steps
In case of Chainlink implementation, instead of directly referencing LST/ETH oracles, do LST/USD -> USD/ETH, since they are much more up to date.
Assessed type
Oracle