SJIP: Clarify Oracle Staleness

[WangSecurity]

Description

Clarify that the staleness rule is about any oracle, not only Chainlink, and add an example of the exception.

Judging Guidelines PR

https://github.com/sherlock-protocol/sherlock-v2-docs/pull/50/files

Rationale

Watsons flagged that the rule reads like it is only about Chainlink, while it's supposed to be about any oracle.

Additionally, added an exception case where such issues can be judged beyond the rules:
The protocol may be using Pyth pull-based oracle, which requires requesting the price before using it. Hence, if we don't request the price firstly, or check it for staleness, then we can end up using very old price (e.g. from 1 hour/day ago). Here's the issue that was validated in such a scenario, despite this rule.

Relevant Issue Discussions

sherlock-audit/2024-12-mach-finance-judging#41

[spacegliderrrr]

Instead of making the rule for any oracle and instantly introducing exceptions, consider making the rule for just Chainlink and Chainlink-like oracles (perhaps ones that fit the Chainlink interface?). This would help avoid further confusion and leave less room for judge interpretation on whether they should make an exception or not.

[WangSecurity]

Interesting idea, do you think something like the following would be better:

Chainlink Stale prices and round completeness checks Recommendations to implement round completeness or stale price checks for Chainlink or other oracles similar to Chainlink (push-based) are invalid

Do you think it requires an additional explanation of what is meant by "oracles similar to Chainlink (push-based)"?

[IllIllI000]

Chainlink is coming out with a pull oracle as well. I'd suggest limiting it to oracles where the api being called, or the network it relies on, already enforces a max age in some way. I'd also move the round completeness to a new rule since it's not related.

[WangSecurity]

About limiting to oracles where the API is being called, can you take a look at the above comment and share your opinion? About moving around completeness, do you think it can be in the same rule as these are all price freshness checks?

[IllIllI000]

Can you also take a look at these and comment on whether you think each would be valid or invalid after the change? They're all slightly different variations on the same theme, and would likely lead to an escalation without clarification:

• ak1 - DepositReceipt_Base.sol#L21 : HEARTBEAT_TIME gap is too huge sherlock-audit/2022-11-isomorph-judging#256
• 0x52 - chainlinkAdaptor uses the same heartbeat for both feeds which is highly dangerous sherlock-audit/2023-04-jojo-judging#449
• 0x52 - stETH/ETH chainlink oracle has too long of heartbeat and deviation threshold which can cause loss of funds sherlock-audit/2023-03-olympus-judging#2
• eeyore - Incorrect calculation of TWAP in OptionTokenV4.getTimeWeightedAveragePrice() function. sherlock-audit/2024-06-velocimeter-judging#298
• 0x52 - Adversary can sandwich oracle updates to exploit vault sherlock-audit/2023-03-olympus-judging#1

In some of the more recent contests, a lot of watsons are being rewarded for just saying 'stale price' or 'min/max not checked', without actually showing a valid attack, but they should be invalid according to duplication rules. Perhaps the rule should change to clarify that saying that is not enough, and specific examples from on-chain settings must be used, and an actual attack must be outlined.