Account for partial fills without double counting

Partial-fill accounting needs a ledger of fills, not a progress percentage repeatedly added to a total. Status polling and event subscriptions can report the same settlement more than once.

The 1inch Fusion introduction describes different resolvers filling portions of an order. Other execution modes may not support partial fills, so enable this model only where the protocol documents it.

Use stable fill identity

Associate every fill with the order, chain and a provider or on-chain identity that distinguishes individual fills. Where logs are the evidence, transaction hash plus log position can help distinguish events within one transaction; also retain block identity for reconciliation.

Apply each fill once. Replacing a polling snapshot should reconcile totals rather than append the snapshot's cumulative amount as another fill.

Keep units and outcomes separate

Sum integer quantities per token. A hypothetical order selling 100 units might fill 30, then 20. Its filled input is 50 and remaining input is 50, regardless of how many times the provider reports those two fills.

Output amounts may differ by fill because the execution terms permit different prices. Report actual received totals instead of multiplying the final price by the original order size.

A terminal state does not imply a fully filled order. Expiry or cancellation can leave a settled portion and an unfilled remainder. Store both so history does not erase successful partial execution.

Reconcile revisions

Retain provisional versus confirmed evidence and a policy for chain reorganizations. If a previously observed event disappears from the canonical chain, recompute from retained evidence rather than subtracting a guessed display value.

Test duplicate notifications, out-of-order fills, a cumulative snapshot after event delivery and a partial fill followed by expiry. Assertions should check token totals and remaining quantity, not just whether a spinner disappeared.