tx-context-misuselisted

# tx.origin / timestamp / block-number misuse ## When this applies - Auth checks using `tx.origin` - Time-based logic (lockups, deadlines, vesting, auctions) - Block-number-based rate limits or cooldowns - L2 deployments where block semantics differ from L1 - Randomness derived from block data ## Detection patterns ### `tx.origin` for authorization (HIGH) ```solidity require(tx.origin == owner); // ← phishable via intermediate contract ``` A contract the owner has interacted with can drain by calling back into this function — owner-EOA is `tx.origin` even if direct caller is the malicious contract. Exception: `tx.origin == msg.sender` check to enforce EOA-only is *sometimes* valid for limiting bots — but EIP-7702 will invalidate even this. Flag as outdated pattern. ### `block.timestamp` for high-precision deadlines (MEDIUM) Miners (post-merge: validators) can skew timestamp ±~15s. Don't use for sub-15s precision. ### `block.timestamp` as randomness (HIGH) ```solidity uint r = uint(keccak256(abi.encode(block.timestamp, msg.sender))); // ← validator can simulate ``` ### `block.number` on L2 (HIGH) Arbitrum: `block.number` is L1 block number, NOT L2. `block.timestamp` is L2. Optimism: `block.number` is L2. Get this wrong and rate limits fire 12x too fast (or too slow). ### `blockhash(n)` with `n` outside `[block.number-256, block.number-1]` returns 0 (MEDIUM) Random distribution becomes biased / predictable. ### `block.coinbase` (validator address) used in logic (H