Integration engineering

Cancellation requests need their own confirmation state

Represent cancellation as a requested action until the provider or chain confirms that the unfilled order can no longer execute.

A cancellation button initiates a process; it does not by itself prove that a signed intent is no longer fillable. The interface needs to distinguish cancellation requested from cancellation confirmed.

EIP-712 defines typed-data signing but does not supply replay protection or a universal cancellation mechanism. The order protocol must define the conditions under which a signature stops authorizing execution.

Identify the cancellation mechanism

Depending on the protocol, cancellation may involve an off-chain service policy, an on-chain nonce or order invalidation, or another documented operation. Do not infer that deleting a local record or removing an order from a website invalidates its signature everywhere.

Model supported cancellation capabilities explicitly in the adapter. If only expiry is supported, say so. Do not offer a button whose actual effect is merely to stop polling.

Handle the fill race

A fill can occur while cancellation is being processed. Continue observing settlement until the outcome is reconciled. If part of an order filled first, the terminal result may be “partially filled, remainder cancelled” rather than “cancelled” with zero activity.

When cancellation itself is an on-chain transaction, retain its hash and receipt separately from swap fills. A submitted cancellation transaction is still pending and may compete with execution.

Make replacement deliberate

Do not automatically issue a replacement order while the first remains fillable. If the product permits overlapping orders, the user needs to understand the combined authorized spend and the application must account for both.

A useful fixture delivers a fill event between cancellation request and acknowledgement. Another loses the acknowledgement entirely. The application should keep observing the original order, preserve any settled amounts and avoid presenting uncertainty as a guaranteed cancellation.

Cancellation records belong in history even when no assets moved. They explain why an order stopped being eligible and help prevent accidental resubmission after a restart.

Sources & verification (1)

Source-check date is recorded in the article details. URLs are provided for manual verification. Use Copy to keep this page open.

  1. EIP-712

    Typed data domains, no automatic replay protection

    https://eips.ethereum.org/EIPS/eip-712

Continue reading

Swap API integration: quote, approve, simulate, submit