Transaction context (tx.origin vs msg.sender) in Blockchain / Solidity - Visual Side-by-Side Comparison

Concept Flow - Transaction context (tx.origin vs msg.sender)

User initiates transaction

↓

tx.origin = User

↓

Contract A receives call

↓

msg.sender = User (if direct call) OR Contract B (if called by Contract B)

↓

Contract B calls Contract A

↓

msg.sender = Contract B

↓

tx.origin still = User

↓

Contract A uses tx.origin or msg.sender

↓

Action depends on which is used

Shows how tx.origin stays the original user, while msg.sender changes with each call in the call chain.

Execution Sample

Blockchain / Solidity

contract A {
  function check() public view returns (address, address) {
    return (tx.origin, msg.sender);
  }
}

Contract A returns the original transaction sender and the immediate caller.

Execution Table

Step	Caller	tx.origin	msg.sender	Returned Values	Explanation
1	User calls Contract A directly	User	User	(User, User)	Direct call: both tx.origin and msg.sender are User
2	User calls Contract B	User	User	-	User initiates transaction, tx.origin=User, msg.sender=User in Contract B
3	Contract B calls Contract A	User	Contract B	-	Inside Contract A, msg.sender is Contract B, tx.origin still User
4	Contract A returns	User	Contract B	(User, Contract B)	Return from Contract A shows tx.origin=User, msg.sender=Contract B
5	End	-	-	-	Execution ends after return

💡 Execution stops after Contract A returns the addresses.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
tx.origin	undefined	User	User	User	User
msg.sender	undefined	User	User	Contract B	Contract B

Key Moments - 3 Insights

Why is tx.origin always the original user even inside multiple contract calls?

Because tx.origin tracks the very first external account that started the transaction, as shown in execution_table rows 2 and 3 where tx.origin remains 'User' despite calls between contracts.

Why does msg.sender change when one contract calls another?

msg.sender is the immediate caller of the current function, so when Contract B calls Contract A, msg.sender inside Contract A is Contract B, as seen in execution_table row 3.

Can using tx.origin for authorization be risky?

Yes, because tx.origin does not change through contract calls, a malicious contract can trick a user into calling it, then call another contract where tx.origin is still the user, potentially bypassing msg.sender checks.

Visual Quiz - 3 Questions

Look at the execution_table, what is msg.sender inside Contract A when called by Contract B?

A Contract B

B User

C Contract A

D tx.origin

💡 Hint

Check execution_table row 3 where Contract B calls Contract A.

At which step does tx.origin remain the same despite different msg.sender values?

A Step 1

B Step 3

C Step 2

D Step 5

💡 Hint

Look at execution_table rows 2 and 3 for tx.origin values.

If Contract A used msg.sender for authorization, who would it trust when called by Contract B?

A User

B tx.origin

C Contract B

D Itself

💡 Hint

msg.sender is the immediate caller, see execution_table row 3.

Concept Snapshot

tx.origin is the original external user who started the transaction.
msg.sender is the immediate caller of the current function.
In multi-contract calls, tx.origin stays the same, msg.sender changes.
Using tx.origin for security can be dangerous.
Prefer msg.sender for authorization checks.

Full Transcript

This visual trace shows how in blockchain transactions, tx.origin always holds the address of the original user who started the transaction, while msg.sender changes depending on who called the current contract function. When a user calls Contract B, and Contract B calls Contract A, inside Contract A, tx.origin is still the user, but msg.sender is Contract B. This difference is important for security because using tx.origin for authorization can be risky if a malicious contract tricks a user. The execution table steps through these calls, showing variable values and returned results. Key moments clarify why tx.origin remains constant and msg.sender changes, and the quiz tests understanding of these concepts.