Detailed answer
Key technical distinctions: msg.sender is the immediate caller (could be a contract); tx.origin is the original EOA — never use tx.origin for authentication. bytes32 is fixed-size and cheaper than string; use bytes32 for identifiers and hashes. SafeERC20 handles non-standard ERC-20 tokens correctly. Function selector clashing in proxies requires careful design to avoid security vulnerabilities.
Q1: What is the difference between msg.sender and tx.origin?
msg.sender is the immediate caller of a function — could be a contract. tx.origin is the original externally owned account (human wallet) that initiated the entire transaction. Never use tx.origin for authentication — it's vulnerable to phishing attacks. Always use msg.sender.
Q2: Why do some contracts use address(0) for burns instead of token.burn()?
Sending to address(0) works for tokens that don't implement a burn function. Tokens with built-in burn functions are preferable as they reduce totalSupply, which affects share pricing calculations in vaults and governance power calculations.
Q3: What is the purpose of the indexed keyword in events?
Indexed event parameters are stored in the blockchain's bloom filter, enabling efficient filtering in event logs. Non-indexed parameters are in the data field. Maximum 3 indexed parameters per event. Index parameters you'll frequently filter by (addresses, IDs).
Q4: When should I use bytes32 vs string?
bytes32 is fixed-size, cheaper, and can be used as a mapping key. string is variable-size, more expensive, and cannot be a mapping key. Use bytes32 for: identifiers, hashes, fixed-length codes. Use string for: user-facing content, variable-length text.
Q5: What is the Checks-Effects-Interactions pattern?
Always verify preconditions (checks) before modifying state (effects) before making external calls (interactions). This prevents reentrancy attacks where the external call re-enters your function before state updates complete.
Q6: Why use SafeERC20 instead of calling ERC20 directly?
Some ERC-20 tokens don't correctly return bool from transfer/transferFrom. SafeERC20 wraps these calls to handle both compliant and non-compliant tokens safely, reverting if the transfer didn't succeed regardless of whether the token signals this via return value.