SMART CONTRACTS, DUMB MISTAKES

Nine-figure exploit headlines make the attacks sound exotic, like the work of nation-state wizards breaking unbreakable math. Then you read the post-mortems and find the same short list of ordinary mistakes, year after year, chain after chain, protocol after protocol. The code is public, the money is sitting inside, and the bugs are reruns of bugs we have known about for a decade.

A smart contract is just a program that holds money and cannot be quietly patched on a Friday night. That combination, real funds plus immutable code plus full public visibility, is why boring bugs become historic losses. An attacker does not need to guess where the treasure is. It is on the map, in the open, and they can study the lock for as long as they like before touching it.

I spent the 2023 era watching this happen in real time across Solana projects. Here is the pattern, from someone who was in the trenches rather than reading about them afterward.

The five bugs that never die

If you understand these five failure modes, you understand the mechanics behind a startling percentage of the money ever stolen from decentralized protocols. They are not clever. That is precisely why they keep working.

• →Reentrancy. A contract sends out funds before updating its own internal record of balances. The attacker calls back into the contract mid-payment, before the books are corrected, and withdraws again in a loop. This is the 2016 DAO hack in a new costume, and it still drains protocols today because developers keep writing the same ordering mistake.
• →Unchecked mints and missing signer checks. A function that creates new tokens or moves funds without properly verifying who is allowed to call it. On Solana specifically, this often shows up as a missed account-owner validation, where the program trusts an account it should have checked. One missing verification, and anyone can mint or move at will.
• →Admin keys in plain sight. A single wallet holds the power to upgrade the contract, pause it, or drain it entirely. This is not a hidden backdoor. It is a clearly labeled front door, disclosed in the code, that everyone chose to ignore because the team seemed trustworthy.
• →Oracle manipulation. The contract trusts a single thin price feed to know what assets are worth. The attacker moves that market for one block, borrows against the temporarily false price, and walks away before the price corrects. The contract did exactly what it was told, which was the problem.
• →Arithmetic edges. Overflow, precision loss, and rounding errors that seem trivial until they run at scale. A fraction of a cent rounded the wrong way, multiplied across millions of transactions, becomes a fortune quietly leaking out the side.

Why audits keep missing them

The obvious question is: if these bugs are so well known, why do audited protocols keep falling to them? The answer is that an audit is a snapshot of one specific version of the code, reviewed under a deadline, by humans who cannot catch everything. It is a useful reduction of risk, not a guarantee of safety, and it gets treated as the latter far too often.

Worse, protocols routinely redeploy code after the audit finished, integrate unaudited dependencies, and treat the audit report as a marketing asset to wave at investors rather than a document anyone actually reads. A badge on a website that says "audited" tells you almost nothing. The report itself, the specific commit it covered, and evidence that the findings were fixed, tell you everything.

An audit badge on a website is a claim. The report, the commit hash it covered, and the fixes that actually shipped are the evidence. Learn to ask for the evidence.

Reading a contract before you trust it

You do not need to be a professional auditor to protect yourself. You need a ten-minute checklist and the discipline to actually run it before you commit money, rather than after you have lost it. Most catastrophic decisions in this space are made by people who felt trust before they verified it.

• →Is the contract source verified and readable, or is it an unverified blob you are asked to trust blindly?
• →Who holds upgrade authority, and can they change the rules after you deposit? Is that power behind a timelock that gives you warning, or can they act instantly?
• →Is the liquidity genuinely locked, and locked by a mechanism you can independently verify, rather than the team own contract?
• →Does the team publish which audit findings were actually fixed, with commits you can inspect?
• →Where does the price feed come from, and how hard would it be for someone to move it?

Five questions. They will filter out an embarrassing percentage of the incidents that are coming, because most exploited protocols fail at least one of them visibly, in advance, for anyone willing to look.

The human layer, again

Here is the part that connects Web3 security back to everything else. The technical bugs are real, but the reason they keep draining protocols is human. Communities got engineered where asking "who holds the mint keys?" made you the villain, the fudder, the person spreading fear. Verification was socially punished. In that environment, the technical red flags did not matter, because no one was allowed to point at them.

The strongest defense in this space is not a tool. It is a culture where verification is normal and questions are welcome. The same lesson as the rest of security: the weakest layer is usually the person, and the fix is usually a room where people can speak up.

Looking ahead

Formal verification and safer development frameworks are slowly deleting entire classes of these bugs, the way memory-safe languages gradually killed off buffer overflows in traditional software. That progress is real and worth celebrating. But incentives move faster than tooling, and enormous piles of money will always attract shortcuts, unaudited forks, and confident teams who skipped the boring checks.

The bugs cannot hide forever, because they live on a public ledger where anyone can read them. That is the strange gift of this technology. The receipts are right there. Before your next deposit, ask the only question that really matters. If this contract failed tomorrow, would the post-mortem surprise anyone who actually looked, or would it read like every other one, listing red flags that were visible all along?