WATCHPUG - New orders should request for a new oracle version at `currentTimestamp` (the next whole hour) instead of the current time (`block.timestamp`)

[sherlock-admin]

WATCHPUG

high

New orders should request for a new oracle version at currentTimestamp (the next whole hour) instead of the current time (block.timestamp)

Summary

Vulnerability Detail

Oracle#request() will be called whenever the user creates a new order. However, in the current implementation, while it records the oracles[global.current].timestamp as the currentTimestamp returned from the oracle provider's status() function (which should be the next whole hour time), the actual price/version requested was the current time (block.timestamp) instead.

For example, an order created at 10:24 records the oracles[global.current].timestamp as 11:00 but the actual requested price update time is 10:24.

Unless there is an order submitted at 11:00, this order will most certainly be invalidated.

Or maybe someone will call PythOracle#commit() to deliberately commit the price for 11:00, but this function is disincentivized. Only the requested price will get the keeper fee.

Impact

Almost all orders will get invalidated.

Code Snippet

https://github.com/sherlock-audit/2023-07-perennial/blob/main/perennial-v2/packages/perennial-oracle/contracts/Oracle.sol#L35-L41

https://github.com/sherlock-audit/2023-07-perennial/blob/main/perennial-v2/packages/perennial-oracle/contracts/pyth/PythOracle.sol#L77-L81

Tool used

Manual Review

Recommendation

New orders should request a price update at currentTimestamp (the next whole hour). A settlementFee should only be charged when it is the first request to that timestamp.

Duplicate of #42

[sherlock-admin]

2 comment(s) were left on this issue during the judging contest.

141345 commented:

d

panprog commented:

should be low or medium because no funds loss is shown