OrderBook
First Flight #43
Beginner FriendlySolidity
100 EXP
View results
Previous Next
Submission Details
Severity: low
Valid

Fee Precision Issue

gwish08

OrderBook.sol uses low-precision fee logic prone to rounding errors, enabling attackers to distort calculated fees.

Description

  • The contract calculates protocol fees using a simple percentage-based system with 3% fee and 100 precision, designed to charge sellers a reasonable commission on successful trades.

  • The fee calculation is vulnerable to integer overflow when multiplying large price values, and the low precision creates rounding issues for small amounts, enabling both fee manipulation attacks and order book spam.

contract OrderBook is Ownable {
// @> Low precision constants create rounding issues
uint256 public constant FEE = 3; // 3%
uint256 public constant PRECISION = 100;
​
function createSellOrder(
address _tokenToSell,
uint256 _amountToSell,
uint256 _priceInUSDC,
uint256 _deadlineDuration
) public returns (uint256) {
// @> No validation against extreme values that could cause overflow
if (_amountToSell == 0) revert InvalidAmount();
if (_priceInUSDC == 0) revert InvalidPrice();
// @> Missing upper bounds validation
// ... order creation logic
}
​
function buyOrder(uint256 _orderId) public {
Order storage order = orders[_orderId];
order.isActive = false;
// @> Vulnerable fee calculation - can overflow with large priceInUSDC
uint256 protocolFee = (order.priceInUSDC * FEE) / PRECISION;
uint256 sellerReceives = order.priceInUSDC - protocolFee;
​
// @> No overflow protection in fee calculation
iUSDC.safeTransferFrom(msg.sender, address(this), protocolFee);
iUSDC.safeTransferFrom(msg.sender, order.seller, sellerReceives);
totalFees += protocolFee; // @> Can accumulate incorrect fees due to overflow
}
}

Risk

Likelihood:

  • Attackers discover the integer overflow vulnerability and create orders with prices near uint256 maximum to exploit fee calculation

  • Users create legitimate small-value orders that suffer from precision loss due to the low PRECISION constant

  • Malicious actors spam the order book with economically nonsensical orders (tiny amounts at maximum prices) to disrupt legitimate trading

Impact:

  • Protocol loses significant fee revenue when overflow causes fee calculations to wrap around to near-zero values

  • Order book becomes cluttered with spam orders that waste gas and storage, degrading user experience

  • Small legitimate orders may have their fees rounded down to zero, creating unfair trading conditions

  • Attack costs are minimal (only gas) while potential gains from avoiding fees on large trades are substantial

Proof of Concept

// Scenario A:
// 1. Attacker creates 1000 orders with:
// _amountToSell = 1 wei
// _priceInUSDC = type(uint256).max
// 2. These orders are technically valid but economically impossible
// 3. Order book queries become expensive due to spam
// 4. Legitimate users waste gas filtering through nonsensical orders
​
// Scenario B:
// 1. User creates order with priceInUSDC = 50 (small amount)
// 2. protocolFee = (50 * 3) / 100 = 150 / 100 = 1 (rounded down)
// 3. Expected fee: 1.5, actual fee: 1 (33% reduction in fees)
// 4. For priceInUSDC = 33: protocolFee = (33 * 3) / 100 = 99 / 100 = 0
// 5. No fee collected despite successful trade
​
// Demonstrating the overflow:
uint256 maxPrice = type(uint256).max;
uint256 testFee = (maxPrice * 3) / 100; // This will overflow
// Result: testFee will be a small number, not 3% of maxPrice

Recommended Mitigation

Increase precision and reasonable bounds.

Updates

Lead Judging Commences

yeahchibyke Lead Judge
4 months ago
yeahchibyke Lead Judge 4 months ago
Submission Judgement Published
Validated
Assigned finding tags:

Fee can be bypassed

Protocol Suffers Potential Revenue Leakage due to Precision Loss in Fee Calculation

Support

FAQs

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