Closed howlbot-integration[bot] closed 3 months ago
oracle manipulation is the out of scope
The Warden outlines that the TWAP employed by Predy is less costly to influence due to the project's deployment on an L2, however, such an attack would still involve multi-block price adjustments that fall under the known risks of the protocol. As such, this submission is considered out-of-scope.
alex-ppg marked the issue as unsatisfactory: Out of scope
Lines of code
https://github.com/code-423n4/2024-05-predy/blob/a9246db5f874a91fb71c296aac6a66902289306a/src/libraries/UniHelper.sol#L35
Vulnerability details
Impact
The cost of manipulating the TWAP in L2 network is too low so TWAP should not be used in L2
Proof of Concept
Predy uses TWAP prices in places such as when liquidating a user. According to the information provided by the Uniswap team, as documented in the Uniswap Oracle Integration on Layer 2 Rollups guide, primarily addresses the integration of Uniswap oracle on L2 Optimism. However, it is relevant to note that the same concerns apply to Arbitrum as well. Arbitrum's average block time is approximately 0.25 seconds, making it vulnerable to potential oracle price manipulation.
Oracles Integrations on Layer 2 Rollups
In predy The Oracle period is even hardcoded to 30 mins which makes the manipulation much easy. And After getting the twap period it calculates the price of the already manipulated pool in here
Tools Used
Uniswap
Recommended Mitigation Steps
Fetch the oracle source from chainlink in place of twap
Assessed type
Uniswap