A 1inch Fusion order is not Classic swap calldata

A Fusion integration should not reuse a Classic swap's “send transaction, wait for receipt” workflow unchanged. The user authorizes an order, and settlement happens through a different actor and lifecycle.

The 1inch Intent Swap introduction describes Fusion orders filled by resolvers through a variable-rate auction. It also describes partial fills. These properties affect data modeling even when the interface resembles an ordinary token swap.

Keep three records

Store the requested trade, the signed order and each observed settlement separately. The order identifier is not a transaction hash. A submission acknowledgement should move the order into an accepted or pending state rather than completing the trade.

Track the order's validity interval and economic bounds using the provider's documented representation. A displayed estimated output should not overwrite the signed minimum or auction terms.

Make authorization review explicit

Inspect the typed-data domain, chain, tokens, amount and validity conditions before asking for a signature. Handle any token permission prerequisite separately. Describing resolver-paid settlement as gasless does not justify omitting a prerequisite that the user's token or account still needs.

If the account or chain changes while signing, retain the result only under its original context. Do not attach it to a new active form.

Reconcile fills and terminal outcomes

Aggregate confirmed fills without counting the same event twice. Distinguish a fully filled order from one that partially filled and then expired or was cancelled. Show the actual settled amounts and the unfilled remainder.

Keep polling or another documented status mechanism independent of the wallet connection. A user closing the signature modal or switching screens does not revoke an already submitted order. Recovery should resume observation from the stored order identifier, not automatically create a replacement order.