In this track: From send to settlement
The recipient versus the sender
Who authorizes a transaction can differ from who receives an asset.
The person submitting a delivery form, the delivery office and the final recipient can be three different participants.
Maya prepares an instruction: send 0.01 pretend ETH to Leo.
A local simulation. Nothing is signed or sent to a network.
The transaction sender authorizes the instruction
For an ordinary externally owned transaction, the recovered sender is the account whose nonce and balance are considered under transaction rules. A website’s displayed user name is not a replacement for that authorization context.
The destination can be a contract
The to field can point to a smart contract. The final token recipient may then appear inside calldata, while the contract processes the action. Contract creation is a special transaction case without an ordinary destination address.
Nested calls add more participants
When Contract A calls Contract B, B normally sees A as its immediate caller in a standard call. The original transaction sender and the current call’s sender are therefore not always identical. Different low-level call types have their own context rules.
Read the complete path
A transfer interface can hide intermediate contracts or permissions. Start by identifying the transaction destination and decoding the intended function. For deeper reasoning, a call trace shows the nested execution structure.
In a standard call from Contract A to Contract B, who is B’s immediate caller?
The immediate caller depends on the current call frame, not just the original transaction sender.
Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.