Most smart contract exploits aren’t zero-days. They’re known vulnerability classes hitting code that skipped a serious review, or passed an audit too narrow to catch what mattered.
DeFi losses exceeded $3.1 billion in the first half of 2025, with smart contract failures alone contributing $263 million in damages. The rest came from access control failures, oracle misconfiguration, and protocol logic bugs that no automated scanner would have flagged. (For a closer look at how these played out in practice, see our breakdown of the April 2025 crypto hacks surge.)
Understanding how these attacks work is the first step to building contracts that don’t end up in a post-mortem thread.
Source: Hacken H1 2025 Web3 Security Report
Security Starts Before the First Line of Code: Getting Requirements Right
A vulnerability doesn’t have to be a bug. If the specification a contract is built on is flawed, the code will faithfully implement something that was wrong from the start, and no audit will catch it, because the code is doing exactly what it was told to do. Ambiguous tokenomics, edge cases in liquidation logic that were never thought through, governance mechanisms that weren’t stress-tested: these are design bugs, and they’re far more expensive to fix after deployment than before.
Before writing Solidity, the team should be able to answer a simple question: what are the invariants this system must never violate? If that doesn’t have a clear answer, the spec isn’t ready.
The Most Common Smart Contract Vulnerabilities
Not every exploit is equally likely, and not every project faces the same risk profile. According to the OWASP Smart Contract Top 10 for 2026, built directly from 2025 incident data, access control issues lead the pack, business logic bugs are right behind, and reentrancy persists in new forms alongside oracle manipulation, flash loans, and upgrade risks.
These aren’t abstract categories. Each one maps to a specific pattern that auditors look for and that developers can address before deployment.
The full ranking, ordered by 2025 impact:
| Rank | Vulnerability class |
|---|---|
| SC01 | Access Control |
| SC02 | Business Logic |
| SC03 | Price Oracle Manipulation |
| SC04 | Flash Loan Attacks |
| SC05 | Lack of Input Validation |
| SC06 | Unchecked External Calls |
| SC07 | Arithmetic Errors (rounding & precision) |
| SC08 | Reentrancy |
| SC09 | Integer Overflow & Underflow |
| SC10 | Proxy & Upgradeability |
Source: OWASP Smart Contract Top 10 (2026)
The trend over time makes the two dominant classes clear: access control and smart contract bugs trade the lead quarter to quarter, but together they account for the bulk of on-chain losses.
Source: Hacken H1 2025 Web3 Security Report
Reentrancy
A reentrancy attack occurs when a contract makes an external call to another contract before updating its own state. The called contract can then call back into the original contract, causing unexpected behavior. The Checks-Effects-Interactions (CEI) pattern exists specifically to prevent this: validate inputs, update state, then make the external call. In that order, every time.
OpenZeppelin’s ReentrancyGuard is the standard implementation. What teams miss is that read-only reentrancy in view functions called during state changes can still be exploitable, especially in lending protocols.
Flash Loan Attacks
Flash loans allow anyone to borrow large amounts of capital within a single transaction, with no collateral, as long as repayment happens in the same block. Attackers use this to execute oracle manipulation, AMM liquidity pool draining, and arbitrage exploits across platforms. The flash loan itself isn’t the vulnerability. It’s the amplifier that turns a small pricing flaw into a protocol-draining event.
Beanstalk, for example, was exploited because its governance contract had no protection against flash loans. The attacker borrowed enough to gain a 78% supermajority in a single transaction and passed a proposal that drained protocol funds.
Oracle Manipulation
Price oracles are the bridge between on-chain contracts and off-chain data. When a contract uses a single, manipulable source, such as a spot price from an AMM, it becomes vulnerable to anyone who can temporarily move that price. Over 31% of early 2025 DeFi losses came from oracle-based attacks, with flash loan oracle exploits totaling over $403 million historically.
The fix is well-understood: use time-weighted average prices (TWAPs), pull from multiple oracle sources, and validate that feeds are recent. Chainlink’s AggregatorV3Interface provides staleness checks that most vulnerable contracts simply skip. (We go deeper on oracle trust models in Decentralized Oracles.)
Access Control Failures
This is the category that causes the most aggregate damage, and it’s often the least glamorous. Exposed admin functions, weak role separation, missing onlyOwner modifiers on sensitive operations, and governance contracts with insufficient delay mechanisms. Access control flaws led to financial losses totaling $953.2 million and remain the leading cause of smart contract breaches.
OpenZeppelin’s AccessControl module handles role-based permissions cleanly, yet less than 50% of developers implement it fully.
Business Logic Errors
These are the hardest to catch with automated tools because they require understanding what the contract is supposed to do, not just what it does. Incorrect fee calculations, broken invariants in AMM pricing curves, and flawed liquidation thresholds fall here. No static analyzer catches a fee that’s calculated correctly in isolation but breaks under specific token decimal configurations. (This class of bug is central to how value actually moves in DeFi, see The Role of Smart Contracts in DeFi.)
Source: Hacken H1 2025 Web3 Security Report
Operational Security: The Attack Surface Beyond the Code
Code security is only as strong as everything around it. The wallet used to deploy a contract is an attack vector. A seed phrase typed into a browser extension on a compromised machine, or a private key stored unencrypted on a developer’s laptop, can hand an attacker full control without touching a single line of Solidity. A .env file committed to a public repo has caused multi-million dollar losses in protocols that otherwise had clean audits.
Hardware wallets for deployment keys, multisig for admin functions, proper secrets management in CI/CD pipelines, and basic hygiene around personal devices, these aren’t optional extras. They’re part of the security surface, and skipping them makes everything else irrelevant.
A Note on OpenZeppelin Defender
OpenZeppelin’s Defender platform was a good attempt at addressing exactly these operational gaps: it brought together on-chain monitoring, managed relayers (so private keys never had to sit in application infrastructure), access control management, and deployment pipelines under one roof. Most teams were either skipping these entirely or building them ad hoc. Defender made it easier to do them properly. It’s now being phased out, new sign-ups closed June 2025 and the platform shuts down fully in July 2026, with OpenZeppelin migrating the core tools to open source.
The platform is going away, but the problems it solved aren’t. Monitoring for suspicious on-chain activity, managing who holds what admin keys, and keeping deployment workflows auditable are still unsolved for most teams. They don’t require a specific platform to address, but they do require intentional decisions, not afterthoughts.
The Developer’s Responsibility: Pushing Back on Bad Design
There’s a failure mode that doesn’t appear in audit reports: the developer who sees a problem and implements it anyway. A fee mechanism that breaks under specific conditions, a governance model that can be gamed, a token design that creates perverse incentives, these are things a good developer spots before writing a line of code. At SpaceDev, the expectation is that developers don’t just implement what clients ask for. They give a proper technical recommendation, including when that means saying something won’t work.
In smart contract development, the cost of a wrong design decision isn’t a refactor, it’s potentially an irreversible loss. That changes the calculus. Flagging a problem early, explaining why it matters, and proposing an alternative is part of the job, not a deviation from it.
Manual Audit vs. Automated Tools: What Each Actually Catches
Automated scanners, Slither, MythX, Echidna, are fast and consistent. They reliably catch known patterns: reentrancy, integer overflow, unchecked return values. They miss business logic errors, complex multi-contract interactions, and anything that requires understanding the protocol’s economic model.
| Approach | Catches | Misses | Typical cost |
|---|---|---|---|
| Automated (Slither, MythX) | Known vuln patterns, gas inefficiencies | Logic errors, economic exploits | Low / open-source |
| Manual review | Logic errors, design flaws, complex interactions | Can miss edge cases in large codebases | $25K-$150K |
| Formal verification | Mathematically provable properties | Doesn’t validate the spec itself | High, specialized |
| Fuzzing (Echidna, Foundry) | Edge cases, unexpected input behavior | Requires invariant definitions upfront | Medium |
Comprehensive smart contract audits in 2025 typically range between $25,000 and $150,000, depending on complexity. The variance reflects scope more than firm prestige: a 500-line ERC-20 and a cross-chain lending protocol with governance aren’t the same engagement.
A serious audit combines all four approaches. Automated tools run first to clear the obvious issues. Manual review then focuses on what scanners can’t evaluate: the intended behavior, the economic assumptions, and the interaction surface with external protocols.
How to Read an Audit Report
An audit report isn’t a pass/fail certification. It’s a snapshot of what a team found under a specific scope, within a specific timeframe. Knowing how to interpret findings changes how useful the document actually is.
Findings are typically classified by severity:
- Critical: Exploitable now, directly causes loss of funds or protocol takeover. Requires immediate remediation before deployment.
- High: Significant risk under realistic conditions. Should be resolved before launch.
- Medium: Real vulnerability but harder to trigger or limited in impact. Should be addressed before launch, not after.
- Low / Informational: Best practice gaps, gas inefficiencies, documentation issues. Don’t block deployment but should be tracked.
Two things teams consistently misread: the scope section and the “resolved” status. An audit scoped to three contracts doesn’t cover the four contracts that interact with them. And “resolved” means the auditor acknowledged the team’s response, not necessarily that the fix is correct.
There’s a deeper limitation worth naming: an audit validates what the code does, not whether the protocol was correctly designed. A well-audited implementation of a broken economic model or a flawed governance mechanism will pass a security review clean. Before the audit, the team should be able to define the invariants the system must never violate, what conditions must always hold, regardless of user behavior. If those aren’t clearly stated going into the engagement, the audit scope is incomplete before the first line is reviewed.
Audit Scope by Contract Type
Different contract types carry different risk surfaces. The audit process should be calibrated to what the contract actually does:
| Contract type | Primary risk areas | Recommended audit focus |
|---|---|---|
| ERC-20 / token | Minting permissions, approval logic, transfer hooks | Access control, overflow, fee-on-transfer edge cases |
| AMM / DEX | Price manipulation, liquidity math, flash loan surface | Oracle design, invariant testing, economic modeling |
| Lending protocol | Oracle dependencies, liquidation logic, collateral math | TWAP validation, liquidation thresholds, reentrancy |
| Cross-chain bridge | Signature verification, relayer trust model, key management | Message validation, replay protection, key storage |
| Governance | Flash loan voting, timelock configuration, proposal logic | Anti-flash-loan mechanisms, execution delay adequacy |
Token and ERC-20 contracts are also where asset-backed and real-world-asset projects begin, if you’re issuing a token to represent an underlying asset, the minting and transfer logic is the security boundary. (We cover that design space in our asset tokenization service and in Real World Assets (RWAs) Explained.)
Bridge contracts are particularly fragile because they combine off-chain relayers, multi-sig wallets, and light-client verification, and a flaw in any one layer compromises the whole system. Scope that excludes the relayer or the off-chain signing infrastructure misses the attack surface that caused several major bridge exploits.
Post-Audit Security: What Keeps a Protocol Safe After Launch
An audit at deployment is necessary but not sufficient. Protocols that survive long-term treat security as an ongoing operational function, not a one-time checkbox.
Monitoring
On-chain monitoring tools like OpenZeppelin Defender, Tenderly, or Forta track unusual activity, large balance changes, and admin function calls in real time. The goal is detection before losses compound. SpaceDev’s BlockAudit service includes monitoring setup as part of its post-audit engagement, using OpenZeppelin Defender to set security triggers tied to specific on-chain events.
Bug bounties
A well-scoped bug bounty program extends the audit surface to a global pool of security researchers. Immunefi is the standard platform for Web3 bounties. Payout tiers should reflect the actual severity classification used in the audit, with critical-level payouts meaningful enough to attract serious researchers.
Upgrade hygiene
Upgradeable contracts introduce a persistent risk surface. Every upgrade is a new deployment that needs its own review, and proxy admin keys are a frequent target. Timelocks on upgrade functions, multisig admin control, and a clear governance process for upgrades matter as much as the initial audit.
Operational security around keys deserves the same attention as the contracts themselves. The wallet used to deploy or upgrade a contract is part of the attack surface. A compromised deployer key, whether from an unencrypted file on a developer’s machine, a leaked .env committed to a repo, or a seed phrase entered on a compromised device, can bypass everything the audit verified. Hardware wallets for deployment keys, multisig for admin functions, and basic hygiene around developer environments aren’t extras; they’re part of the security posture.
DeFi exploit losses declined 74% from their 2022 peak by 2025, driven by improved auditing practices, faster bug bounty programs, and more robust smart contract standards. The protocols that contributed to that improvement didn’t just get better audits. They built security infrastructure that survives the period between audits.
Getting a Smart Contract Audit: Practical Starting Points
Before engaging an auditor, these questions determine how useful the engagement will be:
- Is the codebase frozen or still in active development? Auditing a moving target wastes both time and budget.
- What is the deployment timeline? Audits on critical contracts typically take two to four weeks for manual review. Rushing compresses the time available for edge case analysis.
- What chains and frameworks are in scope? Solidity on EVM and Rust on Solana require different tooling and reviewer expertise.
- Are there external protocol dependencies? Integrations with Uniswap, Aave, Chainlink, or other protocols extend the attack surface and should be in scope.
One question that doesn’t appear on most checklists: has the development team internally reviewed and challenged the design? An auditor reviews code; they don’t redesign protocols. If there are known tensions in the business logic, unclear edge cases in the economic model, or design decisions the team had doubts about but implemented anyway, those should surface before the engagement starts, not be discovered by the auditor. At SpaceDev, we treat this as part of pre-audit preparation: developers are expected to flag what they’re uncertain about, not just deliver working code. The auditor’s time is expensive; using it to discover problems the team already suspected is a poor use of scope. (Our pre-audit checklist is the fastest way to get a codebase ready.)
SpaceDev’s BlockAudit covers smart contract security across Ethereum/EVM, Solana, Solidity, and Rust, combining static analysis, manual review, and SECOPS assessment for the full security picture. If you’re approaching a deployment or want an independent review of existing contracts, book a call to scope the engagement.
For teams earlier in development, SpaceDev’s smart contract development service builds security considerations into the architecture before a line of auditable code is written.
