Sender, spender and recipient: who does what in a swap?

The sender initiates or authorizes an action, the spender has permission to move input tokens, and the recipient receives output. They can be different addresses. Seeing several addresses in one swap flow is therefore normal, but each needs a clear role.

Separate the three questions

• Who authorizes? A user account may sign a transaction or order.
• Who can transfer the input? A token allowance or another authorization mechanism names a spender.
• Where does the output go? The execution request specifies a recipient, directly or through protocol rules.

The ERC-20 standard distinguishes balances, transfers and third-party spending allowances. 0x's contract guide provides a concrete example in which approval and execution responsibilities differ.

The transaction destination is not always the final recipient

Suppose Alice submits a call to Router R, permits Spender S to transfer Token A, and asks the route to deliver Token B to Bob. The outer transaction's destination is R. The token output recipient is Bob. Reading only the outer destination would misidentify who receives the purchased asset.

This is a hypothetical role map, not a recommendation to authorize any particular contract. Real implementations may combine roles or introduce additional settlement components.

Intermediaries do not necessarily own the economic result

A route may temporarily move tokens through contracts or pools while fulfilling one transaction. These transfers do not mean the user chose each intermediate address as a final beneficiary. The intended result is determined by the complete call and its enforced conditions.

When documenting a swap, label addresses by function rather than pasting an unexplained list. “Transaction target,” “approved spender” and “output recipient” are more informative than “swap address.” This vocabulary also makes inconsistencies easier to discuss: an unexpected recipient is a different issue from a different execution contract or an absent allowance.

For smart accounts and delegated execution, the transaction submitter can introduce another role. Avoid assuming that the account paying network charges must also own the input tokens.