Transaction Sender

Overview

The transaction sender is commonly the account whose authorization is validated for the top-level transaction. On Ethereum-style networks, the sender can be derived from the signature and is associated with the nonce. In a UTXO transaction, there may be several input owners and no single native sender. A wallet interface may infer one for convenience, but the protocol data is more granular.

Modern execution models separate roles further. A relayer can submit bytes on behalf of a user, a paymaster can cover fees, and a Smart Account can validate a user operation through custom logic. A contract then becomes the caller for internal calls. The original user, fee payer, top-level Sender Address, and immediate execution caller may all be different entities.

This distinction matters for permissions and monitoring. A contract may authorize an action based on the immediate caller, an embedded signed message, or the smart account’s validation result. Analytics that attribute every internal transfer to the top-level sender can be misleading. Likewise, a sender address is not reliable proof of legal identity or beneficial ownership.

Payment and compliance systems should preserve protocol-native sender fields, recovered signers, fee payer, relayer, smart-account address, and relevant internal callers. Documentation should state which one drives customer matching or policy checks. Outgoing systems should confirm the intended authority and source of funds before signing, especially when delegation or sponsored execution is used.

Implementations should keep the top-level sender, recovered signers, smart account, relayer, fee payer, and relevant internal callers. That context supports investigation because modern authorization flows split initiation, fee payment, and execution authority across several roles. Controls also need to state which role drives permissions, customer attribution, compliance checks, and source-of-funds reporting.