Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion CONTEST_QA_README.csv
Original file line number Diff line number Diff line change
Expand Up @@ -14,11 +14,12 @@ Example answer:
"Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?","Same as above, except this applies to access-restricted functions of protocols you integrate with.

It is common to answer ""No,"" as protocols typically trust the governance of the protocols they integrate with.",4
Is the codebase expected to comply with any specific EIPs?,"Please explain the underlying intention behind integrating with each EIP, and how compliance with these EIPs aligns with your protocol's goals.",5
What EIPs the codebase is expected to comply with if any?,"Note that the EIP-compliance issues will be considered Medium severity even if the actual impact is low/unknown even in view functions.",5
"Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.","Please provide information on how these off-chain bots (e.g., keeper bots, arbitrage bots) read and process on-chain data.",6
What properties/invariants do you want to hold even if breaking them has a low/unknown impact?,"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 could be assigned Medium severity. You can answer ""No"" if there are no specific invariants you want to hold.",7
Please discuss any design choices you made.,"For example: ""We chose to ignore fees in some calculations because they unnecessarily overcomplicated formulas, but didn't have practically any impact on the final result. But, if this approximation may cause a serious loss of funds, it may be a valid finding.""",8
Please provide links to previous audits (if any) and all the known issues or acceptable risks.,"Listing the audits provides context to Watsons and invalidates findings acknowledged in these audits. Additionally, issues listed in this question will also be considered Invalid as known or acceptable findings.",9
Please list any relevant protocol resources.,"Please link to the docs, whitepaper, and the website for Watsons to gather context on the audit.",10
Additional audit information.,"If you'd like to specify what areas would you like Watsons to look into, this is a perfect place to do so.
In case you forked any contracts, please provide a diff from the original ones. You can also provide a diff of the contracts after your last audit(s). This will direct Watsons' focus on the least battle-tested parts.",11

2 changes: 1 addition & 1 deletion audits/judging/guidelines/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -153,7 +153,7 @@ If the original report does not include a Proof of Concept (PoC), it will be con
### VIII. List of Issue categories that are considered valid:

1. **Slippage** related issues showing a direct loss of funds with a detailed explanation for the same can be considered valid **high**
2. **EIP Compliance:** For issues related to EIP compliance, the protocol & codebase must show that there are important external integrations that would require strong compliance with the EIP's implemented in the code. The EIP must be in regular use or in the **final state** for EIP implementation issues to be considered valid
2. **EIP Compliance:** For issues related to EIP compliance, the protocol must mention EIP in the contest README, and issues violating "MUST" statements in the EIP specifications (including violations in view functions, but excluding statements in code comments in the EIP specifications), irrspective of whether the impact is low/unknown, may be assigned Medium severity if it doesn't conflict with common sense. For the issue to be considered valid Medium, the report **must** explicitly mention the violated EIP requirement and show potential problems with external integrations; and the EIP must be in regular use or in the **final state**.
3. **Identifies the core issue:** In case of issues that have a large number of duplicates, Issues that identify the core issue and show valid loss of funds should be grouped.
4. **Out of Gas:** Issues that result in Out of Gas errors either by the malicious user filling up the arrays or there is a practical call flow that results in OOG can be considered a valid **medium** or in cases of blocking all user funds forever maybe a valid **high**.**Exception:** In case the array length is controlled by the trusted admin/owner or the issue describes an impractical usage of parameters to reach OOG state then these submissions would be considered as **low**.
5. **Chainlink Price Checks**: Issues related to minAnswer and maxAnswer checks on Chainlink's Price Feeds are considered medium only if the Watson explicitly mentions the price feeds (e.g. USDC/ETH) for the in-scope tokens on the in-scope chains that require this check. **Additionally**, a proper attack path and at least medium severity impact must be included in the report. See [this](https://stackoverflow.com/questions/78558661/which-chainlinks-price-feeds-still-have-minanswer-and-maxanswer-checks) to know if min/maxAnswer are deprecated on the price feed.
Expand Down