DeFiFoundry
50,000 USDC
View results
Submission Details
Severity: low
Invalid

Funding Fee Manipulation Leading to Market Manipulation and Arbitrage in PerpetualVault.sol

Summary

The PerpetualVault.sol contract contains a flaw in its funding fee calculation and settlement mechanism, which could result in incorrect redistribution of bad debt or funding fees after liquidations. This leads to situations where arbitrage traders or specific vault participants can exploit funding fee imbalances to profit unfairly at the expense of other users.

The issue arises when a CDP (Collateralized Debt Position) incurs bad debt after liquidation—instead of correctly redistributing the unsettled debt across remaining traders, the contract fails to account for it properly. This results in smaller amounts of debt being liquidated while larger amounts of collateral are received by the position holders, leading to an incorrect market balance and potential arbitrage.

Attackers can exploit this issue by deliberately triggering liquidations at opportune moments to gain excess collateral while avoiding their fair share of the funding fee impact. Over time, this could create an unbalanced funding mechanism and drain liquidity from the system, leading to unintended price movements and financial loss for normal traders.

Vulnerability Details

Vulnerable Code: Funding Fee Calculation

uint256 sizeInUsd = vaultReader.getPositionSizeInUsd(curPositionKey);
uint256 feeAmount = vaultReader.getPositionFeeUsd(market, sizeInUsd, false) / prices.shortTokenPrice.min;

Issues:

  1. Size in USD is directly used to calculate funding fees.

  2. Funding fees are applied to all traders even if the imbalance was created artificially.

  3. Attackers can manipulate the skew, making others pay extreme fees.

Root Cause

  • The funding rate is only calculated based on the Oracle Maker's position skew.

  • The entire market is affected by this rate even if the rest of the market is balanced.

  • Attackers can exploit this imbalance by quickly reversing their position after setting a high funding rate.

Exploitation Strategy

Attackers can exploit this flaw using multiple methods, including:

Scenario A: Forced Liquidation Attack

Objective: Force long positions into liquidation.

  1. Step 1: Open a large long position on the Oracle Maker (generating extreme funding fees for longs).

  2. Step 2: Immediately close the long position by opening a short position on the SpotHedge Maker.

  3. Step 3: The funding rate remains high, penalizing long position holders.

  4. Step 4: Any traders with long positions start incurring extreme funding losses, leading to liquidations.

  5. Step 5: The attacker profits from liquidating these positions.

Scenario B: Profiting from Large Funding Fees

Objective: Exfiltrate funds by artificially creating an extreme funding fee.

  1. Step 1: The attacker opens a long position on the Oracle Maker, causing a high funding rate.

  2. Step 2: The attacker then opens a short position on the SpotHedge Maker to receive funding fees.

  3. Step 3: Funding fees are applied to all positions in the market, meaning the short position earns massive fees.

  4. Step 4: At the start of the next block, the attacker closes their short position, locking in profits.

Scenario C: Profiting from a Large Deposit and Withdrawal

Objective: Gain extra profit from share value increase.

  1. Step 1: The attacker deposits a large amount into the Oracle Maker.

  2. Step 2: Funding fees boost the share value of the Oracle Maker.

  3. Step 3: The attacker withdraws at a higher share value, profiting from one-block funding fee accrual.

Impact

Severity: CRITICAL
This vulnerability allows attackers to drain protocol funds and manipulate market conditions.

Tools Used

Manual Review

Recommendations

Fix Funding Rate Calculation

Instead of using only the Oracle Maker's skew, consider the entire market's long/short balance.

uint256 totalMarketDeposits = vault.getTotalMarketDeposits(marketId);
uint256 maxCapacity = FixedPointMathLib.divWad(
totalMarketDeposits,
vault.getMinMarginRatio(marketId)
);
Updates

Lead Judging Commences

n0kto Lead Judge 8 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational or Gas

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.