Incorrect Refund Calculation in Partial Order Fulfillment Scenarios
Summary
The acceptLoanOfferAndFillOrder function in the smart contract incorrectly calculates refunds for order fees in scenarios where an order is partially filled. The refund calculation uses the full exchangeOrder.makerAmount and exchangeOrder.takerAmount instead of the actually filled amounts, potentially leading to incorrect refunds.
`1.The contract must support partial order fulfillment.
2.The exchangeOrder.feeRateBps must be greater than minimumOrderFeeRate.
3.The order must be partially filled.
External pre-conditions
No response
Attack Path
An attacker creates a large sell order with a high fee rate.
The attacker then creates a small loan proposal that only partially fills the sell order.
When acceptLoanOfferAndFillOrder is called, it will partially fill the order.
The refund calculation will use the full order amounts, resulting in an incorrect (likely larger) refund than should be given for the partial fill.
The attacker receives a larger refund than they should, effectively paying a lower fee rate than intended.
Impact
This vulnerability can lead to incorrect refund amounts being calculated and transferred. In partial fill scenarios:
Financial Loss: The protocol may refund more fees than it should, leading to financial losses.
Inconsistent Fee Structure: This creates an inconsistency in fee application between fully and partially filled orders.
PoC
No response
Mitigation
Use the actually filled amounts in the refund calculation
Waydou
High
Incorrect Refund Calculation in Partial Order Fulfillment Scenarios
Summary
The acceptLoanOfferAndFillOrder function in the smart contract incorrectly calculates refunds for order fees in scenarios where an order is partially filled. The refund calculation uses the full exchangeOrder.makerAmount and exchangeOrder.takerAmount instead of the actually filled amounts, potentially leading to incorrect refunds.
Root Cause
iN https://github.com/sherlock-audit/2024-09-predict-fun/blob/41e70f9eed3f00dd29aba4038544150f5b35dccb/predict-dot-loan/contracts/PredictDotLoan.sol#L277 The root cause of this vulnerability lies in the refund calculation logic not accounting for partial order fulfillment. The
CalculatorHelper.calcRefundfunction is called with the full order amounts, regardless of whether the order was partially or fully filled.Internal pre-conditions
`1.The contract must support partial order fulfillment. 2.The exchangeOrder.feeRateBps must be greater than minimumOrderFeeRate. 3.The order must be partially filled.
External pre-conditions
No response
Attack Path
An attacker creates a large sell order with a high fee rate. The attacker then creates a small loan proposal that only partially fills the sell order. When acceptLoanOfferAndFillOrder is called, it will partially fill the order. The refund calculation will use the full order amounts, resulting in an incorrect (likely larger) refund than should be given for the partial fill. The attacker receives a larger refund than they should, effectively paying a lower fee rate than intended.
Impact
This vulnerability can lead to incorrect refund amounts being calculated and transferred. In partial fill scenarios: Financial Loss: The protocol may refund more fees than it should, leading to financial losses. Inconsistent Fee Structure: This creates an inconsistency in fee application between fully and partially filled orders.
PoC
No response
Mitigation
Use the actually filled amounts in the refund calculation