How To Stop Losing Money To DeFi Hacks
Editor’s Note: As DeFi hacks accelerate in the age of AI, this article by sysls examines how protocols can rethink security through layered defenses, operational discipline, and survival-focused design. Binance News publishes this article with the author’s approval.Disclaimer: This article includes third-party opinions and does not constitute financial advice. The content does not represent Binance's position. IntroductionBuilding @openforage and reading the myriad hacks of DeFi protocols have put the fear of "state actors" in me. They are sophisticated, well-resourced, and play the extreme long game; super-villains singularly focused on combing every crevice of your protocol and infrastructure for exploits, while your average protocol team has their attention split six ways running the business.I don't pretend to be a security expert, but having led teams in high-stakes environments (both in the military and in high finance with large sums of money), I am a seasoned operator in thinking about and planning for contingencies.I truly believe only the paranoid survive. No team ever sets out thinking "I am going to be careless and lackluster about my approach to security"; and yet hacks happen. We need to do better.AI Means This Time It's DifferentSourced from https://defillama.com/hacksHacks are not uncommon, but the frequency has clearly increased. Q1 of 2026 is the highest ever recorded number of DeFi hacks, and while Q2 has JUST begun, it is already on track to break the previous quarter's results.My central hypothesis is that AI has drastically reduced the cost of combing for exploits, and greatly increased the attack surface. A human takes many weeks to comb through the protocol settings of a hundred protocols for misconfigurations; the latest foundation models do it in a few hours.This should drastically change the equation of thinking about and reacting to hacks. Older protocols, used to security measures from before AI got competent, are increasingly at risk of being smoked.Thinking In Surfaces & LayersSourced from https://defillama.com/hacksRebuilt from https://defillama.com/hacksThe surface area of hacks reduces to, in practice just three: Protocol Team, Smart Contracts & Infrastructure, User Trust Boundaries (DSN, Social Media, etc).Once you've identified the surfaces, layer in defenses:• Prevention: Processes that, if followed, minimize the probability of being exploited.• Mitigation: Prevention has failed. Limit the damage.• Halt: Nobody makes their best decisions under pressure. Master kill switch the moment you confirm an attack. Freezing prevents further damage and buys space to think and...• Retake: If you've lost control of toxic or compromised components, jettison and replace them.• Recovery: Seize back what you've lost. Plan ahead for contacting institutional partners that can freeze funds, undo transactions, and aid investigation.PrinciplesThese principles guide the actions we can take to implement the layers of defences.Use Frontier AI LiberallyUse frontier-model AI liberally to scan your codebase and configs for vulnerabilities, and to red-team across a large surface area: try to find vulnerabilities in your frontend; see if they reach your backend. Attackers are going to do this. What your defensive scan can find, their offensive scan would have found.Use skills like pashov, nemesis and AI platforms like Cantina (Apex) and Zellic (V12) to quickly scan your codebase before committing to full audits.Time And Friction Are Good DefensesLayer in multi-step processes with timelocks for anything potentially damaging. You want plenty of time to step in and freeze once you smell something.The old argument against timelocks and multi-step setters was the friction they create for protocol teams. You have much less to worry about now: AI can easily click through these frictions in the background.InvariantsSmart contracts can be built defensively by writing down the immutable 'facts' that, IF broken, break the entire logic of your protocol.The crown invariant of @openforage centers on solvency (if total asset backing falls below total claims, the protocol collapses):VaultAssets + DeployedAssets >= OutstandingClaimsYou typically have a handful of invariants. Promote them to code sparingly; enforcing multiple per function gets unwieldy.Balance Of PowersMany hacks come from compromised wallets. You want configurations where even if a multisig is compromised, you can arrest damage quickly and bring the protocol to a state where governance can make decisions.This requires a balance between GOVERNANCE, which decides everything, and RESCUE, the abilities to restore governable stability (without being able to replace or overthrow governance itself).Something Is Going To Go WrongStart with the assumption that however smart you are, you will get hacked. Your smart contracts or dependencies might fail. You might get social engineered. A new upgrade might introduce a vulnerability you weren't prepared for.Once you think this way, rate limits that throttle damage and circuit breakers that lock down the protocol become your best friends. Limit damage to 5-10%, freeze, then game out your response. Nobody makes their best decisions with bullets in the air.The Best Time To Plan Is NowThe best time to think about your response is before you get hacked. Codify as much of the process as possible and rehearse with your team so you are not scrambling at impact. In the age of AI, that means having skills and algorithms that surface as much information as possible, as fast as possible, sharable in both summary and long form to your inner circle.The Name Of The Game Is SurvivalYou don't need to be perfect, but you sure as hell need to survive. No system is impenetrable from day 1; through multiple iterations, you become anti-fragile by incorporating lessons.The lack of evidence of being hacked is not evidence that you are not susceptible. The point of maximum comfort is going to be the point of maximum danger.PreventionsSmart Contract DesignOnce you've identified the invariants, promote them into runtime checks. Think carefully about what invariants are actually practical to enforce.This is the FREI-PI (Function Requirements, Effects, Interactions, Protocol Invariants) pattern: at the end of every function that touches value, re-verify the crown invariants the function promised to preserve. Many drains (flash-loan sandwiches, oracle-assisted liquidation griefs, cross-function solvency drains) that pass CEI (Checks-Effects-Interactions) get caught by an end-of-function invariant check.Good TestingStateful fuzzing builds random sequences of calls against the protocol's full public surface, asserting invariants at each step. Most production exploits are multi-transaction, and stateful fuzzing is just about the only reliable way of finding those paths before the attackers do.Use invariant tests that assert a property holds for ANY call sequence the fuzzer can generate. Complement with formal verification, which proves a property across all reachable states. Your crown invariants absolutely should get this treatment.Oracles And DependenciesComplexity is the enemy of security. Every external dependency extends the attack surface. If you're designing primitives, push the choice of who and what to trust to users. If you can't remove dependencies, diversify them so no single point of failure craters your protocol.Extend your audits to model the ways your oracles and dependencies can fail, and apply rate-limits to how much catastrophe can be done IF they do.The latest KelpDAO exploit illustrates: they inherited the LayerZero default of requiredDVNCount=1, and that config lived outside their audits. What eventually got compromised was off-chain infrastructure outside the scope of audits they had commissioned.Attack SurfacesMost attack surfaces in DeFi are already enumerated. Walk down every category, ask if it applies to your protocol, and implement the control that addresses the attack vector. Build red-team skills that force your AI agents to look for exploits in your protocol; this is table-stakes at this juncture.Having Native Rescue AbilitiesIn voting-based governance, power starts concentrated in the team's multisig and takes time to diffuse. Even with broad token distribution, delegation tends to funnel authority into a small set of wallets (sometimes n=1). When those get compromised, it's game over.Deploy "guardian wallets" with a strictly narrow mandate: they can ONLY PAUSE the protocol, and at a >=4/7 threshold can rotate compromised delegations to PRE-DEFINED replacement wallets in EXTREME situations. Guardians never enact governance proposals.This way, you have a rescue tier that can always restore governable stability without power to overthrow governance. The checkmate scenario, losing >=4/7 guardians, has minuscule probability given holder diversity, and the whole layer can be phased out once governance is mature and diversified.Wallet And Key TopologyMultisig wallets are table stakes, minimum 4/7. No single human controls all 7 keys. Rotate signers liberally, and quietly.A key should never interact with a device used for day-to-day tasks. If you browse the internet, use email, or have Slack on your signing device, take it as given that signer is already compromised.Have multiple multisigs, each with a distinct purpose. ASSUME at least one entire multisig will be compromised, and plan from there. No single person should have enough control to compromise the protocol, even under extreme scenarios (kidnapping, torture, etc.).Think About BountiesI really enjoyed Nascent's article on bounties. If you have resources, it is well-worth placing a large bounty on exploits relative to protocol TVL, but even if you are a fairly small protocol, the bounty on exploits should still be as generous as possible (e.g. 7-8 figs min).If you're dealing with state-sponsored attacks they are not interested in negotiating, but you can still engage in "White Hate Safe Harbor" programs that authorizes white-hats to act on your behalf in securing the fund for a % fee of the exploit (effectively a bounty paid by depositors).Find Good AuditorsI wrote earlier that as LLMs get smarter, the marginal value of engaging an auditor decreases. I still stand by that, but my views have shifted.First, good auditors stay ahead of the curve. If you're doing something novel, your code and its exploit may not be in training data, and throwing more tokens has not yet proven effective at finding novel solutions. You don't want to be sample point one for a unique exploit.Second, and underappreciated: engaging auditors stake their reputation on the line. If they sign off and you get exploited, they're highly incentivized to help. A relationship with people whose literal job is security is a boon.Practice Operational SecurityTreat operational security as a success metric. Play out phishing drills; pay a (trusted) red team to try and social-engineer the team. Have spare hardware wallets and devices lying around to replace entire multisigs. You don't want to scramble to buy these on D-day.MitigationYour Exit Path Is Your Loss CeilingThe capped size of any path that moves value out of your protocol is the maximum theoretical loss from a bug abusing that path. Plainly: a mint function without a per-block cap is a blank check to any infinite-mint bug. A redemption function without a weekly cap is a blank check to any asset-balance corruption.Think judiciously about explicit numbers on the size of your exit paths. That number balances the maximum damage you're willing to lose against the most extreme UX requirements of your users. IF something falls through, this is what saves you from complete destruction.Allowlists (And Denylists)Most protocols have lists of what can be called, traded, or received from, and lists of what users really DO NOT do. Even when implicit, these are trust boundaries that SHOULD be formalized.Formalizing them lets you set 2-stage setters that create meaningful friction. An attacker would first need to add to the allowlist (and/or remove from the denylist) and THEN act. Having both means an attacker sneaking in a new vector has to defeat both processes: the market must be allowed (integration/listing), AND the action must not be forbidden (security review).RetakeAlgorithmic MonitoringA kill-switch is useless if nobody is watching. Off-chain monitors should watch the crown invariants continuously and escalate algorithmically once something is wrong. The path should end at the humans of the guardian multisigs with enough context to make the call in minutes.Stop To RecalibrateIf you get shot, you stop the bleeding, not make decisions while your life counts down. With protocols, that's a kill switch (reflect it on the UI too): a single button halting every value-moving path in one transaction. Prepare a "pause everything" helper script that enumerates the pausable set and halts them atomically.Governance is the only way to unpause, so the kill switch must not halt governance itself. If the guardian tier can pause the governance contract, a compromised guardian tier can deadlock recovery permanently.Launch Your War RoomFreeze, stop the bleeding, then put everyone you trust (small circle, pre-agreed) into a communication channel. You want the surface small to keep information from leaking to attackers, the public, or bad-faith arbitrageurs.Role-play the roles your team needs: a shot-caller making decisions; an operator well-rehearsed at executing defensive scripts and halts (the shot-caller seconds); someone reconstructing the exploit and identifying root cause; someone on comms with key parties; someone scribing observations, events, and decisions over time.When everyone knows their role and has rehearsed, you react by process rather than scramble at the worst possible time.Think About Knock-On EffectsAssume your attackers are sophisticated. The first vulnerability may be a distraction, or a seed for more. The exploit may be bait to make you do the exact wrong thing that triggers the true exploit.Halts must be well-studied, fully contained, and not exploitable themselves. A halt should be a full protocol freeze: you don't want to be baited into halting one component in a way that opens another. Once you have root cause and attack vector, explore adjacent exposed surfaces and knock-on effects, and patch them all at once.Rotate Pre-committed SuccessorsRotation is only safe if the replacement is known in advance. I like the idea of a pre-committed successor registry: it makes it much harder for an attacker to swap a healthy guardian/governance wallet for a compromised one. This is in line with the "Allowlists/Denylists" philosophy in mitigation.For every important role, register a successor address. The only rotation primitive the emergency tier can execute is "replace role X with its successor". This also lets you evaluate successors during peace time: take your time, do diligence, fly over and meet the person making the request.Test Judiciously Before UpgradingOnce you've identified the root cause and splash zone, you'll need to ship an upgrade. This is probably the most dangerous code you will ever deploy: written under pressure, against an attacker who has already proven they understand your protocol enough to find bugs.Delay shipping without extensive testing. If you have no time for an audit, lean on white-hat relationships, or put up a 48-hour contest before deployment to get a fresh adversarial read before it goes live.RecoveryMove FastStolen funds have a half-life; once the exploit lands, they move rapidly down the laundering pipeline. Have a chain-analytics provider like Chainalysis on standby to label the attacker's address cluster across chains, so they can be flagged with exchanges in real time and tracked as they hop.Reach out to SEAL911 immediately!Pre-make a list of centralized exchange compliance desks, contract bridges, custodian admins, and other third parties with admin levers to freeze cross-chain messages or specific deposits in flight.NegotiateYes, it stings, but you should still attempt to talk to the attacker. Most things in life can be talked down. Offer a time-bound white-hat bounty paired with a public statement committing to no legal action if funds are returned in full by a deadline.If you're dealing with a state actor you're probably out of luck, but you might be dealing with less sophisticated actors who just found a way to exploit you AND want to get away with it cheaply.Before you do this, have legal counsel in the room.ConclusionThe hacks won't stop, and as AI gets smarter there will be more of them. It's not enough for defenders to "get sharper." We need to use the same tools attackers use, red-team our protocols, monitor continuously, and put hard limits on damage so we survive the worst.Special thanks to the team from @nascent for their thought provoking and forward looking articles on protocol security, and @delitzer for his brilliant feedback on the article and OpenForage. Likewise, thanks to @sohkai and @dbarabander for thoughtful feedback on article structure and clarity.
