Transaction context (tx.origin vs msg.sender) in Blockchain / Solidity - Practice Questions

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of msg.sender vs tx.origin in nested calls

Consider two contracts: A calls B. What will be the output of msg.sender and tx.origin inside contract B when A calls B?

Blockchain / Solidity

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

contract A {
    B b;
    constructor(address _b) {
        b = B(_b);
    }
    function callB() public view returns (address, address) {
        return b.check();
    }
}

A msg.sender is the original external caller's address; tx.origin is A's address

B msg.sender is A's address; tx.origin is the original external caller's address

C Both msg.sender and tx.origin are the original external caller's address

D Both msg.sender and tx.origin are A's address

💡 Hint

Remember that msg.sender is the immediate caller, while tx.origin is the original external account that started the transaction.

Inside contract B, msg.sender is the address of contract A because A called B. The tx.origin remains the original external account that initiated the transaction, not the intermediate contract.

❓ Predict Output

intermediate

Detecting phishing with tx.origin

What will be the output of the following Solidity function if called by an external user directly?

function isOwner() public view returns (bool) {
    return tx.origin == owner;
}

Blockchain / Solidity

address owner = 0x1234567890123456789012345678901234567890;

function isOwner() public view returns (bool) {
    return tx.origin == owner;
}

A Returns true if the external caller is the owner

B Returns true if the immediate caller is the owner

C Always returns false

D Causes a compilation error

💡 Hint

tx.origin is the original external account that started the transaction.

The function compares tx.origin (the external account that started the transaction) to the stored owner address. If they match, it returns true.

🔧 Debug

advanced

Why does this contract allow phishing via tx.origin?

Consider this contract snippet:

function withdraw() public {
    require(tx.origin == owner, "Not owner");
    payable(msg.sender).transfer(address(this).balance);
}

What is the security risk here?

A An attacker can trick the owner into calling a malicious contract that calls withdraw, bypassing the check

B The require statement will always fail because tx.origin is never the owner

C The contract will run out of gas due to infinite recursion

D There is no risk; tx.origin is safe to use here

💡 Hint

Think about how tx.origin can be manipulated by intermediate contracts.

Using tx.origin for authorization is dangerous because an attacker can create a malicious contract that the owner calls. The tx.origin remains the owner, so the check passes, but the attacker controls the call flow, allowing unauthorized withdrawals.

📝 Syntax

advanced

Identify the error in this Solidity function using tx.origin

Which option correctly fixes the syntax error in this function?

function checkOrigin() public view returns (bool) {
    if tx.origin == owner {
        return true;
    } else {
        return false;
    }
}

A Change function to external instead of public

B Replace tx.origin with msg.sender

C Remove the else block entirely

D Add parentheses around the condition: if (tx.origin == owner) { ... }

💡 Hint

Check the syntax for if statements in Solidity.

In Solidity, the condition in an if statement must be enclosed in parentheses. The original code misses these parentheses, causing a syntax error.

🚀 Application

expert

Design a secure authorization check avoiding tx.origin pitfalls

You want to restrict a function so only the contract owner can call it. Which approach is the most secure?

A Use <code>require(tx.origin != owner)</code> to block the owner

B Use <code>require(msg.sender != owner)</code> to block the owner

C Use <code>require(msg.sender == owner)</code> to check the immediate caller

D Use <code>require(tx.origin == owner)</code> to check the original transaction sender

💡 Hint

Consider how intermediate contracts affect msg.sender and tx.origin.

Using msg.sender ensures the immediate caller is the owner, preventing phishing attacks that exploit tx.origin. Checking tx.origin is unsafe because it can be manipulated by malicious contracts.

Practice

1. What does tx.origin represent in a blockchain transaction?

easy

A. The original external account that started the transaction

B. The immediate caller of the current function

C. The contract address executing the function

D. The miner who included the transaction in a block

Solution

1. Step 1: Understand the meaning of tx.origin

   tx.origin always points to the external account that initiated the transaction, regardless of how many contracts are called.

2. Step 2: Differentiate from msg.sender

   msg.sender is the immediate caller, which can be a contract or an account, but tx.origin is always the original external user.

3. Final Answer:

   The original external account that started the transaction -> Option A

4. Quick Check:

   tx.origin = original external account [OK]

Hint: Remember: tx.origin is the original user, msg.sender is immediate caller [OK]

Common Mistakes:

• Confusing tx.origin with msg.sender
• Thinking tx.origin changes in internal calls
• Assuming tx.origin is always a contract

2. Which of the following is the correct way to check if the caller is the owner using msg.sender in Solidity?

easy

A. require(owner == block.coinbase);

B. require(tx.origin == owner);

C. require(owner == tx.origin);

D. require(msg.sender == owner);

Solution

1. Step 1: Identify the correct variable for immediate caller

   To check the caller of the function, msg.sender is used because it represents the immediate caller.

2. Step 2: Verify the syntax of the require statement

   The correct syntax is require(msg.sender == owner); to ensure only the owner can proceed.

3. Final Answer:

   require(msg.sender == owner); -> Option D

4. Quick Check:

   Use msg.sender for permission checks [OK]

Hint: Use msg.sender for permission checks, not tx.origin [OK]

Common Mistakes:

• Using tx.origin for permission checks
• Swapping owner and caller in comparison
• Using block.coinbase which is miner address

3. Consider this Solidity code snippet:

contract Test {
    address owner;
    constructor() {
        owner = msg.sender;
    }
    function checkOrigin() public view returns (bool) {
        return tx.origin == owner;
    }
}

If an external user calls checkOrigin() directly, what will be the returned value?

medium

A. false

B. true

C. Compilation error

D. Revert due to permission error

Solution

1. Step 1: Understand owner assignment in constructor

   The owner is set to msg.sender when the contract is deployed, which is the external user deploying it.

2. Step 2: Analyze checkOrigin() call by external user

   When the external user calls checkOrigin(), tx.origin is the same external user who deployed the contract (owner), so the comparison returns true.

3. Final Answer:

   true -> Option B

4. Quick Check:

   Direct call: tx.origin equals owner [OK]

Hint: Direct calls: tx.origin equals msg.sender equals owner [OK]

Common Mistakes:

• Assuming tx.origin differs from msg.sender on direct calls
• Confusing owner initialization
• Expecting errors from this code

4. Given this Solidity code:

contract Caller {
    address owner;
    function callCheck(address callee) public view returns (bool) {
        (bool success, ) = callee.call(abi.encodeWithSignature("checkOrigin()"));
        return success;
    }
}

contract Callee {
    address owner;
    constructor() {
        owner = msg.sender;
    }
    function checkOrigin() public view returns (bool) {
        return tx.origin == owner;
    }
}

What is the main issue with the callCheck function in Caller?

medium

A. It causes a compilation error due to missing payable keyword

B. It compares tx.origin instead of msg.sender inside checkOrigin

C. It uses low-level call incorrectly and ignores return value unpacking

D. It sets owner incorrectly in Callee constructor

Solution

1. Step 1: Analyze the use of low-level call in callCheck

   The call returns (bool, bytes), but the code only returns the bool from call without decoding the actual function's return value.

2. Step 2: Understand the consequence of ignoring return data

   Because the function ignores the returned bytes, it cannot get the actual boolean result from checkOrigin(), leading to incorrect or misleading results.

3. Final Answer:

   It uses low-level call incorrectly and ignores return value unpacking -> Option C

4. Quick Check:

   Low-level call needs return data decoding [OK]

Hint: Low-level call returns bytes; decode to get function result [OK]

Common Mistakes:

• Blaming tx.origin usage instead of call misuse
• Ignoring that call returns (bool, bytes)
• Assuming owner is set wrongly

5. You want to design a contract that only allows the original external user who started a transaction to execute a sensitive function, even if called through multiple contracts. Which is the safest way to implement this check?

hard

A. Use require(tx.origin == owner); to check the original external account

B. Use require(msg.sender == owner); to check the immediate caller

C. Use require(tx.origin == msg.sender); to ensure both are equal

D. Use require(owner == address(this)); to check contract address

Solution

1. Step 1: Understand the difference between msg.sender and tx.origin

   msg.sender is the immediate caller, which can be a contract, while tx.origin is the original external account that started the transaction.

2. Step 2: Choose the check that ensures original user authorization

   To ensure only the original external user can execute the function, use require(tx.origin == owner); because it tracks the transaction origin through multiple calls.

3. Final Answer:

   Use require(tx.origin == owner); to check the original external account -> Option A

4. Quick Check:

   Original user check uses tx.origin [OK]

Hint: Use tx.origin to track original external user through calls [OK]

Common Mistakes:

• Using msg.sender which can be a contract
• Comparing tx.origin to msg.sender incorrectly
• Checking contract address instead of user