Normalize aggregator responses without losing meaning

Normalize the fields needed for comparison, but retain the original executable artifact. Flattening every provider into one to/data/value shape loses the distinction between transactions, route builders and signed orders.

A small comparison layer

A proposed model includes provider, chain, trade direction, exact input or output amount, expected counter-amount, token identities, cost fields with units, expiry and executionKind. Each cost should state whether it is paid in the input token, output token or native currency, and whether it is already reflected in the displayed amount.

Keep unknown separate from zero. Missing gas cost on an intent candidate does not prove that execution is economically free. A null USD conversion does not justify converting it into a zero-dollar fee.

PancakeSwap's payload reference contains both a normalized candidate and distinct underlying agg or pcsx objects. It also identifies fixed-point gas-cost data and different units inside nested payloads. These details show why a shallow rename map is not enough.

Preserve provider semantics

Store the validated raw response or a lossless typed representation behind a provider-specific adapter. The execute step should consume that artifact together with the original request snapshot. Never rebuild its signed terms from rounded comparison-table values.

Use exhaustive branching when executionKind changes. An unknown new provider mode may still be visible as unsupported, but must not default to the transaction path.

Fixture design

Include one response for each execution kind, one with omitted optional costs and one with identical-looking numbers expressed in different units. Verify that comparison fields normalize correctly while the execution artifact stays unchanged. This is more useful than asserting that every provider response happens to have the same list of keys.