Uninitialized minimumOrderFeeRate Allows Bypassing Minimum Fee Requirement in acceptLoanOfferAndFillOrder Function
Summary
In the PredictDotLoan contract, the minimumOrderFeeRate variable is not set during deployment, defaulting to zero. The acceptLoanOfferAndFillOrder function relies on this variable to enforce a minimum fee rate for exchange orders. Since the default value is zero, the condition checking whether the exchange order's fee rate is above the minimum does not function as intended. This oversight allows users to accept loan offers and fill exchange orders with zero or negligible fees, potentially undermining the protocol's fee structure and affecting revenue.
Root Cause
The root cause of the vulnerability is the lack of initialization of the minimumOrderFeeRate variable upon contract deployment. In Solidity, uninitialized state variables of type uint default to zero.
Since minimumOrderFeeRate is zero by default, the condition exchangeOrder.feeRateBps < minimumOrderFeeRate will only revert if exchangeOrder.feeRateBps is also zero. However, fee rates are often zero or set by users to minimal values, effectively disabling the intended check. This means the function does not enforce any meaningful minimum fee rate unless minimumOrderFeeRate is explicitly set to a non-zero value by an administrator after deployment.
Internal pre-conditions
No response
External pre-conditions
No response
Attack Path
Protocol Revenue Loss: The protocol may collect significantly lower fees than intended, impacting revenue streams that could fund development, maintenance, or rewards.
Inconsistent Fee Enforcement: Users can bypass the minimum fee requirement, leading to an unfair advantage for those who exploit this oversight over users who pay standard fees.
Massive Foggy Gorilla
Medium
Uninitialized minimumOrderFeeRate Allows Bypassing Minimum Fee Requirement in acceptLoanOfferAndFillOrder Function
Summary
In the PredictDotLoan contract, the minimumOrderFeeRate variable is not set during deployment, defaulting to zero. The acceptLoanOfferAndFillOrder function relies on this variable to enforce a minimum fee rate for exchange orders. Since the default value is zero, the condition checking whether the exchange order's fee rate is above the minimum does not function as intended. This oversight allows users to accept loan offers and fill exchange orders with zero or negligible fees, potentially undermining the protocol's fee structure and affecting revenue.
Root Cause
The root cause of the vulnerability is the lack of initialization of the minimumOrderFeeRate variable upon contract deployment. In Solidity, uninitialized state variables of type uint default to zero.
https://github.com/sherlock-audit/2024-09-predict-fun/blob/main/predict-dot-loan/contracts/PredictDotLoan.sol#L229-L231
Since minimumOrderFeeRate is zero by default, the condition exchangeOrder.feeRateBps < minimumOrderFeeRate will only revert if exchangeOrder.feeRateBps is also zero. However, fee rates are often zero or set by users to minimal values, effectively disabling the intended check. This means the function does not enforce any meaningful minimum fee rate unless minimumOrderFeeRate is explicitly set to a non-zero value by an administrator after deployment.
Internal pre-conditions
No response
External pre-conditions
No response
Attack Path
Protocol Revenue Loss: The protocol may collect significantly lower fees than intended, impacting revenue streams that could fund development, maintenance, or rewards.
Inconsistent Fee Enforcement: Users can bypass the minimum fee requirement, leading to an unfair advantage for those who exploit this oversight over users who pay standard fees.
Impact
No response
PoC
No response
Mitigation
Initialize minimumOrderFeeRate During Deployment: