Insight Severity Level

"Insights" are reports that provide informational value, but do not identify vulnerabilities. They recognize that enhancing a project's security may require recommendations that do not fit into traditional bug report categories.

The insight severity level only applies to audit competitions, invite-only programs, & Attackathons. Insights do NOT apply to bug bounties.

A report may qualify as an ‘Insight’ if it is one of the following:

1. Security Best Practices:

An improvement that strengthens the security design or implementation of the code by addressing potential threats, even in the absence of an immediate or known vulnerability.

Valid Examples:

• Recommending implementation of the Checks-Effects-Interactions pattern to mitigate potential reentrancy attacks, even if not immediately exploitable or impactful.
• Suggesting the use of OpenZeppelin’s SafeMath library for arithmetic operations to prevent integer overflow/underflow.

Invalid Examples:

• Suggesting minor style changes or naming conventions without security relevance.
• Recommending cosmetic formatting adjustments.

2. Code Optimizations and Enhancements:

A recommendation aimed at improving system performance, reducing operational costs, or optimizing resource utilization, contributing to long-term sustainability.

Valid Examples:

• Suggesting caching variables in memory rather than repeated storage reads to reduce gas costs.
• Recommending replacing loops with optimized data structures or mappings to reduce computational overhead.

Invalid Examples:

• Suggesting minor syntax optimizations or redundant code cleanup without measurable performance impact.
• Suggesting the removal of unused or dead code that does not affect gas costs, regardless of whether it is kept or removed.
• Recommendations purely related to code readability without efficiency improvements.
• Gas usage problems often come from the caller’s side or user mistakes, like sending too many arguments. These issues affect only the caller and don’t increase gas use at the contract or protocol level.

3. Architectural Decentralization and Composability:

An enhancement to the project’s architecture that reduces risks associated with centralization or unsafe composability, promoting a more secure and resilient system design.

Valid Examples:

• Advising the use of standardized ERC token interfaces to prevent potential compatibility issues in external integrations.
• Proposing clear and modular smart contract structures that isolate sensitive components to limit exposure in case of exploits.
• Suggesting explicit handling and checks for external contract interactions to prevent composability risks.

Invalid Examples:

• Recommending validation checks for change operations performed by privileged or access-controlled functions.
• Suggesting minor changes to modularize code without addressing security or centralization concerns.

4. Documentation Improvements:

A substantial improvement to project documentation that clarifies complex logic, architectural decisions, and security considerations, helping to prevent misunderstandings and incorrect implementations.

Valid Examples:

• Finding discrepancies between the implemented logic in the codebase and its documentation or NatSpec comments, ensuring accurate representation of contract behavior.

Invalid Examples:

• Correction of minor grammatical errors or formatting adjustments in documentation that do not affect clarity or security.
• Suggestions to rephrase minor sections of documentation without substantial improvement in clarity or usefulness.

How to submit a valid Insight:

• Submit one report per Insight:
  Do NOT batch multiple insight submissions into one report, or else they may only be rewarded as though it were one insight.
  
  
• Complete the PoC section with the conditions under which the insight is valuable:
  For example, an insight which points out a potential gas optimization must describe how and where the change leads to a decrease in gas costs, considering the system as a whole.

Insight Judging:

• Only the first valid submission of an Insight is rewarded. Duplicate reports of Insights are NOT rewarded.
  
  
• Immunefi may close low quality insight submissions without justification.
  
  
• Insights are NOT eligible for mediation or appeal. Begging for an Insight will receive a warning and repeated insight begging is a bannable offence.