The three paths
| Modification | Path | Preserves priority? | Can partially succeed? |
|---|---|---|---|
| Change price | Cancel + new | No — new order re-queues | Yes |
| Reduce size (new size < remaining size) | In-place edit | Yes — keeps queue position | No |
| Increase size (new size > remaining size) | Cancel + new | No — new order re-queues | Yes |
Why reducing size keeps priority
Shrinking a resting order is risk-free for the book — it does not cross any other order and does not change the maker’s intent. Intention edits the original order in place, updating bothsize and original_size, without affecting the order’s position in the price-time queue.
Intention’s approach is intentionally different from some peer exchanges that cancel-and-replace on every modification. Keeping priority on size-down matters for market makers who want to pull size without losing their spot.
Why price change and size-up use cancel + new
Both effectively require creating a different order. The engine must ensure the old order is cancelled before the new order is placed; if the cancel fails, the modification aborts and the original order stays live. If the cancel succeeds but the new order fails (for example, because of insufficient margin), the result is “partial success”: the old order is gone but no new order was created. Client UIs surface this state clearly so you can retry.In-place size reduction
Comparison is based on remaining size, not original size, so a partially filled order can still be edited. For example, a 10 BTC limit that has filled 3 BTC has a remaining size of 7; editing to “6 BTC” is a valid size-down edit and keeps priority. Even an in-place edit can fail. The modified order must still satisfy the minimum order size for the contract. If it would not, Intention rejects the modification and leaves the original order intact.Cancel + new flow (price change or size-up)
For non-post-only orders, the two phases are scheduled across blocks:
Post-only modifications are faster — the cancel and the new order can be processed within the same block because post-only orders skip the off-chain queue.
In all cases, time-in-force constraints that depend on off-chain wait still apply. For example, a modified IOC will be evaluated only when the new order actually reaches matching.
Result states
A modification resolves into one of three states:- Success. New parameters are live. If it went through cancel + new, the new order has a fresh queue position; if it was an in-place size reduction, priority is preserved.
- Partial success. Only possible on cancel + new: the old order is gone but the new order did not make it (commonly insufficient margin or minimum-size rejection).
- Failure. The cancel never succeeded, or an in-place reduction failed validation. The original order remains unchanged.
Partial-fill interactions
Comparisons between new size and current size always use remaining size. On success, bothsize and original_size are updated consistently so downstream accounting is correct.