Flow

Summary:

During the audit of the Flow contract, a significant vulnerability related to precision and rounding errors was identified. The implementation of the contract allows for calculations involving fixed-point numbers, which can lead to inaccuracies during arithmetic operations. These inaccuracies could potentially be exploited by malicious actors to manipulate token streaming and lead to financial losses.

Vulnerability Details:

The contract utilizes fixed-point mathematics for managing the streaming of tokens, specifically through the use of the UD21x18 and UD60x18 types. However, the implementation does not adequately handle precision and rounding during calculations, leading to discrepancies in expected outcomes.

Affected Functionality

The specific issue arises during the calculation of streamed amounts. A test case designed to verify the accuracy of streamed amounts revealed the following discrepancy:

• Calculated Amount: 1,000,000,000,000,000,010 (1.000000000000000010)

• Expected Amount: 11,000,000,000,000,000,000 (11.000000000000000000)

This mismatch indicates that the calculations performed by the contract do not align with the intended financial logic, thus exposing the contract to potential exploits.

Test Evidence:

The vulnerability was evidenced by the following test failure:

The test was designed to confirm the correctness of the streamed amount calculation but failed due to the identified precision issue.

Impact:

Financial Losses:

• Users relying on the Flow.stream() function for accurate token transfers may experience financial losses due to the imprecision in the streamed amounts. This could lead to underpayment or overpayment scenarios, where users receive less than expected or inadvertently pay more than intended. Such discrepancies can accumulate over multiple transactions, resulting in substantial financial implications for users and potentially leading to trust erosion.

Market Manipulation Risks:

• Malicious actors could exploit the rounding error to manipulate the streaming amounts to their advantage. For example, they could design transactions that intentionally exploit the rounding mechanism, allowing them to withdraw more tokens than they are entitled to, thereby draining resources from the contract. This could destabilize the token economy, particularly if large-scale manipulations occur.

Tools Used: Slither and Aderyn.

Recommendations:

Implement Fixed-Point Arithmetic:

• Utilize fixed-point arithmetic libraries that inherently handle rounding issues. Instead of relying on floating-point calculations, which can introduce rounding errors, leverage libraries like PRBMath to perform all calculations with fixed-point numbers. This ensures that all arithmetic operations are precise and minimize the risk of rounding errors.

Explicit Rounding Strategies:

• Clearly define the rounding strategy to be used in calculations. This includes specifying whether to round up, round down, or round to the nearest whole number. Make these decisions consistent throughout the contract to avoid discrepancies in how values are treated. Using standard rounding functions from trusted libraries can help maintain consistency.

Use SafeMath or Equivalent:

• While Solidity 0.8 and later versions include built-in overflow and underflow checks, explicitly using libraries like SafeMath (or similar) can further reinforce safe arithmetic operations. This can help manage edge cases where precision issues could arise, especially when scaling values.