Liquidity Management

Summary

VaultReader contains a logic error in getPriceImpactInCollateral that stems from unscaled integer division. This approach allows key values (scaled to 1e30) to be truncated when smaller than their divisor. As a result, values that should be fractional become zero or extremely inaccurate, affecting subsequent calculations such as price impact or collateral adjustments. This can lead to significant miscalculations within the protocol’s risk and fee management logic.

Vulnerability Details

The vulnerability resides in the VaultReader contract, specifically within the getPriceImpactInCollateral function. This function performs integer division on values presumed to be scaled by 1e30 without adjusting for the scale, causing truncation when the numerator is smaller than the denominator. As a result, calculations that should produce a fractional outcome become zero or severely inaccurate. This miscalculation directly impacts subsequent logic that relies on price impact data, posing a risk to the protocol’s collateral and fee computations.

Impact

By using truncated values instead of precise calculations, this flaw can lead to inaccurate assessments of required collateral, fees, and price impact. These inaccuracies could result in undercollateralized positions or incorrect fee distributions, potentially making the protocol susceptible to arbitrage, unexpected liquidations, or other adverse outcomes that compromise the system's economic integrity.

Proof of Concept

This logical error arises because the function performs integer divisions on values presumably scaled by 1e30 without adjusting for precision, resulting in truncated outputs that can become zero or severely inaccurate.

Code Analysis

• VaultReader.sol - getPriceImpactInCollateral

Below is the relevant snippet highlighting the integer division issue. Irrelevant code has been removed for clarity:

Explanation

When sizeDeltaInUsd / prices.indexTokenPrice.min is performed without any scaling factors, significant decimals are lost if both values are in 1e30. Consequently, if sizeDeltaInUsd is smaller than prices.indexTokenPrice.min, the result becomes zero, skewing the subsequent price impact calculation.

Vulnerable Scenario

• sizeDeltaInUsd is scaled to 1e30 (e.g., 1.5 * 1e30, representing 1.5 USD).

• prices.indexTokenPrice.min is also 1e30 (e.g., 2 * 1e30).

• Integer division 1.5e30 / 2e30 yields 0, causing expectedSizeInTokensDelta to be 0.

• This feeds into the remaining logic, producing an incorrect final result. Any function relying on this calculation (fees, collateral adjustments, price impact, etc.) may thus rely on inaccurate data.

Such a scenario may lead to mismatches in fee or collateral calculations, potentially opening avenues for arbitrage or other unintended risk management behaviors.

Test and Result

The test deposits collateral, opens a position to obtain a valid positionKey, and then sets up a scenario where integer division causes truncation. It compares the actual priceImpact result (-5913539007855679092) to the expected truncated value, confirming that the division scales are not handled and leading to the precise truncated outcome. The test passes, demonstrating that the function indeed exhibits this precision loss.

• Add the following test to test/PerpetualVault.t.sol

Confirmation

The logical error is confirmed by the absence of proper scaling in the integer division step, which can truncate otherwise non-zero values and disrupt core logic in the contract’s calculations.

Tools Used

Manual Code Review:
A comprehensive line-by-line inspection of the contract was performed to identify potential discrepancies and confirm integer division issues without proper scaling. This manual analysis highlighted the truncation problem in critical calculation paths.

Recommendations

Use proper scaling to handle 1e30 values before performing integer division. Multiply by a precision factor, then divide. For example:

This approach preserves fractional precision and avoids truncation issues in subsequent calculations.