Why You Should Never Use tx.origin for Authentication in Solidity

The Bug in One Sentence

`tx.origin` is the address that *kicked off* the transaction. `msg.sender` is whoever is calling you *right now*. If you authenticate with the former, anyone your user touches can drain them.

This is SWC-115, and it has been in Solidity's footgun hall of fame since 2016. It still ships in production code in 2025, usually because somebody copy-pasted from a tutorial written by a person who shouldn't be writing tutorials.

How the Phishing Attack Works

Imagine a personal wallet contract that lets the owner transfer funds:

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

constructor() {
owner = msg.sender;
}

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

Looks fine, right? The owner is the only person who can transfer. Now an attacker deploys this:

```solidity
contract Phish {
Wallet public victimWallet;
address payable public attacker;

constructor(Wallet _w, address payable _a) {
victimWallet = _w;
attacker = _a;
}

// Bait: free NFT mint, airdrop claim, whatever
function claimAirdrop() external {
victimWallet.transfer(attacker, address(victimWallet).balance);
}
}
```

The attacker shills `claimAirdrop()` on Twitter. The owner of `Wallet` calls it. Now the call stack is:

`tx.origin` = victim (the EOA that signed the tx)
- `msg.sender` inside `Wallet.transfer` = `Phish` contract

The `require(tx.origin == owner)` check **passes**, because `tx.origin` is still the victim. The wallet drains itself to the attacker. The victim signed nothing about a transfer. They thought they were minting a JPEG.

This is the entire bug class. Every contract that uses `tx.origin` for auth is a phishing kit waiting for a victim.

The Fix

Replace it with `msg.sender`:

```solidity
// FIXED
contract Wallet {
address public owner;

constructor() {
owner = msg.sender;
}

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

Now when `Phish` calls `transfer`, `msg.sender` is the `Phish` contract, not the victim. The check fails. The victim still loses some gas, but their funds are safe.

That's it. One word. The compiler even warns you about this since Solidity 0.7 if you crank up the linter, and tools like Slither flag it as a high-severity issue by default. If you're not running [a free AI audit](https://www.cryptohawking.com/audit) on every commit, you should be — this is the kind of thing static analysis catches in under a second.

When Is tx.origin Actually OK?

There are exactly two legitimate uses I've seen in five years of auditing:

1. **Refunds and gas rebates.** You want to send gas back to the human, not the relayer contract. `tx.origin` is fine here because you're paying them, not authorizing them.
2. **Explicitly rejecting contract callers.** `require(tx.origin == msg.sender)` ensures the caller is an EOA, not a contract. This was popular for limiting flash-loan-style sandwich attacks. But ERC-4337 account abstraction breaks this assumption — a legitimate smart wallet user will fail your check. In 2025, this pattern is increasingly hostile to real users. Use commit-reveal or per-block rate limits instead.

Everything else: use `msg.sender`.

Real-World Incidents

There's no single billion-dollar `tx.origin` hack the way there's a famous reentrancy hack, because the bug is so well-known that mainstream protocols stopped shipping it years ago. Where it does show up:

**Personal wallet contracts and "smart" multisigs written by individuals**, especially before 2020. Vitalik Buterin himself warned about this pattern in 2016 on the Ethereum Stack Exchange and it became the canonical phishing vector example.
- **NFT mint contracts** with custom `onlyOwner`-style modifiers built by teams who learned Solidity from a YouTube video. I've personally flagged this in three audits in the last 18 months, each time on contracts holding mid-six-figure treasuries.
- **Forked DeFi protocols** where the original used `msg.sender` and the fork "improved" it. Reader, they did not improve it.

The attacks are quiet because they're targeted — phishing one whale doesn't make headlines like a $600M bridge exploit. But the cumulative losses across years of low-key drains are real.

Detection Checklist

Before you ship, grep your repo:

```
grep -rn "tx.origin" contracts/
```

For every hit, ask: *is this an authorization check?* If yes, it's a bug. If it's a refund destination or an EOA gate (and you've thought about ERC-4337 users), it might be fine. Document why.

Automated tools that catch this:

**Slither**: `tx-origin` detector, runs in seconds
- **Mythril**: flags it under SWC-115
- **Solhint**: `avoid-tx-origin` rule
- **Solidity compiler**: emits a warning when you use `tx.origin` in a comparison

If none of those are in your CI, add them today. If you want a human to sanity-check before mainnet, a [manual audit from us](https://www.cryptohawking.com/audit/manual) runs $5,000 in ETH/SOL/USDT with a three business day turnaround — cheap insurance compared to a drained treasury.

TL;DR

`tx.origin` = the human at the start of the call chain.
- `msg.sender` = whoever is calling your function right now.
- Use `msg.sender` for authentication. Always.
- The only honest uses of `tx.origin` are gas refunds and explicit EOA-only gates (and even the latter is increasingly broken in an account-abstraction world).
- This is a fifteen-second fix. Don't be the one whose users get phished because you skipped it.