Pass the actual sender and recipient when building a KyberSwap route

The account that requests a price, the account that executes a transaction and the address that receives output can differ. A KyberSwap build request must describe the actual execution context.

KyberSwap's V1 field mapping includes separate sender and recipient build inputs. Preserve that distinction in your internal model instead of deriving both from whichever wallet address is currently displayed.

Identify the caller at the router boundary

For a direct wallet transaction, the selected wallet may be the relevant sender. For a smart account or wrapper contract, trace which address calls the router and supplies the assets. A human owner signing an operation does not automatically become the token holder seen by every contract.

Document the supported execution topology. If the adapter only supports a direct wallet call, reject a wrapper configuration explicitly until its sender, approvals and refund behavior have been implemented.

Make recipient changes invalidate construction

Changing the recipient after route discovery requires a build with that recipient. Changing it after calldata has been produced requires a new executable payload. A label change beside unchanged bytes does not redirect settlement.

Show the full destination through an accessible detail control when the recipient differs from the connected account. A shortened address alone is a weak review aid for this consequential difference.

Simulate the same context

Use the actual caller, destination, data and native value when simulating. Testing from an unrelated funded account can hide the balance and allowance conditions that will apply to the user.

Exercise direct wallet delivery, a distinct recipient and a supported smart-account path separately. Also change accounts while a build is pending. The delayed response should remain tied to its original sender and must not overwrite the new account's review state.