Price-Time Priority Matching in Rust

Price-time priority sounds simple until the implementation has to survive real state transitions. Orders arrive, cancel, partially fill, cross multiple price levels, and interact with timestamps, client identifiers, and replay logs. The matching engine has to make the same decision every time.

For a Rust matching engine, latency matters. Determinism matters more.

The priority contract

The core rule is price first, time second. Better-priced orders fill before worse-priced orders; within a price level, earlier orders fill before later orders. Everything else in the engine should preserve that rule:

• Insertions must maintain level order.
• Cancellations must not disturb remaining priority.
• Partial fills must preserve residual order state.
• Timestamps and sequence numbers must be unambiguous.
• Replay must reconstruct the same book and the same fills.

If two runs with the same input journal produce different fills, the engine has violated the contract even if both runs were fast.

Why explicit state beats cleverness

Matching engines invite clever data structures. The right question is not whether a structure is clever, but whether its invariants are testable and replayable. O(1) cancellation is useful. Cache locality is useful. But neither is acceptable if the book state becomes difficult to audit.

FerroMatch treats the matching core as a deterministic component. The state transition should be explainable from the input sequence, and the benchmark surface should measure the hot path without hiding correctness assumptions.

Where this fits

In the MorphIQ stack, matching is useful beyond exchange-like venues. It supports simulated fills, replayable execution state, strategy testing, and product workflows that need an execution model without claiming broker-like order routing.

The useful phrase is not "fast matching engine." It is "replay-exact matching with price-time priority."