OrderBook

Description

The contract tracks all orders using a simple incremental orderId counter. This works well under the current single-deployment scenario. However, future protocol upgrades or migrations might attempt to restart the counter without properly offsetting from the highest existing orderId.

Without safeguards, this could cause duplicate orderIds, leading to confusion across indexers, UIs, and wallets tracking these IDs as immutable references. Such collisions would undermine the reliability of the order book’s history.

Root + Impact

Normal Behavior:
Every time a seller creates a new order, the contract increments nextOrderId and uses it as a unique identifier.

Issue:
In the event of a protocol upgrade, redeployment, or migration (which is typical for evolving DeFi projects), developers might inadvertently restart nextOrderId from 0 or another conflicting value. This would introduce duplicate order IDs that could:

• Overwrite or mask previously existing orders in indexers,

• Cause historical UI charts to show incorrect owners or amounts,

• Confuse automated bots relying on orderId uniqueness.

Risk

Likelihood

• Only surfaces during future migrations, but migrations are common as protocols evolve to patch bugs, add features, or launch V2 contracts.

Impact

• Low — while this won’t cause immediate fund loss, it could severely corrupt user-facing data, break dashboards, and reduce trust in the protocol’s integrity.

Proof of Concept

Imagine the protocol decides to upgrade to add multi-asset batching:

Indexers like TheGraph or custom bots watching OrderCreated(orderId,...) will now receive duplicate orderIds, tying them incorrectly to previous orders.

Resulting in:

• Wallets showing stale or wrong orders,

• Traders interacting with unintended listings,

• Price analytics and trading history polluted.

Recommended Mitigation

Add explicit migration checks in future upgrades:

Additionally, emit a MigrationApplied(uint256 newStartingOrderId) event to keep off-chain systems in sync.