Build an order state machine for intent-based swaps

An intent order can be accepted without being filled, and a fill can be observed before the application's status service catches up. A useful state machine must represent both facts without declaring success too early.

Separate authorization from observation

A proposed application lifecycle includes draft, awaiting signature, signed, submitting, accepted, partially filled and terminal outcome. Add an unknown-submission state for a request whose acknowledgement was lost. Exact provider states differ, so map them rather than assuming they match your internal names.

The PancakeSwap Unified API, for example, distinguishes order submission from a later status lookup keyed by order hash. That order identity should not be replaced by a quote identifier or a settlement transaction hash.

Store evidence with transitions

Do not let a delayed “open” response overwrite a newer confirmed fill. Track observation time and provider ordering information where available. If evidence conflicts, retain an explicit reconciliation state.

Recover without multiplying orders

After a timeout, look up the known order before creating another signature. A lost HTTP response does not show that submission failed. Repeated orders may authorize multiple independent fills.

Keep lifecycle tracking alive when the wallet disconnects or the review screen closes. These events remove interaction context, not necessarily the order's validity.

Test acknowledgement loss, status lag, duplicate fill notifications and expiry after a partial fill. Each has a different result from a clean rejection before the order was accepted.