Unbounded loops can make functions exceed block gas limits as state grows, permanently preventing execution—classic denial of service. This is common in airdrop distributions, iterating holders, or clearing arrays. Security interviews test this because it’s a real production failure: “worked in tests” but becomes uncallable at scale. Mitigations include batching/pagination and off-chain indexing.

In upgradeable contracts, the proxy holds storage while the implementation code changes. If developers reorder variables or change types, storage slots map incorrectly—corrupting balances, roles, or critical pointers. This is a high-severity issue in audits. Interviewers expect candidates to mention append-only storage layout, storage gaps, and standards like EIP-1967 for proxy slots.

tx.origin authorization can be bypassed if a user is tricked into calling an attacker contract, which then calls the target contract—tx.origin remains the user. This is a known insecure pattern in Ethereum security. Interviewers like it because it tests whether candidates understand call chains and why msg.sender + explicit access control is the correct boundary.

immutable variables are assigned once (typically in the constructor) and then become read-only. They are stored in bytecode rather than regular storage slots, which can reduce gas compared to storage reads. This matters in Solidity interviews because immutables are common in optimized contracts (e.g., router addresses) and in secure configuration patterns.

Minimal proxy clones (EIP-1167) keep logic in an implementation and rely on proxy bytecode forwarding calls, making deployment cheap. In practice, immutables in the implementation help keep runtime reads efficient and reduce repeated storage reads for configuration-like values. Candidates are often tested on why clones save gas and how configuration is safely handled.

The Checks-Effects-Interactions (CEI) pattern reduces reentrancy by making you validate inputs and update internal state before any external call (like ETH transfer or token transfer). If a malicious contract re-enters, state has already moved forward, limiting exploitability. Many interviewers treat CEI as a must-know Solidity security habit for production contracts

Low-level CALL (and friends like DELEGATECALL) returns a success flag rather than automatically bubbling a revert. If you don’t check that boolean (or decode return data properly), your contract may continue in a “success-looking” state while the external call actually failed. This is a classic Solidity audit finding tied to unsafe external interactions.

A happy-path-only focus is a strong signal of poor threat modeling in blockchain security because it ignores attacker behavior, edge cases, and abuse scenarios. Strong smart contract audit readiness requires adversarial thinking, not just normal-flow testing.

Front-running is often downgraded incorrectly in smart contract audits because teams underestimate MEV and mempool-based exploitability. In DeFi security, transaction ordering attacks can cause repeated economic loss even without a classic code exploit.

Access control bugs often have the highest real-world exploit probability in smart contracts because attackers can directly call privileged functions when role checks fail. In blockchain security audits, broken authorization logic is a common cause of fund loss and protocol takeover.

An uninitialized storage pointer defaults to storage slot zero. This can overwrite critical state variables such as ownership or balances, making it a high-severity audit issue.