0xMiden / 0xMiden/clob-example
match_orders compares inverted prices, accepting fills worse than the incoming limit
- Lenguaje dominante
- Rust
- Estrellas
- 3
- Forks
- 3
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Descripción
### Summary
`match_orders()` compares the existing order price directly against the incoming order price even though the two orders have inverse source/target assets. That means the comparison uses mismatched units and can accept fills that are worse than the incoming order's limit.
### Code path
`backend/order-book/src/order.rs`:
```rust
if existing_order.price() > incoming_order.price() {
return Err(OrderError::PriceTooHigh(...));
}
```
`Order::price()` returns `target_asset_amount / source_asset_amount`. For a resting order that matches an incoming order, the assets are reversed, so the resting order's price is denominated in the inverse unit.
### Example
The current test fixture already shows this case. The incoming order offers 10 source for 20 target, so its limit is 2 target per source. A resting order with 5 target as source and 10 source as target asks for 2 source per target, which is worse than the incoming limit of 0.5 source per target.
The current direct comparison sees `2.0 > 2.0` and accepts the fill, even though the prices are not in the same unit.
### Expected behavior
The match check should compare prices in the same unit, preferably with integer cross-multiplication to avoid floating point rounding. A resting order should be rejected when it asks for more incoming source per incoming target than the incoming order allows.
Guía de contribución
Evaluación
Este issue todavía no se ha evaluado.