Why Non-Developers Need to Understand This
If you're a founder, investor, product manager, or executive working anywhere near a blockchain project, you need a working understanding of smart contract security. Not because you're going to read the code. Because you're going to make decisions that affect whether the code is secure.
When to launch. Whether to spend on a third audit. Whether to increase the TVL cap. Whether the team's claim that a finding is "low severity" is accurate. These are judgment calls that require context. This is that context.
What Smart Contracts Actually Are
A smart contract is a program deployed to a blockchain. Once deployed, it runs autonomously — executing its logic whenever the defined conditions are met, without requiring a human to approve each transaction. The code is the rule.
This is powerful. It's also where the risk lives. If the code has a flaw, the flaw executes automatically too. There's no bank to call, no dispute resolution process, and in most cases no way to undo the transaction once it's been processed.
The history of smart contract exploits is largely a history of developers writing code that does exactly what it says, but not what they intended.
The Reentrancy Attack
This is the original exploit — made famous by the DAO hack in 2016, which resulted in $60M stolen and ultimately a hard fork of Ethereum.
The concept: a smart contract sends ETH to an external address. Before the contract has finished updating its own internal records, that external address calls back into the same contract and triggers another withdrawal. The contract hasn't recorded the first withdrawal yet, so it allows the second. This repeats until the contract is drained.
Why it still happens: modern languages and frameworks have built-in protections, but developers still introduce reentrancy vulnerabilities through complex function call patterns. In 2022, reentrancy was still responsible for hundreds of millions in losses.
What to look for: does the audit specifically test for reentrancy? Is the "checks-effects-interactions" pattern followed? Are there reentrancy guards on critical functions?
Integer Overflow and Underflow
Smart contracts, like all programs, store numbers in fixed-size containers. If a number exceeds the maximum size, it wraps around — a number just above the maximum becomes zero or a very small number. If it goes below zero, it wraps to the maximum.
In practice: a contract tracking user balances could be manipulated so that a balance that should be zero becomes astronomically large. Or a contract calculating fees could be manipulated so that a subtraction operation wraps and produces a result that makes no financial sense.
Modern Solidity versions (0.8.0+) include built-in overflow protection, but older contracts and contracts using assembly code can still be vulnerable.
What to look for: what Solidity version is the contract using? Does the audit specifically cover arithmetic operations? Are there bounds checks on user-controllable inputs to arithmetic functions?
Access Control Failures
The most avoidable class of vulnerabilities. Some functions in a smart contract should only be callable by authorized addresses — admin functions, emergency pause functions, upgrade mechanisms. If these access controls are missing or misconfigured, anyone can call them.
The Poly Network exploit in 2021 ($611M) involved an access control failure that allowed an attacker to call a privileged function and modify the authorized address list. Once they controlled the authorization, they could move funds freely.
What to look for: what functions are restricted to admin/owner? Are role-based access controls documented and audited? What happens if the owner key is compromised?
Oracle Manipulation
Not exactly a code vulnerability, but a system design vulnerability. Many contracts rely on external price feeds to make decisions — whether to liquidate a position, how many tokens to issue, what a collateral ratio is. If those price feeds can be manipulated, the contract's logic can be exploited even if the code is technically correct.
Flash loan attacks are the typical delivery mechanism. An attacker borrows a massive amount of capital for a single transaction, uses it to distort a price on a DEX that's being used as a price oracle, exploits the contract that's relying on that distorted price, then repays the flash loan — all in one transaction. No upfront capital required.
What to look for: what oracles does the contract use? Decentralized oracle networks (Chainlink, Pyth) are significantly harder to manipulate than on-chain price calculations. Does the contract use time-weighted average prices (TWAPs) rather than spot prices?
Logic Errors
The hardest category to evaluate and the one that requires the most sophisticated auditing. Logic errors are cases where the code does exactly what it says — the logic is just wrong for the intended behavior.
Compound's 2021 issue, where a misconfigured oracle resulted in $90M in erroneous token distributions, was essentially a logic error in how the distribution function interacted with price data. The code ran correctly. The logic was wrong.
What to look for: do the auditors include formal verification or economic analysis alongside code review? Have the core invariants of the protocol — the properties that must always be true — been explicitly defined and tested?
The Audit Process: What It Is and What It Isn't
A smart contract audit is a structured review of code by security-specialized engineers looking for known vulnerability patterns and logic flaws. A good audit includes automated scanning tools, manual review, and targeted testing.
Audits reduce risk. They don't eliminate it. The Euler Finance hack ($197M, 2023) happened on a contract that had been audited multiple times. The vulnerability wasn't discovered because it required understanding the interaction between specific functions in a non-obvious way.
For any protocol managing meaningful capital, the minimum bar is: two independent audits from firms with demonstrable DeFi experience, a responsible disclosure process, a bug bounty program with meaningful rewards, and a remediation report showing how audit findings were addressed.
The protocol that passes all of that and still gets exploited is the exceptional case. The protocol that skips any of it is playing a different game.
What This Means for Your Decision-Making
If you're a non-technical decision-maker working on or investing in a blockchain project, you don't need to read the code. You do need to ask:
- Who audited this, and what were the findings?
- Which findings weren't fixed, and why?
- Is there a bug bounty program? What's the maximum payout?
- What's the upgrade mechanism? Who controls it?
- What external data does this contract depend on?
The answers to these questions tell you more about the security posture of a project than the code itself will. Ask them before you launch, before you invest, and before you increase exposure to any protocol in your portfolio.