OrderBook

Description

The contract uses require statements to enforce critical security and state conditions, such as ensuring only the seller can amend or cancel an order. However, many of these checks lack explicit revert reason strings. This significantly reduces developer experience and makes it harder for integrators, testers, and even auditors to understand why a transaction failed.

Root + Impact

Normal Behavior:
require statements in Solidity revert a transaction if a condition fails. By default, if no message is provided, the transaction fails with an empty error string.

Issue:
Without specific error messages, developers integrating wallets or frontends with the protocol receive generic "execution reverted" errors, which provide no insight into which condition failed.

Example scenario:
A frontend dApp or integration script that tries to amend an order but fails due to wrong caller gets only a generic error. This forces developers to step through low-level traces or logs, wasting time and increasing support burdens.

Risk

Likelihood

• Always impacts developer integrations and QA, every time a require check fails.

Impact

• Low — does not threaten funds, but slows integration, increases developer friction, and complicates user support when transactions fail silently.

Proof of Concept

Try to amend an order from an unauthorized account:

This means wallet providers or transaction dashboards cannot show a helpful reason like "Only seller can amend".

Recommended Mitigation

Adding explicit revert strings improves clarity in failed transactions, speeds up integration, reduces QA overhead, and results in a smoother developer and end-user experience across the protocol ecosystem.