Keep KyberSwap route discovery and building separate

KyberSwap's ordinary V1 integration has two useful boundaries: discover a route, then build the transaction for that route. A route summary is an input to construction, not itself wallet calldata.

The official V1 migration document specifies GET /{chain}/api/v1/routes followed by POST /{chain}/api/v1/route/build. The build request carries the returned route summary alongside execution settings.

Keep the handoff intact

Store the summary as provider-owned data, associated with the request that produced it. Do not rebuild it from a displayed list of pools or strip fields because the interface does not use them. Display data and build inputs have different completeness requirements.

When the user reaches execution review, verify the chain, tokens, amount and selected route generation before building. If the form changed, obtain a new summary instead of editing token addresses inside the old one.

Do not confuse endpoint families

The current EVM specification also describes a gated combined swap endpoint with execution-intent restrictions. A preview polling loop should use the documented preview path, not assume every endpoint is interchangeable.

Keep gateway configuration and required headers in the backend adapter. Track the chosen API family explicitly so a legacy response cannot accidentally pass through a V1 parser.

Validate the built result

Check the destination, encoded data, value and execution context before asking the wallet to send. A successful route search establishes that a candidate was found; it does not establish allowance, available balance or final simulation success.

A useful test swaps the build response of two simultaneous route requests. The adapter should detect the request mismatch before the transaction reaches review.