The functions getFeesForAssetsAmountOut and getFeesForUsdTokenAmountIn perform fee calculations without checking that their input amounts are non-zero. While other parts of the system may implicitly catch zero-value scenarios, lacking explicit validation can lead to ambiguous or unexpected arithmetic outcomes, potentially causing issues in extreme edge cases.
In the following function, there is no validation to ensure that the input amounts (or related parameters such as the price) are non-zero:
Ambiguous Fee Calculations: Zero-value inputs could lead to undefined or unintended arithmetic behavior, such as divisions by zero or affecting fee rounding.
Edge-Case Vulnerabilities: Although not directly exploitable, missing validation opens the door for potential issues or future vulnerabilities if the fee calculation logic is altered.
Non-adherence to Best Practices: Financial calculations should always validate critical inputs to ensure clarity and strict adherence to intended constraints.
Manual Code Review: A thorough review of fee functions revealed the lack of input validations.
Static Analysis Tools: Tools flagged missing input checks within arithmetic operations.
Fuzz Testing: Fuzzing with zero-value inputs confirmed the need for explicit validations.
Implement Explicit Zero-Value Checks: Update the functions to require that input amounts and prices are non-zero. For example:
Consistent Validation Across Functions: Apply similar zero-value checks in getFeesForUsdTokenAmountIn and other related fee modules.
Update Documentation: Clearly document that the input parameters must be non-zero, outlining the expected requirements for proper fee calculation.
Thorough Testing: Add unit tests to ensure that the contract reverts when zero values are provided, thereby safeguarding against unexpected behavior.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.