DeFi Security Guide: How to Effectively Defend Against Hacker Attacks in the AI Era?

Original Title: How To Stop Losing Money To DeFi Hacks
Original Author: sysls, openforage
Original Compilation: AididiaoJP, Foresight News

Introduction

After learning about numerous DeFi protocol hacking incidents, I have developed a fear of “state actors.” They are highly skilled, well-resourced, and play an extremely long-term game; these supervillains focus on scrutinizing every corner of your protocol and infrastructure for vulnerabilities, while ordinary protocol teams are distracted by six or seven different business areas.

I don’t claim to be a security expert, but I have led teams in high-risk environments (including military and high-value financial sectors), and have extensive experience in thinking through and planning emergency responses.

I sincerely believe that only paranoids can survive. No team starts out thinking “I will be careless and negligent about security”; yet hacks still happen. We need to do better.

AI Means This Time Is Truly Different

(Data source: https://defillama.com/hacks)

Hacks are not rare, but their frequency is clearly increasing. The first quarter of 2026 was the quarter with the most recorded DeFi hacks, and although the second quarter has just begun, it already looks set to break the previous quarter’s record.

My core assumption is: AI has significantly lowered the cost of finding vulnerabilities and greatly expanded the attack surface. Humans need several weeks to review configurations of a hundred protocols for misconfigurations; the latest foundational models can do it in just a few hours.

This should fundamentally change how we think about and respond to hacks. Old protocols that relied on security measures before AI became powerful are increasingly at risk of being “秒杀” (instantly defeated).

Think in Surface and Hierarchies

(Data source: https://defillama.com/hacks)

The surface area of hacks can actually be summarized into three: protocol teams, smart contracts and infrastructure, and user trust boundaries (DSN, social media, etc.).

Once these surfaces are identified, layer on defenses:

· Prevention: Processes that, if strictly enforced, can minimize the probability of exploitation.

· Mitigation: When prevention fails, limit the damage.

· Pause: No one can make optimal decisions under immense pressure. Once an attack is confirmed, immediately activate the kill switch. Freezing can prevent further losses and buy time for thinking…

· Reclaim: If you lose control of toxic or compromised components, abandon and replace them.

· Recovery: Regain what you lost. Plan in advance to work with institutions that can freeze funds, revoke transactions, and assist investigations.

Principles

These principles guide the specific actions for implementing layered defenses.

Heavy Use of Cutting-Edge AI

Use advanced AI models extensively to scan your codebase and configurations for vulnerabilities, and conduct red-team testing across surfaces: try to find exploits at the front end to see if they can reach the backend. Attackers do this. Defensive scans that you can perform are already being done by their offensive scans.

Utilize skills like pashov, nemesis, and AI platforms such as Cantina (Apex) and Zellic (V12) to quickly scan codebases before submitting full audits.

Time and Friction Are Good Defenses

Add multiple steps and time locks to any operation that could cause damage. You need enough time to intervene and freeze when anomalies are detected.

Past objections to time locks and multi-step setups were that they cause friction for protocol teams. Now, you don’t need to worry too much: AI can easily click through these frictions in the background.

Invariants

Smart contracts can be defensively built by writing immutable “facts”: if these facts are broken, the entire protocol logic collapses.

Typically, you only have a few invariants. Elevate them carefully to code; enforcing multiple invariants in every function becomes hard to manage.

Power Balance

Many hacks originate from compromised wallets. You need configurations that, even if multisig is broken, can quickly contain damage and bring the protocol back to a governance decision-making state.

This requires balancing governance (which decides everything) and rescue (restoring controllable stability without replacing or overturning governance).

Problems Will Always Occur

Start with the assumption: no matter how smart you are, you will be hacked. Your smart contracts or dependencies may fail. You might suffer social engineering attacks, and new upgrades could introduce unforeseen vulnerabilities.

Thinking this way, rate limits that restrict damage and circuit breakers that lock the protocol become your best friends. Limit damage to 5-10%, then freeze and plan your response. No one can make perfect decisions in a hail of bullets.

The Best Time to Plan Is Now

Think through your response plan before being hacked. Encode processes as much as possible and rehearse with your team so you won’t be caught off guard when impact hits. In the AI era, this means having skills and algorithms capable of rapidly presenting large amounts of information, sharing summaries and detailed reports with your core circle.

You don’t need perfection, but you must survive. No system is invulnerable from day one; through multiple iterations, you will become resilient by learning from lessons.

Absence of evidence of being hacked does not mean you won’t be hacked. The greatest comfort zone is often the greatest danger zone.

Preventive Measures

Smart Contract Design

Once invariants are identified, elevate them to runtime checks. Carefully consider which invariants are truly worth enforcing.

This is the FREI-PI (Function Requirements, Effects, Interactions, Protocol Invariants) pattern: at the end of each function that touches value, re-verify the invariants that the function promises to maintain. Many exploits involving CEI (Checks-Effects-Interactions) patterns—like flash loan sandwiches, oracle-assisted liquidations grief, cross-function solvency drains—can be caught by invariant checks at function end.

Good Testing

Stateful fuzzing generates random call sequences over the full public surface of the protocol, asserting invariants at each step. Most vulnerabilities in production are multi-transaction, and stateful fuzzing is almost the only reliable way to discover these paths before attackers do.

Use invariants to assert properties across all call sequences generated by fuzzers. Coupled with formal verification, it can prove properties hold in all reachable states. Your crown invariants should definitely accept this approach.

Oracles and Dependencies

Complexity is the enemy of security. Every external dependency expands the attack surface. When designing primitives, give users the choice of whom and what to trust. If dependencies cannot be eliminated, diversify them so no single failure point can destroy your protocol.

Extend audit scope to simulate oracle and dependency failures, and impose rate limits on potential disasters caused by their failure.

The recent KelpDAO vulnerability is an example: they inherited the default LayerZero requiredDVNCount=1 configuration, which was outside their audit scope. Ultimately, the breach was in off-chain infrastructure outside their audit coverage.

Surface Attacks

Most surface attack vectors in DeFi have already been listed. Check each category, ask whether it applies to your protocol, and implement controls against that vector. Cultivate red-team skills, and have your AI agents actively seek vulnerabilities in your protocol; this is now a basic requirement.

Native Rescue Capabilities

In voting-based governance, power initially concentrates in the team’s multisig, which takes time to diffuse. Even with broad token distribution, delegation often centralizes authority in a few wallets (sometimes just one). When these wallets are compromised, the game is over.

Deploy “Guardian Wallets” with strict, narrow permissions: they can only pause the protocol, and at a threshold of >=4/7, can in extreme cases rotate compromised delegations to predefined replacement wallets. Guardians can never execute governance proposals.

This creates a rescue layer that can always restore governance stability without having the power to overturn governance. The probability of losing >=4/7 guardians is extremely low (considering holder diversity), and once governance matures and disperses, this layer can be phased out.

Wallet and Key Topology

Multisig wallets are a minimum requirement, at least 4/7. No single person controls all 7 keys. Rotate signers frequently and silently.

Keys should never interact with daily-use devices. If you use a signing device to browse the internet, send emails, or open Slack, consider that signer compromised.

Maintain multiple multisigs, each for different purposes. Assume at least one full multisig will be compromised, and plan from there. No individual should have enough control to break the protocol, even under extreme scenarios (kidnapping, torture, etc.).

Consider Bounties

If resources permit, setting a high bounty for vulnerabilities relative to protocol TVL is very worthwhile; even smaller protocols should offer as generous a bounty as possible (e.g., low 7-8 figures).

If facing state actors, they may refuse to negotiate, but you can still participate in “White Hat Safe” programs, authorizing white hats to act on your behalf to protect funds, and taking a percentage of the bug bounty as a fee (paid by depositors).

Find Good Auditors

I’ve written before that as large language models become smarter, the marginal value of hiring auditors declines. I still hold that view, but my perspective has shifted.

First, good auditors stay ahead of the curve. If you’re doing something novel, your code and vulnerabilities may not be in their training data, and simply increasing token count has not proven effective at discovering new vulnerabilities. You don’t want to be the first sample point for unique bugs.

Second, an underrated benefit is: hiring auditors is a reputation guarantee. If they sign off and you get attacked, they are strongly incentivized to help. Building relationships with security professionals is a huge advantage.

Operational Security

Treat operational security as a success metric. Conduct phishing drills; hire (trusted) red teams to attempt social engineering attacks on your team. Prepare backup hardware wallets and devices to replace entire multisigs if needed. You don’t want to scramble to buy these on D-day.

Mitigation Measures

Your exit path is capped by your loss limit

Any path that moves value out of the protocol has a maximum theoretical loss, which is the cap size. Simply put: a mint function without per-block limits is a blank check for any infinite minting vulnerability. A redemption function without weekly limits is a blank check for any asset balance damage.

Carefully consider clear numerical limits for your exit paths. These numbers should balance your maximum tolerable damage and extreme user UX needs. If something goes wrong, this is what can save you from total destruction.

Whitelists (and Blacklists)

Most protocols have lists of addresses that can be called, transacted with, or received, and lists of users who are absolutely forbidden from acting. Even if implicit, these are trust boundaries and should be formalized.

Formalizing them allows you to set up two-phase setters, creating meaningful friction. Attackers must first add to the whitelist (or remove from blacklist) before acting; having both means they must break two processes simultaneously: the market must be enabled (listed), and the action must not be prohibited (security review).

Reclaim

Algorithm Monitoring

Without monitoring, kill switches are useless. Off-chain monitors should continuously track invariants, and if issues are detected, escalate alerts algorithmically. The final path should reach human guardians of the multisig, providing enough context for them to make decisions within minutes.

Pause and Recalibrate

If you are compromised, first stop the bleeding, not make decisions during countdown. For protocols, this is the kill switch (also UI-visible): a button that can pause all value-moving paths in one transaction. Prepare a “pause everything” auxiliary script that enumerates all pausable components and pauses them atomically.

Only governance can lift the pause, so the kill switch cannot pause governance contracts themselves. If the guardian layer can pause governance, a compromised guardian layer could permanently deadlock recovery.

Activate Your War Room

Freeze, stop bleeding, then bring all trusted personnel (small circle, pre-agreed) into a communication channel. Keep it small to prevent leaks to attackers, the public, or malicious arbitrageurs.

Role-play key roles: decision-maker; skilled operator executing defense scripts and pauses; someone reconstructing vulnerabilities and identifying root causes; a communicator with key stakeholders; someone recording observations, events, and decision timelines.

When everyone knows their role and has rehearsed, you can respond systematically instead of panicking at the worst moment.

Consider Chain Reactions

Assume your attacker is highly skilled. The first vulnerability might be a decoy or a seed for subsequent attacks. The attack could be designed to induce you to do something completely wrong, triggering the real exploit.

Pauses must be thoroughly researched, fully controllable, and not exploitable themselves. Pausing should freeze the entire protocol: you don’t want to be tricked into pausing one component and opening another. Once root causes and attack vectors are identified, explore adjacent exposed surfaces and chain reactions, and fix everything at once.

Pre-commit Successors

Only with prior knowledge of successors is rotation safe. I like the idea of a pre-committed successor registry: it makes it harder for attackers to replace healthy guardians/governance wallets with compromised ones. This aligns with the “whitelist/blacklist” concept in mitigation measures.

Register a successor address for each key role. The only primitive for emergency rotation is “replace role X with its successor.” This also allows you to evaluate successors during peace time: take your time, do due diligence, and meet with the proposer.

Test Carefully Before Upgrading

Once root causes and scope are clear, you need to deploy an upgrade. This might be the riskiest code you write: under pressure, targeting attackers who already understand your protocol and vulnerabilities.

Delay deployment without thorough testing. If time is tight, rely on white-hat relationships or set up a 48-hour challenge before deployment to get a fresh adversarial review.

Recovery

Act Fast

Stolen funds have a half-life; once the breach occurs, they quickly enter laundering channels. Prepare in advance with on-chain analysis providers like Chainalysis to track attacker address clusters in real-time, and notify exchanges when they cross chains for tagging and tracking.

Pre-arrange a list of third parties with authority to freeze cross-chain messages or specific in-transit deposits—such as centralized exchanges, cross-chain bridge admins, custodians, and others.

Negotiate

Yes, it’s painful, but you should still try to communicate with attackers. Many things in life can be resolved through negotiation. Offer time-limited white-hat bounties and publicly state that if funds are fully returned before the deadline, no legal action will be taken.

If facing state actors, luck may be against you, but you might be dealing with less experienced attackers who simply found a way to exploit you and want to exit at lower cost.

Always have legal counsel present before doing so.

Conclusion

Hacks will not stop; as AI gets smarter, attacks will only increase. Merely making defenders “more alert” is not enough. We need to use the same tools as attackers—red teaming our protocols, continuous monitoring, and setting hard limits on damage—so we can survive the worst-case scenarios.

Original Link

Click to learn about Rhythm BlockBeats job openings

Join the Rhythm BlockBeats official community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Group: https://t.me/BlockBeats_App

Twitter Official Account: https://twitter.com/BlockBeatsAsia