Root + Impact

Description

• The OrderBook contract includes a check in the buyOrder and amendSellOrder functions that reverts transactions if the current block timestamp exceeds the order's deadlineTimestamp (if (block.timestamp >= order.deadlineTimestamp) revert OrderExpired();). While this ensures orders cannot be filled or amended after their expiration, it also means that expired orders remain active (isActive = true) until explicitly canceled via cancelSellOrder. This design leads to locked tokens and poor UX, as users cannot interact with expired orders except to cancel them, and there’s no automatic mechanism to deactivate or refund expired orders.

Risk

Likelihood:

• Reason 1 // Describe WHEN this will occur (avoid using "if" statements)

• Reason 2

Impact:

• Locked Funds: Tokens in expired but active orders remain locked in the contract, preventing sellers from accessing their assets until they manually call cancelSellOrder. This can lead to funds being stuck indefinitely if users are unaware or forget to cancel.

• Poor UX: Users are frustrated by the inability to amend or fill expired orders, and the lack of automatic expiration handling creates confusion, as orders appear active but are unusable.

• Reduced Market Efficiency: Expired orders clutter the order book, reducing liquidity and making it harder for users to identify actionable orders.

• Invariant Complications: The invariant that the contract’s token balance equals the sum of amountToSell for active orders is inflated by expired orders, complicating state management and auditing.

Proof of Concept

Recommended Mitigation

Automatic Order Deactivation: Introduce a mechanism to automatically mark expired orders as isActive = false when they are checked (e.g., in buyOrder or amendSellOrder).