The LibChainlinkOracle intends to use the lookback parameter to return the Time-Weighted Average Price (TWAP) from the Chainlink Oracle over the past specified seconds. However, due to faulty logic, this value is never actually used.
Currently, the contract contains a logical error where it checks if the lookback is greater than zero. If lookback is greater than zero, it does not use the lookback value. Conversely, if lookback is zero, the contract incorrectly uses the getTwap function, which returns the first price fetched from the oracle instead of the intended TWAP.
A 2nd issue is that there is no minimum value determined for the lookback. As the project will be deployed on L2, there is a chance that the block.timestamp can cause the project to use a lookback very low like 1 second.
Example on Arbitrum:
"block timestamps are usually set based on the sequencer's clock. Because there's a possibility that the sequencer fails to post batches on the parent chain (for example, Ethereum) for a period of time, it should have the ability to slightly adjust the timestamp of the block to account for those delays and prevent any potential reorganisations of the chain. To limit the degree to which the sequencer can adjust timestamps, some boundaries are set, currently to 24 hours earlier than the current time, and 1 hour in the future."
When calling sunrise, the following logic is used to set the lookback on LibWellMinting
As shown above, in a L2 the scenario where block.timestamp.sub(s.sys.season.timestamp) can result in a very low number in seconds. i.e: 1-10 secs or a This will impact the reliability of Beanstalk on the TWAP price returned from the Chainlink Oracle.
Notice that in LibUsdOracle the docs mention the following:
There is no check in place to guarantee this protection against manipulation.
The faulty lookback parameter affects Beanstalk's reliance on accurate TWAP for its operations. This can cause incorrect pricing data, resulting in mispricing and potential financial risks.
The TWAP function's susceptibility to very low lookback values compromises price accuracy and increases the protocol's exposure to price manipulation.
Manual Review
Use lookback when its value is > 0.
Ensure the minimum value for lookback when its value is > 0.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.