OrderBook

Description

In the amendSellOrder function, when a seller decreases _newAmountToSell, the difference order.amountToSell - _newAmountToSell is transferred back. While the diff calculation itself is precise using uint256, the concern is a hypothetical scenario where the underlying token's smallest transferable unit (if it were not 1 wei/atomic unit) or future complex calculations involving fractional amounts could lead to negligible "dust" amounts being stuck in the contract.

Risk

Root Cause: This is more a design consideration. The current _amountToSell and _newAmountToSell are uint256, representing the raw token amount (including decimals), ensuring diff is always a precise integer. The potential for "dust" is not due to a calculation error but a highly theoretical scenario involving token properties not common to standard ERC20s.

Solidity

Likelihood: Low. This is not a bug in the current implementation. It's a "what if" scenario for fractional amounts that standard ERC20 tokens and uint256 arithmetic correctly handle.

Impact: Very Low. It does not represent a security risk in its current form. Any theoretical "dust" would be negligible and not exploitable.

Proof of Concept

Given the current design and use of uint256 for amountToSell and _newAmountToSell, the diff calculation is always exact down to the token's smallest atomic unit (wei). Therefore, no "dust" is created by the calculation itself. A "proof of concept" would require an underlying ERC20 token to behave non-standardly (e.g., have a minimum transfer amount larger than 1 wei), which is not a vulnerability of this contract's logic.

Recommended Mitigation

None strictly necessary for the current logic as uint256 handles exact integer arithmetic for token amounts. If future contract upgrades or integrations involve tokens with unusual decimal behaviors or minimum transfer rules, careful consideration would be needed to handle those edge cases.

Reference Files:

• src/OrderBook.sol