ihavebigmuscle - Whitelisted LPs in OracleMaker Can Manipulate the Funding Rate through Deposit/Withdraw Operations

[sherlock-admin2]

ihavebigmuscle

high

Whitelisted LPs in OracleMaker Can Manipulate the Funding Rate through Deposit/Withdraw Operations

Summary

Whitelisted LPs in OracleMaker Can Manipulate the Funding Rate through Deposit/Withdraw Operations

Vulnerability Detail

When depositing or withdrawing, the whitelisted LPs in OracleMaker will change the maker's margin. According to the funding rate calculation formula:

int256 fundingRate = fundingFactor * (position.openNotional) ** fundingExponentFactor / ((position.margin + position.unsettlePnl) / oraclerMaker.minMarginRatio())

, if the margin is larger, abs(fundingRate) is smaller, and if the margin is smaller, abs(fundingRate) is larger.

Therefore, the whitelisted LPs in OracleMaker can manipulate the funding rate prior to the execution of a transaction, thereby potentially avoiding payment in situations where the funding fee needs to be paid.

Impact

This could lead to a loss of funding fee income for the maker.

Code Snippet

https://github.com/sherlock-audit/2024-02-perpetual/blob/02f17e70a23da5d71364268ccf7ed9ee7cedf428/perp-contract-v3/src/fundingFee/FundingFee.sol#L123-L139

Tool used

Manual Review

Recommendation

It's suggested that the calculation of the funding fee could use a time-weighted method, instead of being determined by the current position status in OracleMaker.

[sherlock-admin2]

1 comment(s) were left on this issue during the judging contest.

santipu_ commented:

Medium

[nirohgo]

Escalate

This escalation applies to this finding as well as #144 and #147, (all submitted by the same Watson and marked as dups of #133)

All three findings are not dups of #133 and are invalid:

141 (this finding) - This finding is about manipulating the funding rate through Liquidity Providing which can affect the rate. #133 deals with manipulating the rate through opening a position balanced by a counter position, and gain substantial amounts within one block. #141 is invalid because there is nothing to gain in the attack method described because funding fees are paid per second over the period of holding the position. If an LP held a position for some time, manipulating the fee short time through deposits/withdraws wont make a difference (and the effects on funding fee of supplying/removing liquidity long term are not a manipulation but rather the expected behavior)

144 - Deals with opening a delta neutral position on both whitelisted makers as a way to grief the spotHedge maker by making it pay funding fees. This too is not a viable attack: A. the Oracle Maker skew will be balanced by market forces in a short time. B. There is no guarantee that the SpotHedge maker will maintain its skew long enough to pay substantial fees.

147 - Again deals with opening a delta neutral position on both whitelisted makers, this time as a way to grief them by increasing their exposure. Again, not a reasonable attack since the attacker has no way to keep these makers exposed long term and they will be rebalanced by market forces.

[sherlock-admin2]

Escalate

This escalation applies to this finding as well as #144 and #147, (all submitted by the same Watson and marked as dups of #133)

All three findings are not dups of #133 and are invalid:

141 (this finding) - This finding is about manipulating the funding rate through Liquidity Providing which can affect the rate. #133 deals with manipulating the rate through opening a position balanced by a counter position, and gain substantial amounts within one block. #141 is invalid because there is nothing to gain in the attack method described because funding fees are paid per second over the period of holding the position. If an LP held a position for some time, manipulating the fee short time through deposits/withdraws wont make a difference (and the effects on funding fee of supplying/removing liquidity long term are not a manipulation but rather the expected behavior)

144 - Deals with opening a delta neutral position on both whitelisted makers as a way to grief the spotHedge maker by making it pay funding fees. This too is not a viable attack: A. the Oracle Maker skew will be balanced by market forces in a short time. B. There is no guarantee that the SpotHedge maker will maintain its skew long enough to pay substantial fees.

147 - Again deals with opening a delta neutral position on both whitelisted makers, this time as a way to grief them by increasing their exposure. Again, not a reasonable attack since the attacker has no way to keep these makers exposed long term and they will be rebalanced by market forces.

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[nevillehuang]

@nirohgo I agree with your escalation. I believe the other 3 mentioned findings are invalid and additionally, they lack sufficient description and proof of issue.

[WangSecurity]

Agree with the escalation and planning to accept the escalation and invalidate the issue, unless the watson provides any additional input/info.

[Evert0x]

Result: Invalid Unique

[sherlock-admin4]

Escalations have been resolved successfully!

Escalation status:

• nirohgo: accepted