Validate the swap recipient separately from the sender

Supporting a different output recipient requires more than adding an address box. The provider must support that role combination, the built transaction must encode it, and the review screen must make the destination clear.

Start with provider capabilities

Do not assume an endpoint parameter named recipient always means an arbitrary payout address. The PancakeSwap Unified Swap reference uses recipient as the signer and output recipient for its X path; a third-party payout is not expressible through that interface. Other execution paths can have different semantics.

Model sender, signer and recipient separately in your application, then let the adapter reject combinations it cannot encode. A rejected capability is preferable to quietly substituting the sender and delivering funds somewhere other than the address the user reviewed.

Bind resolution to confirmation

For a plain address, validate format and the chosen chain context. If the form accepts a human-readable name, resolve it explicitly and show the resulting address. Save the resolved value in the trade snapshot. A new resolution result should require a new review rather than silently changing a transaction that is ready to sign.

Do not infer ownership from a token transfer history or a matching display name. Likewise, detecting deployed code does not establish that a recipient contract can use the chosen asset.

After the swap

Reconcile the output against the selected recipient. Reading only the sender's balance may falsely report that a successful third-party payout delivered nothing. Save the recipient alongside the attempt ID, chain and transaction hash so support staff can inspect the intended destination without reconstructing it from an old browser session.

Useful fixtures include a malformed address, a name whose resolution changes, a provider that forbids separate recipients and an account switch after recipient selection.