Getting used to the protocols of security measures before AI became powerful is increasingly facing the risk of being "dominated" in an instant.

Written by: sysls

Compiled by: AididiaoJP, Foresight News

Introduction

After understanding a large number of DeFi protocol hacking incidents, I developed a fear of "national actors." They are technically skilled, well-resourced, and engage in an extremely long-term game; these supervillains focus on combing through every corner of your protocols and infrastructures in search of vulnerabilities while the attention of regular protocol teams is scattered across 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 the military and high-stakes finance) and have extensive experience in thinking about and planning emergency responses.

I firmly believe that only the paranoid can survive. No team starts out thinking, "I want to take a careless and perfunctory approach to security"; yet hacks still occur. We need to do better.

AI Means This Time It’s Really Different

(Source: https://defillama.com/hacks)

Hacking incidents are not uncommon, but the frequency is noticeably increasing. The first quarter of 2026 saw the highest number of recorded DeFi hack incidents, and even though the second quarter has just begun, it is already on track to break the previous quarter's record.

My core assumption is this: AI significantly lowers the cost of seeking vulnerabilities and greatly expands the attack surface. It may take humans weeks to comb through the configurations of one hundred protocols looking for misconfigurations; the latest foundational models can do this in just a few hours.

This should fundamentally change how we think about and respond to hacks. Those old protocols that became accustomed to security measures before AI became powerful are increasingly facing the risk of being "dominated" instantly.

Thinking in Layers and Surface

(Source: https://defillama.com/hacks)

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

Once these surfaces are identified, defensive layers should be stacked:

• Prevention: If strictly enforced, processes can minimize the likelihood of being exploited.
• Mitigation: When prevention fails, limit the extent of damage.
• Pause: No one can make optimal decisions under extreme pressure. Once an attack is confirmed, immediately engage the kill switch. Freezing can prevent further losses and buy some thinking space...
• Recapture: If you lose control over toxic or compromised components, discard and replace them.
• Recovery: Reclaim what you have lost. Pre-plan partnerships with organizations that can freeze funds, reverse transactions, and assist in investigations.

Principles

These principles guide our implementation of specific actions across various layers of defense.

Extensive Use of Cutting-Edge AI

Extensively utilize cutting-edge models of AI to scan your codebases and configurations for vulnerabilities, and conduct red team testing across broad surfaces: attempt to find vulnerabilities on the frontend to see if they can reach the backend. Attackers would do just that. What you can discover through defensive scanning, their offensive scanning has likely already detected.

Utilize skills such as pashov, nemesis, and AI platforms like Cantina (Apex) and Zellic (V12) to quickly scan the codebase prior to submission of a complete audit.

Time and Friction are Good Defenses

Add multi-step processes and time locks to any operations that may cause damage. You need enough time to intervene and freeze when anomalies are detected.

The past objections against time locks and multi-step setups were that they created friction for protocol teams. Now you needn’t worry too much about that: AI can easily click through these frictions in the background.

Invariants

Smart contracts can be defensively constructed by writing immutable "facts": if these facts are broken, the entire logic of the protocol collapses.

You generally only have a few invariants. It is important to elevate them to the code level carefully; enforcing multiple invariants in each function can become difficult to manage.

Balance of Power

Many hacks stem from compromised wallets. You need configurations such that even if multi-sig is compromised, it can swiftly contain the damage and return the protocol to a state where governance can make decisions.

This requires a balance between Governance (which decides everything) and Rescue (which recovers the ability to govern stability but cannot replace or overturn governance itself).

Things Will Go Wrong

Assume from the outset: no matter how smart you are, you will be hacked. Your smart contracts or dependencies may fail. You may fall victim to social engineering attacks, new upgrades might introduce vulnerabilities you didn’t anticipate.

Once you think this way, rate limits that restrict damage and circuit breakers that lock down the protocol will become your best friends. Limit damage to 5-10%, then freeze, and plan your response. No one can make optimal decisions in the heat of the moment.

The Best Time to Plan is Now

Think about your response plan before being hacked. Encode processes as much as possible and practice with your team so that you won’t be caught off guard during an impact. In the age of AI, this means having skills and algorithms capable of quickly presenting a large volume of information and sharing it in summary and long form with your core circle.

You don’t need perfection, but you must survive. No system is impervious from day one; through repeated iterations, you will become anti-fragile by learning from the lessons.

No evidence of being hacked does not equate to you not being hacked. The greatest comfort zone often represents the greatest danger zone.

Preventive Measures

Smart Contract Design

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

This is the FREI-PI (Function Requirements, Effects, Interactions, Protocol Invariants) model: at the end of every value-affecting function, re-validate the crown invariants that the function promises to maintain. Many drain attacks through CEI (Checks-Effects-Interactions) (flash loan sandwiches, oracle-assisted liquidation grief, cross-function solvency draining) can be captured by checks on the invariants at the end of the function.

Good Testing

Stateful fuzzing generates random call sequences that target the full public surface of the protocol and asserts invariants at each step. Most vulnerabilities in production environments are from multiple transactions, and stateful fuzzing is nearly the only reliable way to discover these paths before attackers do.

Use invariant testing to assert that properties hold across all call sequences generated by the fuzzer. Supplement with formal verification, which can prove that properties hold across all reachable states. Your crown invariants should definitely undergo this process.

Oracles and Dependencies

Complexity is the enemy of security. Every external dependency expands the attack surface. If you design primitives, give users the choice of who and what to trust. If a dependency cannot be removed, diversify it so that no single point of failure can destroy your protocol.

Extend the audit scope to simulate ways in which oracles and dependencies might fail, and impose rate limits on the potential catastrophic impacts if they fail.

A recent example is the KelpDAO vulnerability: they inherited the LayerZero default requiredDVNCount=1 configuration, which fell outside their audit scope. Ultimately, the compromised attack was on the off-chain infrastructure that was beyond the audit scope.

Surface Attacks

Most surface attacks in DeFi have already been enumerated. Examine each category one by one, ask whether it applies to your protocol, and then implement controls against that attack vector. Cultivate red team skills, have your AI agents proactively seek vulnerabilities in your protocol; this is already a basic requirement.

Have Native Rescue Capabilities

In voting-based governance, power is initially concentrated in the multi-signatures of the team, requiring time to diffuse. Even with widespread token distribution, delegation often tends to concentrate authority in a small number of wallets (sometimes even n=1). When these wallets are compromised, the game is over.

Deploy "guardian wallets" with extremely narrow authorizations: they can only pause the protocol and, under a >=4/7 threshold, can in extreme cases rotate compromised delegations to predefined replacement wallets. Guardians can never execute governance proposals.

This way, you have a rescue layer that can always restore governance stability without possessing power to overturn governance. The worst-case probability of losing >=4/7 guardians is minimal (given holder diversity), and once governance matures and decentralizes, this layer can be gradually phased out.

Wallet and Key Topology

Multi-signature wallets are a basic requirement, with a minimum of 4/7. No single person should control all 7 keys. Frequently rotate signers, and do so discreetly.

Keys should never interact with devices used for everyday tasks. If you use signing devices to browse the internet, check emails, or open Slack, consider that signer compromised.

Have multiple multi-signs, each with different purposes. Assume at least one complete multi-sign will be compromised, and plan from there. No single individual should have enough control to compromise the protocol, even in extreme scenarios (kidnapping, torture, etc.).

Consider Bounties

If you have the resources, setting a high-value bounty relative to the protocol TVL is very worthwhile; even if you are a relatively smaller protocol, the bug bounty should be as generous as possible (for instance, a minimum of 7-8 digits).

If you are facing an attack from a national actor, they may not negotiate, but you can still participate in "white hat safe harbor" programs, allowing white hats to act on your behalf to protect funds and take a percentage of the bounty amount as a fee (which is effectively a bounty paid by depositors).

Find Good Auditors

I’ve written before that as large language models become smarter, the marginal value of hiring auditors will drop. I still stand by that viewpoint, but my perspective has shifted somewhat.

First, good auditors will be ahead of the curve. If you are doing something novel, your code and its vulnerabilities may not be in the training data, and simply increasing the number of tokens has not proven effective in discovering new types of vulnerabilities. You don’t want to be the first sample point of a unique vulnerability.

Secondly, an underrated benefit is this: hiring auditors is essentially using their reputation as collateral. If they sign off and you get hacked, they have strong incentives to help out. Building relationships with those whose profession is security is a massive advantage.

Practice Operational Security

View operational security as a success metric. Conduct phishing drills; hire (trusted) red teams to attempt social engineering attacks on the team. Prepare backup hardware wallets and devices to swap out the entire multi-sign if needed. You don’t want to be rushing to purchase these things on D-day.

Mitigation Measures

Your Exit Path is the Loss Limit

The capped size of any path that moves value out of the protocol is the maximum theoretical loss when that path is exploited by a vulnerability. In simple terms: a mint function without a per-block cap gives an open-ended blank check for any infinite minting vulnerability. A redemption function without a weekly cap gives an open-ended blank check for any asset balance damage.

Carefully consider the specific numerical values for your exit paths. This number needs to balance between the maximum damage you are willing to endure and the most extreme UX demands of the users. If something goes wrong, this is what will save you from complete destruction.

Whitelisting (and Blacklisting)

Most protocols have lists of whom can be called, traded, or received, alongside lists of what users absolutely cannot do. Even if implicit, these are trust boundaries that should be formalized.

Formalizing them allows you to set two-stage setters, creating meaningful frictions. Attackers must first be added to the whitelist (and/or removed from the blacklist) before they can act. Having both means that when an attacker stealthily introduces a new vector, they must breach both processes simultaneously: the market must be allowed (integrated/launched), and that action cannot be prohibited (security review).

Recapture

Algorithmic Monitoring

If no one is monitoring, the kill switch is useless. Off-chain monitors should continuously track invariants and algorithmically escalate alerts upon issues arising. The ultimate path should lead to human hands of guardian multisigs, providing enough context for them to make decisions within minutes.

Stop to Recalibrate

If you’ve been hit, you should stop the bleeding first, rather than making decisions during the countdown. For protocols, this is the kill switch (which should also be reflected in the UI): a button that can pause all value-moving paths in one transaction. Prepare a "pause everything" auxiliary script that enumerates all pausable components and atomically pauses them.

Only governance can lift the pause, therefore the kill switch cannot pause the governance contract itself. If the guardian layer can pause the governance contract, the compromised guardian layer can permanently deadlock the recovery process.

Activate Your War Room

Freeze, stop the bleeding, and then pull all the people you trust (your small circle, predetermined) into a communication channel. You want the surface to be small to prevent information from leaking to attackers, the public, or malicious arbitragers.

Role-play for the roles needed by the team: one for decision-making; one as an operator skilled in executing defense scripts and pause operations; one who reconstructs vulnerabilities and identifies root causes; one for communicating with key parties; and one to document observations, events, and timelines of decisions.

When everyone knows their role and has rehearsed, you can react according to the process instead of scrambling at the worst moment.

Consider Chain Reactions

Assume that your attacker is highly skilled. The first vulnerability may be a bait, or a seed for a subsequent attack. The attack might trigger you to do something completely wrong, thereby triggering the actual vulnerability.

The pause must be well thought out, completely controllable, and not exploitable in itself. The pause should be a full protocol freeze: you don’t want to be tricked into pausing one component while inadvertently opening another. Once you identify the root cause and attack vector, explore adjacent exposed surfaces and chain reactions, and fix all at once.

Rotate Pre-committed Successors

Only knowing successors in advance makes rotation safe. I like the idea of a pre-committed successor registry: it makes it harder for attackers to replace healthy guardian/governance wallets with compromised ones. This aligns with the "whitelist/blacklist" concept in mitigation measures.

Register a successor address for each important role. The emergency layer can only execute the rotation primitive of "replace role X with its successor." This also allows you to assess successors during peacetime: take your time, do due diligence, and meet with those who make requests.

Test Carefully Before Upgrades

Once you’ve identified the root cause and scope of impact, you should release an upgrade. This may be the most dangerous code you will deploy: written under pressure, targeted at attackers who have already proven themselves capable of understanding your protocol and finding vulnerabilities.

Delay deployment without sufficient testing. If there's no time for an audit, rely on white hat relationships, or set up a 48-hour contest before deployment to obtain fresh adversarial review.

Recovery

Act Quickly

Stolen funds have a half-life; once a vulnerability goes live, they quickly enter laundering pipelines. Prepare in advance with on-chain analytics providers like Chainalysis to tag attacker address clusters in real time, and notify exchanges to tag and trace as they cross chains.

Have a pre-prepared list of centralized exchange compliance departments, cross-chain bridge administrators, custodian administrators, and other third-party entities with administrative authority to freeze cross-chain messages or specific in-transit deposits.

Negotiate

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

If you face a national actor, your luck might be poor, but you might face less seasoned attackers who have merely found a way to exploit you and want to escape at a lower cost.

Make sure to have legal counsel present before doing so.

Conclusion

Hacking incidents will not stop, and as AI becomes smarter, attacks will only increase. Simply making defenders "sharper" is not enough. We need to use the same tools as attackers to conduct red team testing on our protocols, continuously monitor, and impose hard limits on damage so that we can survive the worst-case scenarios.