Cancel and replace races in autonomous order handling

Cancellation has an intermediate state

Our example follows one intended quantity across the original and replacement orders.

An agent that changes its mind about an order needs to account for the time between requesting cancellation and learning the final outcome. During that interval, the existing order may still execute. Immediately replacing its full size can create more exposure than the agent intended.

Bybit's private order stream explicitly documents a race in which cancellation and execution occur together, resulting in two messages with a filled status and different rejection context. This is a concrete reason to preserve economic execution identity and lifecycle evidence separately.

An illustrative replacement sequence

An agent intends to buy a total of ten units. Its original order has already filled four. It requests cancellation of the remaining six and wants to move the rest to another price. Before cancellation becomes final, a late fill buys two additional units.

Confirmed acquired quantity is now six. The residual target is four, rather than six. If the replacement buys six, the combined result becomes twelve units, exceeding the original target by two. These numbers are illustrative and describe a runtime failure mode, rather than observed DXRG behavior.

The key accounting relation is residual target = intended total quantity minus confirmed executions across the entire instruction lineage. A replacement order is another child of that lineage. The quantity acquired by earlier children remains part of that lineage.

Build the sequence around evidence

Record the cancel request and move the original order into a pending cancellation state. Continue processing fills while that state is pending. When a terminal outcome arrives, reconcile executions and outstanding quantity. Calculate the replacement from the updated lineage total, using the current authorization and target.

If the venue supports a documented atomic amendment or replacement operation, its guarantees may differ from a client-side cancel followed by create. Preserve the distinction. A single endpoint name does not establish that no execution can occur during its processing or that priority is preserved.

An application can also use an explicit reservation for remaining target quantity while replacement is unresolved. The reservation coordinates internal workers; exchange cancellation requires external evidence. It helps prevent two workers from independently issuing a new order for the same residual amount.

Test several arrival orders

A useful replay includes fill before cancel response, cancel response before delayed fill delivery, duplicate terminal messages, and a disconnect during the race. Assert the combined filled quantity and any remaining open exposure after recovery. A successful cancel API response alone leaves the exposure assertion untested.

When the evidence is incomplete, an unresolved state is more accurate than a guessed completed state. The next agent action can then be evaluated against the uncertainty visible at that moment. If a late fill changes the residual, the trace should show which event caused that change.

Venues differ in cancel semantics, amend behavior, priority treatment, and historical query availability. Product category and account mode may also change the relevant identity fields. The procedure is therefore an adapter design and offline test idea, with guarantees specific to each exchange.

For frontier agent evaluation, the useful question is whether instruction changes remain consistent with verified exposure. A model's plausible explanation of a replacement is insufficient if the underlying quantity arithmetic creates unintended positions.

Fit the receipt into the full trace

Our execution and settlement framework connects these mechanics to recorded outcomes. The operating-layer controls paper explains why the machinery around an agent deserves its own evaluation.