Operations could be blocked as they are calculated based on block timestamp and on arbitrum 2 blocks can have the same timestamp

[c4-bot-1]

Lines of code

https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WiseLending.sol#L225-L227 https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WiseLending.sol#L234-L237 https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/WiseLending.sol#L239-L242

Vulnerability details

In Arbitrum, block numbers and timestamps are reliable in long term but not reliable in short term, one invariant of the block timestamp (In Arbitrum ) is that is must always be greater or 'equal' with the previous block timestamp, taking that into consideration. If the max share price was already hit by the previous block it will not change in the next block if it will have the same timestamp( as it is calculated based on timestamp) so no new operations will be possible in that block.

Impact

If 2 or more consecutive blocks will have the same timestamp and the max share price was already hit, the deposits and borrow operations will fail.

Proof of Concept

Provide direct links to all referenced code in GitHub. Add screenshots, logs, or any other relevant proof that illustrates the concept.

Tools Used

Manual Review

Recommended Mitigation Steps

When calling the function _compareSharePrices, save the last block number details, and always compare the block numbers timestamp, if 2 different block numbers have the same timestamp apply a different logic when calculating currentSharePriceMax

Assessed type

Context

[c4-pre-sort]

GalloDaSballo marked the issue as insufficient quality report

[GalloDaSballo]

Funnily enough the comment states the old arbitrum functionality but the link disproves it

[GalloDaSballo]

Recommend closing the issue as invalid

[c4-judge]

trust1995 marked the issue as unsatisfactory: Invalid