Submitted by oakcobalt
In LidoEthBaseInterestAllocator.sol, getLidoData is initialized with an incorrect timestamp, causing subsequent baseApr to be incorrect.
In constructor, getLidoData is initialized with 0 timestamp. This should be block.timestamp instead. As a result, baseApr updates will be much lower:
https://github.com/code-423n4/2024-04-gondi/blob/b9863d73c08fcdd2337dc80a8b5e0917e18b036c/src/lib/pools/LidoEthBaseInterestAllocator.sol#L62
For example, in _updateLidoValue(), _lidoData.aprBps is calculated based on delta shareRate, divided by delta timespan. (_BPS * _SECONDS_PER_YEAR * (shareRate - _lidoData.shareRate) / _lidoData.shareRate/ (block.timestamp - _lidoData.lastTs)) shareRate and _lidoData.shareRate are associated with current timestamp, and deployment timestamp respectively. But timespan would be (block.timestamp - 0). This deflated _lidoData.aprBps value, which is used to validate Loan offers in Pool.sol during loan initiation.
In PoolOfferHandler.sol, this allows loan offers with substantially low aprBps to pass the minimal apr check.
https://github.com/code-423n4/2024-04-gondi/blob/b9863d73c08fcdd2337dc80a8b5e0917e18b036c/src/lib/pools/PoolOfferHandler.sol#L165
Loans with invalid aprs can be created.
Use block.timestamp to initialize getLidoData.
Error
0xend (Gondi) confirmed
0xA5DF (judge) decreased severity to Medium and commented:
Gondi mitigated:
Status: Mitigation confirmed. Full details in reports from oakcobalt, minhquanym and bin2chen.
For this audit, 3 reports were submitted by wardens detailing low risk and non-critical issues. The report highlighted below by minhquanym received the top score from the judge.
The following wardens also submitted reports: oakcobalt and bin2chen.
