Smart contract security depends on threat modeling, invariant testing, access control, and post-deploy monitoring, not on a single audit before launch.
Smart contract security refers to the set of engineering, economic, and operational measures to ensure that a protocol behaves as intended before and after deployment. Rather than relying on a single audit, securing a protocol requires a series of decisions regarding threat modeling, architecture, testing, access control, and live operations.
Smart contract security covers far more than just the code. Besides code correctness, it includes economic assumptions, access control, dependencies, as well as the operational controls for the contract after deployment. An audit covers only a part of that surface.
Code correctness refers to all the possible errors that can be present in smart contract code. The most common ones are reentrancy, arithmetic errors, external calls that are not safe, errors in smart contracts that are upgradeable that occur due to incorrect state changes, errors in signature validation, and storage collisions. Baseline references like Solidity security considerations and Ethereum smart contract security documentation help frame these classes of failure.
Economic correctness refers to the exploitation of smart contracts through the exploitation of the underlying economic assumptions. This can include price formation, liquidity, incentives, and timing. Profit in a legal but harmful sequence of actions refers to a security problem in the protocol even when the bytecode is executed as designed.
Dependency risk also plays a big role in smart contract security. A dependency may behave unexpectedly and affect the state of your smart contracts. So, treat every single dependency as a source of state and of assumptions instead of just neutral building blocks.
A threat model for onchain systems outlines potential losses, actors, controls, and external trust points for a given protocol. A loose model typically translates to a loose implementation.
By outlining the major attack surface before writing code, your team can have architectural discussions about your attack surface before the interfaces are “set in stone” and your (possibly incorrect) assumptions about how something works become too expensive to change.
A useful threat model usually covers the following:
Doing this exercise after the code has been written typically results in weaker outcomes. The team has anchored to the design as it has been developed and therefore the exercise becomes “how do we justify what we've already built?” as opposed to “what should this system trust?” Local patches as opposed to fundamental fixes result from this approach.
In DeFi protocol development, those choices set the shape of the attack surface long before a test suite exists.
Upgradeability is the clearest case. Immutable contracts are more secure because there is no risk of a team losing control of governance or upgrade keys after deployment. However, in return, the team will not be able to fix any logic errors in the code after deployment. An upgradeable contract, on the other hand, gives a team a recovery path from any errors they may have made but, in the process, introduces a host of complexities including that of the proxy, storage layout, upgrade authorization, and social trust.
External calls have similar trade-offs. Rich composability leads to a better product surface, but every external interaction adds more states the protocol has to deal with. This includes call ordering, error handling, reentrancy, and the behavior of tokens in particular. So a system that treats every ERC-20 token the same way is already making a few security decisions.
Economic security is the biggest killer of seemingly secure code. Correctness can depend on a price that can be moved within a single block, or on liquidity that can be borrowed for a single transaction and returned immediately. In the end, economic security depends on the structure of the market for a particular asset, and therefore is largely outside the control of Solidity code.
The tradeoffs are easier to compare side by side:
| Design choice | What it can improve | What it can introduce |
|---|---|---|
| Immutability | Removes upgrade key risk, simpler trust story | No direct patch path, migration may be harder |
| Upgradeability | Enables fixes and staged feature rollout | Proxy complexity, storage risk, admin path exposure |
| External integrations | Better composability and capital efficiency | Reentrancy exposure, dependency failures, unexpected token behavior |
| Tight oracle dependence | Clear pricing input, simpler logic | Oracle manipulation or stale data sensitivity |
| Liquidity sensitive mechanics | Efficient pricing or liquidation flow | Vulnerability to short term liquidity moves and MEV pressure |
While unit tests for functional checks on a smart contract are very important, coverage percentage is a very weak signal for security. Even with very high coverage, a protocol can easily miss testing of adversarial sequencing, of unexpected inputs, and of global system properties.
Static analysis looks for suspicious patterns, unsafe low-level code, dead code, shadowed variables, and reports known bugs. It is very fast to run and can be easily integrated into a continuous integration environment. It does not, however, attempt to economically reason about potential attacks, nor does it verify system-wide invariants. Furthermore, static analysis does not know the difference between legal code and harmful strategy.
Fuzzing involves feeding a program a stream of random inputs (or some guidance as to what to expect) to see how it behaves. It reaches edge cases that hand-written unit tests routinely miss, especially around input ranges and call sequencing. Of course, it still needs to be well designed and targeted against the relevant actors, and the test harness should model the relevant changes in state; otherwise you will just end up testing the easy ways to do things.
Invariant testing is another extremely valuable technique for securing smart contracts. Instead of testing for expected outcomes of individual function calls (i.e., unit testing), invariant testing ensures that a set of predefined local invariants hold true between different actions and function calls of a smart contract. These invariants can be asserted using tools like Foundry invariant testing, for example: total claimable value never exceeds available reserves; a user cannot gain shares without paying the intended asset for a share purchase.
Fork testing: For smart contract protocols, we test against the real chain and live contract interfaces. Here, integration tests expose the implementer's assumptions. However, note that even a fork is a snapshot in time. Thus, even fork testing must model how an attacker could change conditions over time.
Formal verification. This can be used for very narrow, high-value properties that are proven for all possible executions of the code within a given model. Access control, arithmetic bounds, and core accounting invariants are good examples of such properties. Note that formal methods are only as good as the specification of the properties that are verified.
Smart contract security tools are at their strongest when used in unison, paired with a threat model and its corresponding invariants. In other words, simply counting the number of unit tests that pass for a smart contract is not an adequate measure of the security of that contract. Rather, it is a measure of the amount of work that went into implementing the contract.
Many losses occur because someone had authority to do things that they should not have, or because sufficient friction in the exercise of authority was not present. So access control, where protocol design meets operational discipline, is where a lot of these losses will occur.
Role separation to manage access is the first control to put in place. The account that can pause a contract should not be able to upgrade the contract, and the account that can update parameters of a contract should not be able to drain the treasury of a contract or rotate all the roles of a contract to, for example, transfer all the funds to another account.
How a multisig is configured matters nearly as much as whether one exists at all. Thresholds for authorizing actions need to match the potential sensitivities of those actions, signers must be truly independent of each other, and every signer must connect from a truly distinct and separate device. Having a multisig with concentrated operational control can function nearly as badly as a single account.
Timelocks can be used to add review time to actions that can affect user funds or change the execution rules. The problem with timelocks is that they can slow down response time. Hence, in cases where emergency controls are required, teams typically have separate controls for pausing accounts and for changing the logic of a contract.
Designing pause mechanisms in advance is a good idea. First, an “emergency” pause that in fact prevents users from withdrawing their funds can quickly get out of hand. On the other hand, a pause that is too narrow can miss the core of an exploit path. It is therefore safer to a) restrict scope as much as possible, b) clearly document trigger conditions, c) rehearse the whole scenario in advance.
Well reviewed primitives such as OpenZeppelin Contracts documentation for well tested implementations of primitives such as roles, proxies, pause functionality and more help here. While the use of such primitives does not relieve the need for a thorough review of a system that uses them, it does reduce the chance of the implementer introducing a novel bug in the tried and tested code.
A blockchain security audit is a single checkpoint in a long engineering process. It is most valuable to a team that already has a stable codebase, written threat model, invariants, deployment assumptions, and test cases for core and adversarial scenarios.
An audit of unfinished code is a waste of the audit. Most of the review time will be spent reviewing code that will be deleted in the near future. Many of the findings will be rendered obsolete by subsequent changes to the code. Furthermore, issues related to trust boundaries, and issues related to code that uses privileged operations will likely receive little attention, because the surface area of code that is under review is changing on a daily basis.
The rule is simple. If the core interfaces, the role definitions, and the protocol invariants are still changing every few days, then there is not yet enough substance in the code under review for meaningful audit and review.
The monitoring for security threats in the post deploy security stage for a live protocol needs to monitor privileged actions, upgrade attempts, pause and unpause events, unusual changes in balances, failed calls in sensitive flows, abnormal mint or burn patterns, and changes in the health of external dependencies. Alerts need routing rules and severity levels, not just dashboards to view alerts.
An incident response runbook must be created before deployment. This runbook must contain information on who can declare an incident, who can pause a deployment, what triggers escalation, what communication channels are used, how evidence of an incident is captured, and what conditions must be met in order to resume normal operation.
Your teams should know what sort of signer set is required to pause, whether any timelocks are bypassed, which functions stop working and which continue to work, and how your users will be affected by the emergency control in place. Dry runs are important to test whether an emergency control is actually a control and not a disaster waiting to happen.
Additionally, planning out the upgrade and migration paths in advance will help a lot. For a system that is upgradeable, this means organizing the storage in a certain way, making sure all of the authorization is explicit, and ensuring that there are sufficient assumptions about how to reverse an upgrade in case something goes wrong. For an immutable system, designing out a migration plan, identifying a method for exporting the state, and planning out how to best communicate with users is necessary.
No. An audit can find important issues in code and design, but it does not replace threat modeling, strong testing, controlled admin paths, or post-deploy monitoring. A protocol is safer when the audit is one layer inside a disciplined engineering process.
It should start before implementation, when the team is still deciding trust boundaries, roles, external dependencies, and economic assumptions. Early threat modeling changes architecture. Late threat modeling usually produces patches around an already fixed design.
Unit tests check whether a specific input produces an expected output. Invariant testing checks whether a property stays true across many sequences of calls and state transitions, including adversarial ones. That makes it much better at catching system level failures in accounting and permissions.
Yes, if upgradeability is treated as part of the security model rather than as a convenience feature. That means proxy design is reviewed carefully, storage layout is managed deliberately, upgrade authority is tightly controlled, and changes are gated through multisig and timelock processes where appropriate.
Teams should watch privileged actions, unusual balance changes, sensitive event emissions, external dependency health, and signs that assumptions about liquidity or pricing are breaking. Monitoring should feed into alerting and a response runbook, not sit as passive telemetry.
