> For the complete documentation index, see [llms.txt](https://dualguard.gitbook.io/dualguard/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dualguard.gitbook.io/dualguard/bug-bounties/criteria-for-valid-findings.md).

# Criteria for Valid Findings

These rules apply across DualGuard bug bounty programs unless a specific bug bounty page states otherwise.

### DualGuard standards

1. Program-specific instructions on the bug bounty page and in code comments may be used during triage.

   * If they conflict, the bug bounty page is the source of truth.

   * A judge may disregard code comments that appear outdated.

   > Example: a comment says a swap can never fail, but the implementation clearly supports failing swaps.
2. Submit one vulnerability per report.
   * If you identify multiple vulnerabilities, submit them separately.
3. Admin trust assumptions apply by default.
   * External admin functions are assumed to be used correctly.
   * Reports that depend on admin misuse are invalid unless the bug bounty page defines stricter trust assumptions or limits.
4. Scope rules follow the in-scope contract.
   * If a contract is in scope, its parent contracts are also in scope by default.
   * A library issue is valid if an in-scope contract uses that library and is affected by the bug.
   * If the vulnerability exists only in an out-of-scope contract, related reports are invalid.

### Invalid issue categories

The following issue categories are generally not valid:

1. **Gas optimizations**
   * Cases where users or the protocol only pay slightly more gas.
2. **Incorrect event values**
   * Wrong or miscalculated values in emitted events.
3. **Missing zero-address checks**
   * Reports that only recommend checking whether an input is the zero address.
4. **User input validation for user mistakes**
   * Preventing ordinary user mistakes is not, by itself, a valid issue.
   * Exception: the input can still be valid if it can cause major protocol malfunction or significant loss of funds for the protocol or other users, and it meets in-scope severity criteria.
5. **Admin input or call-order validation**
   * Incorrect admin sequencing is not a valid issue.
   * Example: an admin forgets to call `setWithdrawAddress()` before `withdrawAll()`.
   * Admin actions that break normal protocol assumptions are also invalid by default.
   * Example: pausing collateral causes unfair liquidations or another admin-triggered loss scenario.
6. **Blacklist dependency**
   * It is not a valid issue if protocol contracts or admin addresses are added to a blacklist and the protocol is affected as a result.
7. **Front-running initializers without lasting damage**
   * These reports are invalid if there is no irreversible harm or loss of funds and the team can simply redeploy and initialize again.
8. **Minor UX-only issues**
   * Reports are invalid if they only describe inconvenience without fund loss.
   * Example: funds are temporarily inaccessible but recoverable by an admin.
9. **User blacklisting that only harms that user**
   * This is not a valid issue if the blacklisted user only harms themselves.
   * Exception: it may be valid if a malicious actor can use a blacklisted address to harm the protocol or other users, and the issue meets in-scope severity criteria.
10. **Assumptions about future opcode gas repricing**
    * These reports are invalid.
    * The choice to use `call` instead of `transfer` is treated as a design decision unless there is already a concrete reason for the call to exceed 2300 gas without relying on future opcode repricing.
11. **Unexpected direct token transfers that only hurt the sender**
    * This includes native tokens, ERC20s, and similar assets sent directly to in-scope contracts outside expected protocol flows.
    * If the contract cannot recover those funds and only the sender is harmed, the report is invalid.
    * It may still be valid if the behavior harms the protocol or other users and meets in-scope severity criteria.
12. **Loss of airdrops or extra rewards**
    * This is invalid if the reward is not part of the intended protocol design.
13. **Incorrect values in view functions**
    * These are invalid by default.
    * Exception: they may be valid if the incorrect view result feeds a larger execution path that causes loss of funds and the issue meets in-scope severity criteria.
14. **Oracle recommendations about stale prices or Chainlink round completeness**

    * Generic recommendations to add stale-price checks or round-completeness checks are invalid.

    > Exception: a stale-price check may be valid in some designs. For example, a pull-based oracle such as Pyth may require the protocol to actively request a fresh price before use. If that does not happen, the protocol may rely on stale data.
15. **Previously acknowledged audit issues**
    * Reports are invalid if the issue appears in a previous audit linked from the bug bounty page and was acknowledged but intentionally left unfixed.
16. **Chain re-org and network liveness assumptions**
    * These are invalid by default.
    * Exception: they may be valid if the protocol itself is a blockchain and the attacker can force a re-org that affects the protocol and its users, and the issue meets in-scope severity criteria.
17. **Unsupported ERC721 safe minting**
    * Reports that users cannot `safeMint` ERC721 tokens because of unsupported implementation are invalid.
18. **Future-only issues**
    * Reports are invalid if they depend on a future integration or implementation not described in the docs or README.
    * The same applies to hypothetical issues that would exist only after a future code change, including a possible fix for another issue.
19. **Non-standard token behavior**
    * Issues involving [weird-tokens](https://github.com/d-xo/weird-erc20) or similar non-standard token behavior are invalid by default unless the bug bounty page explicitly includes those tokens.
    * Tokens with decimals between 6 and 18 are not considered weird for this purpose.
20. **Newer Solidity versions on older EVM targets**
    * It is not a valid issue to report that a Solidity version supports opcodes unavailable on the deployment network.
    * Compilation flags can target older EVM versions when needed.
21. **Sequencer downtime or misbehavior**
    * Sequencers are assumed to operate correctly and remain available.
    * Reports that depend on sequencer outage or malfunction are invalid.
22. **Design choices without security impact**
    * Suboptimal design is not a valid issue if it does not create a loss-of-funds scenario.
    * These reports are informational at most.
23. **Missing storage gaps in parent contracts**
    * Lack of storage gaps in parent contracts is not a valid issue.

### Duplicate reports

Duplicate submissions are not rewarded, even if the issue remains unfixed when the later report arrives.

Submission time determines priority.

Duplicate analysis is based on **root cause**.

If two reports identify the same vulnerability or the same underlying root cause, they may be treated as duplicates even if they affect multiple code locations or different contracts.

### Best practices

1. Read the bug bounty page and supporting documentation carefully before submitting.
2. Use your judgment and submit only issues that fit DualGuard's validity rules.
3. Describe impact precisely.
   * Bad: `Loss of funds for the user`
   * Good: `Loss of funds for users because the withdraw function has no access control`
4. Keep code snippets short.
   * Only include the lines needed to show the issue and its impact.
   * Put the detail into your explanation, not a large pasted excerpt.
5. Do not copy reports from prior contests, prior audits, or unrelated reports.
   * They are very unlikely to be valid in the current program.