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

Writing: sysls

Compilation: AididiaoJP, Foresight News

Original link:

Disclaimer: This article is reproduced content. Readers can obtain more information through the original link. If the author has any objections to the reproduction, please contact us, and we will modify it according to the author’s requirements. Reproduction is only for information sharing and does not constitute any investment advice or represent Wu Shuo’s views and positions.

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 directions.

I do not claim to be a security expert, but I have led teams in high-risk environments (including military and high-stakes finance), with 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

(Source:

Hacking is not rare, but the frequency is clearly increasing. The first quarter of 2026 recorded the highest number of DeFi hacks ever, and the second quarter has just begun, already promising to break the previous quarter’s record.

My core hypothesis is: AI drastically reduces the cost of finding vulnerabilities and greatly expands 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 hacking. Old protocols that relied on security measures before AI became powerful are increasingly at risk of being “秒杀” (instant kill).

Thinking in Surface and Hierarchies

(Source:

The surface area of hacking can actually be boiled down to three: protocol teams, smart contracts and infrastructure, and user trust boundaries (DSN, social media, etc.).

Once these surfaces are identified, layered defenses can be added:

Prevention: Strict enforcement of processes to 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 coordinate with institutions that can freeze funds, revoke transactions, and assist investigations.

Principles

These principles guide the specific actions for implementing each layer of defense.

Use Cutting-Edge AI Extensively

Leverage advanced AI models to scan your codebase and configurations for vulnerabilities, and conduct red-team testing across surfaces: try to find vulnerabilities at the front end to see if they can reach the backend. Attackers do this. What you can detect through defensive scans, they have already done with offensive scans.

Use skills like pashov, nemesis, and AI platforms like Cantina (Apex) and Zellic (V12) to quickly scan codebases before submitting comprehensive audits.

Time and Friction Are Good Defenses

Add multi-step processes and time locks to any potentially damaging operation. 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 cautiously to code; enforcing multiple invariants in every function becomes unmanageable.

Power Balance

Many hacks originate from compromised wallets. You need a configuration where, even if multi-sig is breached, you can quickly contain damage and bring the protocol back to a governance-decision state.

This requires balancing Governance (deciding everything) and Rescue (restoring governance stability but not replacing or overthrowing 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 limiting damage and circuit breakers for 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 panic when the attack hits. In the AI era, this means having skills and algorithms capable of rapidly presenting large amounts of information, sharing summaries and long-form reports with your core circle.

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

Absence of hacking evidence 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 via CEI (Checks-Effects-Interactions) patterns (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 protocol’s entire public surface, 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 absolutely 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 failure modes, and impose rate limits on potential disasters if they fail.

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

Surface Attacks

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

Have Native Rescue Capabilities

In governance based on voting, power initially concentrates in multisig wallets, which take time to diffuse. Even with broad token distribution, delegation often concentrates authority into 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, they can, in extreme cases, rotate the compromised delegation to predefined replacement wallets. Guardians can never execute governance proposals.

This provides an always-available rescue layer that can restore governance stability without the power to overthrow 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 fundamental, minimum 4/7. No single person controls all 7 keys. Rotate signers frequently and silently.

Keys should never interact with daily-use devices. If you sign on a device browsing the internet, checking email, or opening Slack, that signer is already compromised.

Have 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, set a high bounty for vulnerabilities relative to protocol TVL; even smaller protocols should offer as generous a bounty as possible (e.g., at least 7-8 figures).

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

Find Good Auditors

I previously argued 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. Merely increasing token counts has not proven effective at discovering new vulnerabilities. You don’t want to be the first to have a unique vulnerability.

Second, an underrated benefit: 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.

Practice 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 the Loss Limit

Any path that moves value out of the protocol has a maximum theoretical loss—this is the cap if that path is exploited. Simply put: a mint function without per-block limits is a blank check for infinite minting vulnerabilities. A redemption function without weekly limits is a blank check for asset balance damage.

Carefully consider clear numerical limits for your exit paths. This number must 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, or received, and lists of users who are explicitly forbidden. Even if implicit, these are trust boundaries and should be formalized.

Formalizing 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 attackers must break two processes simultaneously: the market must be allowed (listed/onboarded), and the action must not be prohibited (security review).

Reclaim

Algorithm Monitoring

Without human oversight, kill switches are useless. Off-chain monitors should continuously check invariants and algorithmically escalate alerts if issues are detected. The final path should be to human guardians with multi-sig, providing enough context for them to make decisions within minutes.

Pause and Recalibrate

If you are compromised, stop the bleeding first, rather than making decisions under countdown. For protocols, this is the kill switch (also reflected in UI): a button to pause all value-moving paths in a single transaction. Prepare a “pause everything” auxiliary script that enumerates all pausable components and pauses them atomically.

Only governance can lift the pause; the kill switch cannot pause governance contracts. If guardians can pause governance, a breached guardian layer could permanently deadlock recovery.

Activate Your War Room

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

Role-play for team members: one decision-maker; one skilled operator executing defense scripts and pauses; one analyzing vulnerabilities and root causes; one communicating with key parties; one recording observations, events, and decision timelines.

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

Consider Chain Reactions

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

Pausing must be thoroughly researched, fully controllable, and itself not exploitable. The pause should be a full protocol freeze: you don’t want to be tricked into pausing one component and opening another. Once root causes and attack vectors are identified, explore adjacent surfaces and chain reactions, fixing everything at once.

Rotate Pre-Agreed 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.

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

Test Carefully Before Upgrading

Once root causes and scope are clear, you need to deploy upgrades. This may be the riskiest code you write—under pressure, targeting attackers who already know your protocol and vulnerabilities.

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

Recovery

Act Fast

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

Pre-arrange a list of third parties with authority to freeze cross-chain messages or in-transit deposits—exchanges, bridge administrators, custodians, etc.

Negotiate

Yes, it’s painful, but you should still try to communicate with attackers. Many things in life can be negotiated. 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 sophisticated attackers who just found a way to exploit you and want to exit at lower cost.

Always have legal counsel present before doing this.

Conclusion

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