SJIP 16: Clarify future integrations and invariants in the README and Judging Rules

[WangSecurity]

Description

Re-phrase the question about future integrations and README invariants

Judging Guidelines PR

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

Rationale

I propose a change in the "Future Integrations" question. Here's the current version:

Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold?

Firstly, it brings confusion about what the future integrations are. The goal here is about the other protocols integrating with the contest codebase in the future, not the contest codebase integrating with other protocols. Secondly, it leaves the window for the protocol to answer "Yes" which gives us no specific information. This results in Watsons submitting issues that should be out of scope, based on rules, but claim they should be valid. We always encourage the protocol to either give the exact invariants/properties or answer "No", but there were a couple of situations where a "Yes" answer went through leading to the following outcomes:

1. It worsens their issue validity ratio.
2. Increase the length of escalations.

Honestly, I don't remember if we had a very solid case where the protocol actually used this question for protocols integrating with them in the future (only 1-2).

Another problem is in the following part of the Rules:

The protocol team can use the README (and only the README) to define language that indicates the codebase's restrictions and/or expected functionality. Issues that break these statements, irrespective of whether the impact is low/unknown, will be assigned Medium severity. High severity will be applied only if the issue falls into the High severity category in the judging guidelines.

Apart from the similar problems as with the "Future Integrations" question, this line leads to low-impact issues being rewarded even if they don't have value for the protocol.

Hence, I propose to change the "Future Integration" question to the question about protocol invariants. This way, broken invariants from that question will be assigned Medium severity, irrespective of the impact being low/unknown.

Here's the changed question:

What properties/invariants do you want to hold even if breaking them has a low/unknown impact?

And the changed description:

For example, the invariant is the amount of the underlying tokens must equal the amount of vault tokens. Even if breaking this invariant has a low impact, it will be assigned Medium severity. You can answer "No" if there are no specific invariants you want to hold.

Here's the changed part of the README:

The protocol team can use the README (and only the README) to define language that indicates the codebase's restrictions and/or expected functionality. Additionally, the protocol team can use only the following question to define the protocol's invariants/properties:

What properties/invariants do you want to hold even if breaking them has a low/unknown impact?

Issues that break the invariants from the above question, irrespective of whether the impact is low/unknown, will be assigned Medium severity. High severity will be applied only if the issue falls into the High severity category in the judging guidelines

I believe this SJIP will fix both problems and remove friction from the README and Docs, leading to rewarding only valuable issues and Watsons not getting rewarded for non-valuable reports.

Relevant Issue Discussions

sherlock-audit/2024-05-beefy-cowcentrated-liquidity-manager-judging#7

sherlock-audit/2024-04-xkeeper-judging#58

[sharonphiliplima]

Cool

[gjaldon]

It looks like a good change to me 👍🏼