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.