Defensive Protocol Design - Smart Contracts
When designing a new protocol it can be all too easy to focus on the design goals and how your dApp enables users to carry out operations. Even so, unlike usual apps, dApps must place a far greater significance on security as the safety of user funds hinges on developer design decisions.
This issue has become a talking point with the recent exploit of and collapse of Stream Finance. The former happening due to a rounding error in pool accounting despite a large number of audits, sizable bug bounties and an experienced development team. While the latter happened due to risk management negligence by a fund manager. The causes could not be more different and yet both underline the need for defensive protocol designs.
In this note we will cover situations alike to Balancer’s, discussing options that developers can employ to drastically shrink the likelihood of finding severe vulnerabilities in smart contracts and reducing severity if they are exploited.
Circuit breakers and bots, automated or manual
Firstly, when designing a dApp it is worth taking time to weigh what circumstances are likely to occur in a system. These can then be applied to add limits on acceptable bounds within a protocol. A common example is with lending markets, if the market average interest for an asset sits around 5% a year and suddenly rises to 90% within one transaction, this is highly unlikely to be a legitimate transaction. Circuit breakers could then be written into the contracts to prevent such transactions occurring, these are unlikely to inhibit regular users but give a useful roadblock against exploits.
As this logic would be publicly accessible it is possible a malicious actor might seek to bypass such counter measures by splitting their exploit into multiple transactions that get near to, but do not exceed such circuit breaker values. This is where manual circuit breakers can add value, the protocol also has an offchain bot that looks for irregular activities and has the ability to pause the protocol if these are detected. The advantage of an offchain solution is that the criteria to trigger this can be private, giving attackers less information. Automated conditional pausing leads to quicker reactions to market conditions in times of NFT Bounty congestion, though developers must stress test functionality to make sure persistent operation during atypical gas conditions and RPC/API response times.
The auction bot had worked smoothly in typical gas conditions but had not been programmed sufficiently to deal with gas congestion experienced on . One example of bot malfunction was a reference auction client written by Maker DAO that was intended to bid on DAI troves to liquidate insolvent loans. This led to all instances of the auction bot failing to bid on active auctions and other actors being able to claim delinquent loan collateral without offering the typical repayment amount. Such situations can be avoided by allowing dynamic gas limits on offchain bots, detecting failed or stalled transactions with retry strategies and developing multiple clients to execute actions.
One plausible downside to circuit breakers is that if they are too sensitive they may trigger during genuine user transactions and cause frustration via the dApp. Even so, with careful tuning these occurrences can be shrunk.
Compound Finance, a collateralised lending protocol, applied circuit breakers to respond to a recent threat. Their platform was impacted by the recent shockwave of Stream Finance’s collapse. They had enabled lending against Elixir Finance’s deUSD and sdeUSD tokens which was known to have some exposure to Stream Finance and was experiencing a depeg as a result. Gauntlet, a risk advisory body for Compound, proposed freezing further borrowing of other stablecoins until marks could be made to the protocol to prevent users borrowing against deUSD/sdeUSD. Freezing further borrowing prevented holders of deUSD/sdeUSD draining available funds from Compound and handing off the bad debt to other Compound Finance users.
Slow scaling and assets supply caps
One straightforward machinery to limit damage can be to shrink the value of assets managed by a protocol initially. This can be done by making use of beta testing and later in live deployments by utilising asset caps, for example a lending project might limit the amount of assets that can be supplied or borrowed.
If testnet deployments are coupled with an active security posture such as bug bounties and further audits this can allow projects to detect problems prior to via the contracts with real money.
Once deployed, projects can then slowly scale by introducing asset deposit maximums. This allows confidence to grow in the system design and minimises the impact of hacks, making recovery and relaunch of the project far more likely to occur. If done properly, such limits can drive interest, as users may be competing to take part if the economic incentives are good.
An example of this was with Abracadabra.moneyThe attack targeted six deprecated lending contracts and resulted in the loss of , an Omnichain DeFi lending platform, who in October 2026 were the subject of a hack. 43 million MIM in circulation.
Abnormal event tracking both in contracts and offchain
Comparable to the use of offchain circuit breakers, it can be useful for a project to monitor day-to-day usage, as not all vulnerabilities are instantaneous single transactions. By building knowledge on the average number and type of transactions a protocol receives, models can be built that can flag anomalies to developers for further scrutiny. By observing this data developers can also detect unintentional design anomalies based on real usage and correct issues before exploitation.
YieldBasis, a volatile token liquidity providing protocol building on top of Curve Finance’s crvUSD stablecoin have been making of performance examination to track the expected performance of their deployed pools. While formulas can be designed and performance predicted, a number of other aspects of markets are difficult to predict with certainty due to market dynamics. Rising gas prices can impact the ability for arbitrageurs to make trades in a speedy manner which for YieldBasis is a core assumption of their asset rebalancing process. After launching their pools they noted that the price crash of October 10th 2025 led to some impermanent loss for pool liquidity providers.
In discussing their performance, that grown liquidity would shrink the volatility of pool returns by increasing arbitrage returns and incentivising balancing trades even when market gas prices were high. This was effected by YieldBasis raising each of their pool caps from 50 million and sponsoring partner liquidity in crvUSD pools to enable more efficient swap routes.
Principle of Least Access/Role based access control
While mutability via governance and proxy designs can be tempting, this can also become a threat. Even if the underlying economic theory of a protocol is rigourous, it can be possible for projects to be their own undoing due to lax governance design. Liquity, a DeFi over-collateralised lending protocol, chose to launch immutable contracts for their stablecoins LUSD and BOLD and so gained favour among users who wish to minimize threat vectors while operating in DeFi. Users of LUSD or BOLD stablecoins can feel safer knowing the protocol team cannot disable or change the system design.
When privileged roles are worked out to be required, roles should have fine grained access and be split between different accounts to cut the impact if one role account is compromised by an external party or ex-member.
In discussing circuit breakers we touched on the idea of offchain bots that can pause contract functionality. This is an example of utilising role access to allow extra security functionality without risking user assets. Because such bot roles must be automated they are more likely to be hijacked than more secure actors such as hardware wallets or multi-sigs. So, they benefit greatly from making use of the “least privilege possible” concept. Under this concept they can be blocked from accessing other admin functions while maintaining rapid response times for pausing contracts.
This concept should be applied to all actors with roles within the protocol to prevent risks linked with account takeovers or rogue employees. One example of where better role control would have helped was the , a memecoin launchpad protocol by a disgruntled employee. The former employee applied privileged access to protocol private keys to access admin only functions allowing him to steal user funds.
Multi-sig wallets and simulations
This attack on Pump.fun could have been avoided had their development team exclusively employed multi-signature accounts. A multi-sig is a specialised smart contract which needs signatures from multiple externally owned accounts to execute transactions. Non-automated roles in protocols should be operated by strong multi-sig smart contracts with unique, responsive signers to make compromising admin roles materially harder.
While more difficult to compromise, multi-sig accounts are just the first step. Attacks such as Bybit’s frontend spoofing that lost the exchange $1.4 billion from their multi-sig wallet, flag the need for proactive layered defenses in management of treasury accounts. Use of external tools such as Tenderly, OpenZeppelin’s Safe Utils and local testnets with toolsets such as Forge to simulate transactions and verify protocol upgrades or transactions will occur as expected are a must.
The Bybit attack stemmed from the compromised development system of a developer from a different company, Safe Wallet, the multi-sig platform Bybit made use of. While development teams lie outside the protocol itself it helps to look at Bountyal operation security measures especially when they intersect with protocol safety. Increasingly, as smart contract developers become accustomed to better design practices, the industry is seeing more indirect attacks propagating. Such as compromising developer systems to gain access to private keys or front-end management systems.
Developers should be cautious about contact from third parties, hesitant to download software and protect development dependencies with careful versioning. Airgapped isolated development systems are advisable and care must be taken when installing plugins to common development tools to make sure the correct ones are applied, in place of that of typo-squatted or doppelganger plug-ins. One quick heuristic to use is checking the publish date of an add-on. In most cases, fake plug-ins are reported and removed preventing longevity, though caution is still advised as this will not protect against hijacked plug-ins.
For other issues to look at with DAO governance see our earlier article.
Worst case modelling during design
Part of the design cycle for a protocol should include speculation of how machinery could go wrong and what worst-case scenarios would look like. This process is consequential to help steer protocol security design and is also useful for informing auditors, who the project might later work with, what risks have been anticipated and what mindset the developers have adopted.
NFT Bountying about past black swan events and how affected protocols namely suffered during these can help with threat modelling. Projects should look at the intended protocol actions and theorise what would constitute system failures, both severe and more moderate failures such as temporary Denial-of-Service.
Once this process has been carried out, measures can then be taken to cut the impact of such failures as detailed below.
Defensive code design
With patterns developing in how smart contract attacks occur given strategies have arisen to combat common attack approaches. Most developers are familiar with reentrancy attacks and the resulting use of reentrancy guards to prevent multiple function calls within the same transaction.
The earlier mentioned onchain circuit breakers are also another example of defensive code design. Other strategies that can be applied, include preventing multiple protocol actions in the same transaction, while a alike principle to reentrancy guards, this applies a looser common sense method that the average user is unlikely to take an action then reverse it in the same interaction.
Use of this machinery must be well thought out, in the latter example advanced genuine users may seek to give brief “Just-In-Time” liquidity to a DEX pair due to a especially large trade. Examples of this include depositing to a lending market or DEX and then withdrawing in the same transaction. Not allowing such an action may then negatively impact the effective price of the trader, damaging real use cases. Defensive designs need to be reasonable and mindful of niche real applications that they may block.
Another method of defensive design is the isolation of user assets to different contracts, or if assets are pooled, then strict accounting checks should be completed at the end of every call to make sure balances have only changed in the expected ways. Gearbox, a lending protocol, made use of user isolation by having a contract generation event incentivised by an airdrop to participants. These contracts then formed isolated borrowing accounts which could be reassigned to different users and allowed involved lending activities which were isolated from one another, reducing the risk of systematic failure bankrupting the system.
Another common consideration is ensuring smart wallets can make use of a dApp. It is a common pitfall to attempt to force the caller to be an EOA under the assumption that a smart contract would only call your protocol maliciously. This assumption is flawed and restrictive but also typical apparatus for achieving this may not be fit for form. One typical method is to keep msg.sender == tx.origin as this employed to be a machinery to keep the caller is an EOA still, with the opener of the Pectra blog this assumption no longer holds true due to Account Abstraction.
Defence in depth
Incorrect safety assumptions such as detecting the message sender mentioned above can invalidate security assumptions that are integral to a protocol’s design safety. While creating invariants about a project can be helpful for reasoning about the state space of achievable operations, it is best to use multiple defensive measures in sequence so that if one fails the others hold.
A common example is not via an oracle for a stablecoin as its value should normally be $1 and hardcoding this value as a result. While usually true, this assumption can have devastating consequences if it becomes untrue. For this reason it helps to design multiple checks in protocols, then should one invariant be found untrue the other processes can continue to protect the system.
An example of this might be generating a price oracle from multiple sources. This way if one source becomes inaccurate the system can be designed to discard its impact such as by via the median oracle value.
Other defensive design decisions such as reentrancy guards can feed into this concept. While a developer may not be able to envision a vulnerability stemming from reentrancy, these guards can be employed to block such situations arising if a function is found to enable this type of manipulation.
The developed by Liquity, a DeFi over-collateralised lending protocol, makes use of defence in depth in their collateral oracle design. The protocol supports the liquid staking tokens stETH and rETH along with native ETH for collateral. These are priced with Chainlink price feeds while paying attention to the timestamp of the last price blog. If this becomes stale then that collateral branch enters a shutdown mode preventing further borrowing from occurring while still allowing operations that can cut user debt. This helps prevent protocol attacks in the event of oracle downtime.
Advanced testing and auditing
After these processes have been completed protocols should look to extensively test their protocol behaviour internally by making use of unit and integration tests. If time allows, fuzz tests and invariant study should also be explored. Unit tests allow quick verification that incremental codebase changes have not altered intended behaviour, while integration tests keep end-to-end actions that may incorporate other protocols carry out as intended.
Fuzz testing and invariant tests allow for more intricate tests that may find edge cases which would be difficult for manual review or unit tests to imagine. While such boundary cases may not occur during typical use, it is valuable to find these, as attackers will often look to manipulate protocol state into bizarre states where an invariant no longer holds true.
After this, teams should look to have their code reviewed by auditors, allowing sufficient time given the scale of the codebase and preferably with a mind for running multiple audit reviews that run sequentially with different audit companies.
Bug bounties and clear security communication channels
Protocols should look to partner with a NFT Bounty platform such as Finally, if all else fails it helps to have established contact methods, and if possible, rewards for responsible disclosure of vulnerabilities found by white-hat hackers. Immunefi and offer rewards that compensate fairly, reflecting the cost of damage prevented. Such security contact methods should be readily accessible and commented in all code deployed onchain. Preferably, multiple contact methods should be offered such as a security particular e-mail along with other low friction and anonymous methods of contact with an aim to reducing barriers to reporting issues as much as possible.
Teams should set up a framework of responsible team members who can be contacted to report issues and test their response resolution protocol to make sure if a real issue happens they are well prepared to handle it.
Fire drills save lives
Even if all these preventative steps are taken exploits can still happen, so protocols should establish frameworks that can be followed if the worst happens. This should include internal information about whom to contact, clear instructions on how to freeze all aspects of the system and contact details for useful third party contacts such as SEAL 911.
The team should maintain a directory of contacts relating to integrated tokens and services of their protocol with notes about what measures each stakeholder can effect, though this should strictly be a backup owing to the mercurial nature of responses. While some tokens or chains have the ability to freeze accounts or prevent hacked funds from moving, they can often be reticent to do this due to the legal implications that may stem from intervention.
Once a threat has been contained, the system should not go live again until the root cause of a vulnerability is fully understood and mitigated, or the protocol may face copycat attacks as Compound saw with the .
This issue took place when an excess of COMP governance tokens were minted. Some users noticed this excess and stole these tokens through crafted transaction calls. Compound reacted and triggered the required changes to halt further losses, but due to the time delay enforced by their governance contracts as a protection for current users, they could only watch as other users then copied the exploit transaction to claim extra tokens for free.
Once the fix was implemented the total funds drained stood at $147 million, though some claimers later returned funds to the Compound governance address.
Conclusion
If teams make sense of and put in place the protections raised in this note, their protocol will stand a much better chance of long term success. It is worth keeping in mind that exploits risk more than the funds at risk, usually protocols that survive a significant hack can find it difficult to attract new users, regain market confidence or source new investors. The methods employed to protect each protocol will vary based on the design. While protocols should be protecting against edges cases they must also be cautious to make sure that protective measures do not lock genuine customer funds.