Multiple Orders Requirement for Large Trades is Prone to Slippage Issues

[c4-bot-7]

Lines of code

https://github.com/code-423n4/2024-03-dittoeth//blob/main/contracts/facets/BidOrdersFacet.sol#L40

Vulnerability details

Impact

Users executing trades above the 300 million limit by splitting them into multiple orders incur higher transaction fees. Each additional transaction required to split the order increases the cost, impacting the overall efficiency and attractiveness of the platform for large trades.

Additionally, splitting large orders into smaller ones could lead to increased slippage, especially in less liquid markets. This slippage can negatively impact the execution price for the trader.

These large orders, when split and executed over time, can have a prolonged impact on the market, potentially leading to unfavorable price movements for the trader.

Proof of Concept

https://github.com/code-423n4/2024-03-dittoeth//blob/main/contracts/facets/BidOrdersFacet.sol#L40

function createBid(
        address asset,
        uint80 price,
     >>  uint88 ercAmount,
        bool isMarketOrder,
        MTypes.OrderHint[] calldata orderHintArray,
        uint16[] calldata shortHintArray
    ) external isNotFrozen(asset) onlyValidAsset(asset) nonReentrant returns (uint88 ethFilled, uint88 ercAmountLeft) {
        LibOrders.updateOracleAndStartingShortViaTimeBidOnly(asset, shortHintArray);

        return _createBid(msg.sender, asset, price, ercAmount, isMarketOrder, orderHintArray, shortHintArray);
    }

Tools Used

Manual

Recommended Mitigation Steps

1. Develop an order aggregation mechanism that allows users to submit large orders as a single transaction, which the smart contract then internally manages as multiple smaller orders. This approach would reduce the complexity and potentially lower the transaction costs for the user.

2. Introduce batch processing of orders where feasible, allowing multiple orders to be processed in a single transaction. This method can reduce gas costs and slippage by taking advantage of economies of scale.

3. Implement slippage protection mechanisms that allow users to specify a maximum acceptable slippage for their orders. If the execution price would result in slippage beyond this threshold due to order splitting, the transaction could be reverted or adjusted accordingly.

Assessed type

Other

[c4-pre-sort]

raymondfam marked the issue as insufficient quality report

[c4-pre-sort]

raymondfam marked the issue as primary issue

[raymondfam]

Inadequate elaboration to elicit the attack idea: Dust amounts: want to prevent small orders on the orderbook to prevent skyrocketing gas costs for large orders that match with multiple limit orders

[c4-judge]

hansfriese marked the issue as unsatisfactory: Insufficient proof