Abstract
The DeFi ecosystem lost over $3.8 billion to smart contract exploits between 2020 and 2023. The majority of those losses were not the result of novel cryptographic attacks or unknown protocol-level vulnerabilities - they were the result of well-understood vulnerability classes being missed in development, inadequately addressed in audit, or left unmonitored after deployment. This paper presents a practitioner-oriented security framework designed to close those gaps.
The framework is structured around four phases: pre-development threat modelling, development-time security patterns, pre-deployment audit methodology, and post-launch monitoring. Each phase is documented with sufficient technical detail to be actionable by an engineering team - not just a checklist for auditors. The vulnerability coverage focuses on the nine categories responsible for 94% of measured exploit losses in the period studied: reentrancy, access control, oracle manipulation, integer overflow and underflow, front-running, flash loan attack surfaces, logic errors in economic design, upgrade proxy misconfigurations, and timestamp dependence.
Six real protocol incidents are analysed in depth, with on-chain transaction traces and reconstructed attack paths. The monitoring chapter documents a detection architecture that provided 4–12 hours of early warning before five of the six incidents studied, had the relevant monitoring infrastructure been in place at the time.
"Most protocol teams that suffered exploits in 2021–2023 had completed at least one audit. The audit wasn't the problem. The lack of a coherent security process around the audit - before, during, and after - was."
Why smart contract security keeps failing
A misunderstanding sits at the centre of how most DeFi teams approach security: the belief that an external audit is a security programme. It isn't. It's a point-in-time review by a third party who is working from a snapshot of the codebase, under time pressure, without the full context of the protocol's economic design intent. Audits catch things that development-time practices missed. They don't replace those practices.
The three most common failure modes we see in protocols that subsequently suffer exploits are:
- No internal security review before external audit - the first time anyone looks critically at the access control model is when the external auditor does.
- Economic design reviewed by engineers for correctness, not by anyone modelling adversarial incentive structures. Flash loan attack surfaces arise from economically rational behaviour that engineers didn't anticipate because they weren't thinking adversarially.
- Zero post-deployment monitoring. Most teams treat launch as the end of the security process. In practice, it's the beginning of the highest-risk period - when real money is live and every MEV bot and white-hat researcher is actively looking for gaps.
The nine vulnerability classes that account for most losses
The nine vulnerability categories below account for 94% of measured DeFi exploit losses in the 2020–2023 period. The paper covers all nine in detail; this section summarises the three that appear most frequently in post-mortems and that are most reliably preventable at development time.
1. Reentrancy
Reentrancy is the oldest significant smart contract vulnerability class, first demonstrated in the 2016 DAO exploit. It remains one of the most common causes of loss in production protocols, not because developers are unaware of it, but because its variants - cross-function reentrancy, cross-contract reentrancy, and read-only reentrancy - are less well understood than the classic single-function case. The paper documents all four variants with annotated Solidity examples and a decision tree for identifying exposure during code review.
// ❌ VULNERABLE - state update after external call function withdraw(uint256 amount) external { require(balances[msg.sender] >= amount, "Insufficient balance"); // External call before state update - reentrancy window open (bool success, ) = msg.sender.call{value: amount}(""); require(success, "Transfer failed"); balances[msg.sender] -= amount; // Too late - can be drained first } // ✅ SAFE - checks-effects-interactions pattern function withdraw(uint256 amount) external { require(balances[msg.sender] >= amount, "Insufficient balance"); balances[msg.sender] -= amount; // State updated before call (bool success, ) = msg.sender.call{value: amount}(""); require(success, "Transfer failed"); }
2. Oracle manipulation
Price oracle manipulation has been the root cause of more total value lost than any other single vulnerability class. The common thread across Harvest Finance, Cream Finance, Mango Markets, and a dozen smaller incidents is the same: a protocol using a single on-chain price source - typically a DEX spot price - for a function that controls significant value flows. When that price source can be moved within a single transaction using a flash loan, the attack cost approaches zero while the potential gain is bounded only by the protocol's TVL.
The framework presents a five-point oracle assessment checklist that catches the majority of manipulation-surface exposures at review time. It also covers time-weighted average price (TWAP) implementation tradeoffs - including the conditions under which a TWAP oracle provides inadequate protection for high-value operations.
3. Access control errors
Access control vulnerabilities are conceptually straightforward but surprisingly persistent. The most common pattern is a privileged function - typically an administrative setter or upgrade mechanism - that is either missing an ownership check entirely, or that checks a condition the developer believed to be equivalent to ownership but isn't. The second pattern is a function marked internal when it should be private, or public when it should be external onlyOwner. The paper provides a systematic method for constructing an access control matrix during code review that makes these gaps immediately visible.
The four-phase audit framework
The core of the paper is a four-phase security framework that treats the audit not as a standalone event but as one phase in a continuous process. The framework is designed to be lightweight enough that a team of three to six engineers can implement it without dedicated security headcount, while being rigorous enough to catch the categories of issues that external audits most commonly miss.
Phase 1 - Threat modelling before a line of code is written
The first phase happens before development starts. Its output is a threat model: a structured document that lists every privileged operation the protocol will perform, every external dependency it will call (oracles, bridges, other protocols), and every economic action an adversary could take to profit at the expense of legitimate users. This document becomes the lens through which all subsequent security decisions are made. It takes two to four hours for a focused team to produce a usable threat model for a mid-complexity protocol.
Phase 2 - Development-time security patterns
The second phase is a set of coding practices applied during development. The paper covers the checks-effects-interactions pattern, OpenZeppelin's ReentrancyGuard, the use of Slither and Mythril for static analysis in CI, and fuzz testing with Foundry's fuzzing harness. It also covers what automated tools reliably catch and what they reliably miss - which is equally important context for a team deciding how much to rely on them.
Phase 3 - Pre-deployment audit coordination
The third phase covers how to prepare for and get the most from an external audit. This includes writing an audit brief, producing a function-level documentation standard, and running a full internal code review against the threat model before the external auditor sees the code. Protocols that deliver well-documented, pre-reviewed code to external auditors get significantly more useful reports - the auditor's time is spent on genuine design-level issues rather than documentation questions.
Phase 4 - Post-launch monitoring architecture
The fourth phase is the one most commonly skipped. The paper documents a monitoring stack using Tenderly alerts, Forta bots, and a custom on-chain anomaly detection layer. The detection architecture identifies seven early-warning signals - including unusual flash loan activity involving the protocol's liquidity pools, large position builds in single transactions, and governance proposal submissions outside normal cadence - that collectively provided advance warning before five of the six incident case studies.
Pre-deployment security checklist
The following checklist condenses the Phase 2 and Phase 3 requirements into a format suitable for use as a merge-request gate before any code reaches a deployment-candidate branch.
Post-launch monitoring - what to watch and why
The monitoring chapter is the part of this paper that took the most time to write, because most of the relevant knowledge is held by MEV researchers and white-hat security teams who haven't published it in a form accessible to protocol engineers. We spent two months reviewing on-chain data from the six incident case studies to build the detection model presented here.
The fundamental insight is this: most on-chain exploits don't happen instantly from a standing start. They involve a period of probing - test transactions that check edge cases, small-scale attempts before the full-scale attack, or a series of economic actions that progressively build an advantageous position. That probing creates a signal. If you're watching for it, you have time to respond.
The monitoring setup documented in the paper requires roughly three days to implement for a team that hasn't done it before. It uses Tenderly for transaction simulation alerts, Forta for protocol-specific bot deployment, and a lightweight Python anomaly detector that queries The Graph and compares pool state metrics against 30-day rolling baselines. The combination produced the 4–12 hour early warning window observed in the case study re-analysis.
Conclusion and how to use this paper
This paper is not a substitute for a professional security audit. If your protocol holds or will hold significant user funds, you should engage an external auditor - ideally two, from different firms, at different points in the development cycle. What this paper provides is everything that should happen around that audit to make it as effective as possible and to continue providing protection after the audit is complete.
The framework is designed to scale. A solo developer building a small yield strategy contract can implement Phase 2 and a basic version of Phase 4 in a few days. A team of ten building a multi-chain lending protocol should implement all four phases as formal processes with assigned owners. The checklist in Section 5 is the fastest path to implementation - start there, then work backwards into the earlier phases as capacity allows.
All code examples in this paper are available in the accompanying GitHub repository under MIT licence. Issues and pull requests are welcome. The framework will be updated as the threat landscape evolves.