tx.origin vs msg.sender in Solidity: The Auth Bug That Won't Die

The Bug in One Sentence

`tx.origin` is the EOA at the bottom of the call stack. `msg.sender` is whoever called you directly. If you authorize on `tx.origin`, you've handed your contract's keys to every contract your users will ever interact with.

This vulnerability has been documented since 2018. It still ships. I've personally flagged it in three audits in the last year — including one protocol with eight figures TVL planning mainnet launch.

How the Phishing Attack Works

Here's the vulnerable pattern. A simple wallet contract that lets the owner withdraw:

```solidity
// VULNERABLE — do not deploy
contract Wallet {
address public owner;

constructor() {
owner = msg.sender;
}

function transfer(address payable to, uint256 amount) external {
require(tx.origin == owner, "not owner");
to.transfer(amount);
}
}
```

Looks fine. Owner can withdraw, nobody else can. Right?

Now the attacker deploys this:

```solidity
contract Phish {
Wallet immutable target;
address payable immutable attacker;

constructor(Wallet _target, address payable _attacker) {
target = _target;
attacker = _attacker;
}

// Bait: a free mint, an airdrop claim, anything to get owner to call this
function claimAirdrop() external {
target.transfer(attacker, address(target).balance);
}
}
```

Attacker DMs the owner: "hey bro free NFT here, just call `claimAirdrop()`." Owner signs the transaction. The call path is:

`Owner EOA -> Phish.claimAirdrop() -> Wallet.transfer()`

Inside `Wallet.transfer()`:
- `msg.sender` = `Phish` contract address — would fail the check
- `tx.origin` = `Owner` EOA — **passes the check**

Funds drained. The owner approved nothing related to a transfer — they just clicked a button on a malicious dApp.

The Fix

Use `msg.sender`. That's it.

```solidity
contract Wallet {
address public owner;

constructor() {
owner = msg.sender;
}

function transfer(address payable to, uint256 amount) external {
require(msg.sender == owner, "not owner");
to.transfer(amount);
}
}
```

Now the attacker's phishing contract is `msg.sender`, the check fails, funds are safe. OpenZeppelin's `Ownable` does exactly this — use it instead of rolling your own.

Real-World Damage

The classic example everyone references is the Ethernaut Level 4 (`Telephone`) — a deliberate teaching exercise of this exact pattern. But it's not just CTFs.

This pattern has caused losses in:

Numerous **personal multisig wallets and treasury contracts** built before 2020 where teams rolled their own access control
- Several **token contracts** where minting or admin functions gated on `tx.origin` were exploited via malicious approval flows
- A recurring pattern in **proxy/forwarder contracts** where developers tried to "see through" a trusted forwarder using `tx.origin` instead of implementing ERC-2771 properly

Individual losses range from a few ETH up to seven figures, but unlike a single big hack, this vulnerability bleeds out across hundreds of small contracts. Static analyzers (Slither, Mythril) flag it instantly — which tells you something about the code that ships with it: it was never reviewed. A quick pass through our [free AI audit](https://www.cryptohawking.com/audit) catches this in seconds.

"But I Need to Know the User is an EOA"

This is the only legitimate-looking reason people reach for `tx.origin`. Patterns like:

```solidity
// Trying to block contract callers (e.g. anti-bot for mints)
require(tx.origin == msg.sender, "no contracts");
```

This works today, sort of. But:

1. **It's discouraged by Vitalik and the EIP authors.** Account abstraction (EIP-4337, EIP-7702) breaks the assumption that there's always an EOA at the origin. Smart contract wallets are mainstream now — Safe, Argent, Coinbase Smart Wallet. Your "anti-bot" check just blocks all of them.
2. **It doesn't even stop bots.** A determined bot deploys a contract that calls your mint directly in `constructor()` — at that moment `tx.origin == msg.sender == address(constructor caller)` is still an EOA. Use commit-reveal or allowlists instead.

The One Place tx.origin Almost Makes Sense: Meta-Transactions

In a **meta-transaction** flow (gasless transactions), a relayer pays gas to forward a signed message from a user. Inside the target contract:

`msg.sender` = the trusted forwarder contract
- `tx.origin` = the relayer's EOA (NOT the user)
- The actual user is appended to calldata, per **ERC-2771**

Notice: `tx.origin` is **still not the user**. So `tx.origin` is useless here too. The correct pattern is to inherit `ERC2771Context` and use `_msgSender()`:

```solidity
import "@openzeppelin/contracts/metatx/ERC2771Context.sol";

contract MyApp is ERC2771Context {
constructor(address trustedForwarder)
ERC2771Context(trustedForwarder) {}

function doThing() external {
address user = _msgSender(); // extracts real user from calldata
// ...
}
}
```

`_msgSender()` returns `msg.sender` for direct calls and the calldata-appended user for forwarded calls. This is the right abstraction. `tx.origin` has no role.

When `tx.origin` Has Zero Legitimate Use

Let me be specific. In production Solidity, do **not** use `tx.origin` for:

Authorization (`require(tx.origin == owner)`)
- Distinguishing users from contracts (use `_msgSender()` or commit-reveal)
- Anything in a meta-transaction flow (use ERC-2771)
- Identifying "the real user" (it's not — relayers exist)
- Bypassing reentrancy concerns (use `nonReentrant`)

The one place it appears in real codebases without being a bug is logging/analytics events — and even there, I'd push back in code review.

Audit Checklist

When reviewing a contract, grep for `tx.origin`. For each hit:

1. Is it in a `require` or `if`? Probably a bug. Replace with `msg.sender` or `_msgSender()`.
2. Is it being compared to `msg.sender` for EOA-only logic? Flag it — AA wallets will break, and it's not a real security control anyway.
3. Is it in an event? Acceptable, but consider whether you actually need it.

For protocols with significant TVL, static analysis isn't enough — call patterns through proxies, forwarders, and hooks create combinations that automated tools miss. That's the kind of thing a [manual audit](https://www.cryptohawking.com/audit/manual) catches before mainnet.

TL;DR

Use `msg.sender`. If you're building meta-transactions, use ERC-2771's `_msgSender()`. If you reached for `tx.origin`, stop and ask why — there's a 99% chance there's a better primitive. The 1% case is so niche that if you're reading this article to figure out which case you're in, you're not in it.