Smart Contract Gotchas: What I Wish I Knew Before Auditing Solidity Code

Smart contracts look simple. A few lines of Solidity, some fancy modifiers, a deploy button and you’re live. Except you’re not.

Because what seems like a tiny bug in your code could become a $1M exploit. And once it’s on-chain, you can’t just patch it on Friday and ship a hotfix.

So, if you’re about to audit your first smart contract or you think your test suite has your back - here’s what I wish someone told me earlier.

🔹 Don’t Trust the Modifiers
Solidity modifiers look like a good way to manage access or logic reuse. But they’re just syntactic sugar and they can obscure actual control flow.

Common mistake: Using multiple modifiers (onlyOwner, nonReentrant, etc.) and assuming they execute in a predictable order.

Tip: Flatten your control logic when auditing. Don’t just look at the function signature, follow the full execution chain.

🔹 Overflows Are Mostly Gone - But Underflows Still Bite
With Solidity 0.8+, you get built-in overflow checks. But guess what? Many projects still use older versions or use unchecked blocks for gas optimization.

Case: A staking contract calculated user rewards using an unchecked subtraction, when rewards weren’t claimed in time, it caused an underflow that bricked the contract.

Tip: Never assume a project uses a recent compiler version. Always verify.

🔹 Reentrancy Isn’t Just About call
Everyone knows about The DAO hack. But the modern version of reentrancy is sneakier. For instance, external calls buried inside transferFrom() or safeTransferFrom() (especially in ERC-721 contracts) can be exploited.

Tip: Flag any external call inside state-changing functions — even if it's inside a library. Use tools like Slither, but double-check manually.

🔹 Events Are Not Optional
Events are your audit trail. No logs? No trust. We’ve seen projects with complex on-chain logic but no event emissions for critical operations like withdrawals or ownership transfers.

Tip: You’re not just coding for the EVM, you’re coding for the human trying to debug this in 6 months.

🔹 Watch for Gas Griefing
Gas griefing isn’t an exploit, but it is a pain point. Functions that can be made unusable by large arrays or loops (especially with on-chain data like mappings) make your contract vulnerable to denial of service via gas exhaustion.

Tip: Check every loop for unbounded iteration. Especially if user input determines the size.

🔹 Just Because It’s ERC-20 Doesn’t Mean It’s Safe
Too many audits assume tokens like USDT, USDC, or random altcoins behave according to ERC-20 spec. Spoiler: they don’t.

USDT, for instance, doesn’t return true/false on transfer() - it just silently works or fails. If your contract relies on return values, this inconsistency can break logic.

Tip: Always test with real mainnet forks and a mix of weird tokens.

🔹 Front-Running Is Still a Thing
MEV isn’t going away. Contracts that expose timing-sensitive operations — especially ones that rely on “first come, first serve” logic - are sitting ducks.

Tip: Time-locks, commit-reveal schemes, or minimal state changes per tx can help reduce surface area.

Final Thought
Auditing smart contracts isn’t about checking code line-by-line - it’s about thinking like an attacker. Assume every assumption is wrong, every input is malicious, and every user is trying to drain your funds.

🚀 Need help with a smart contract audit or want a Solidity dev who’s seen this before?

Info-Polus provides vetted Web3 developers who’ve built, audited, and secured contracts in the wild. Whether you’re launching a token, DeFi protocol, or NFT marketplace - we can help!

Visit our website here!