Introduction
After witnessing numerous DeFi protocol hack events, I have developed a fear of the "nation-state actor." They are highly skilled, well-resourced, and playing the long game; these supervillains focus on every nook and cranny of your protocol and infrastructure to find vulnerabilities, while the attention of ordinary protocol teams is divided among 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-value financial field) and have ample experience in thinking and planning emergency response strategies.
I genuinely believe that only the paranoid survive. No team sets out with the mindset of "I will take a carefree and perfunctory attitude towards security" from the start; however, hacks still occur. We need to do better.
AI Means This Time Is Really Different
Hacks are not uncommon, but the frequency is clearly increasing. The first quarter of 2026 was the quarter with the highest number of DeFi hacks on record, and the second quarter has just begun but is already poised to break the previous quarter's record.
My core assumption is: AI has significantly reduced the cost of finding vulnerabilities and greatly expanded the attack surface. It takes humans several weeks to comb through the configuration of a hundred protocols to find misconfigurations; whereas the latest base models can do so in just a few hours.
This should fundamentally change how we think about and respond to hacks. Older protocols that are used to the security measures before AI became powerful are increasingly at risk of being "0-day exploited."
Think in Surfaces and Layers
The attack surface of a hack can actually be categorized into three main areas: the protocol team, smart contracts and infrastructure, and user trust boundaries (i.e., DNS, social media, etc.).
Once these surfaces are identified, layer defenses on top:
· Prevention: Processes that, if strictly followed, can vastly reduce the probability of exploitation.
· Mitigation: When prevention fails, limit the extent of damage.
· Pause: No one can make the best decisions under immense pressure. Once an attack is confirmed, immediately activate the master kill switch. Freezing can halt further losses and buy thinking time...
· Recapture: If you lose control of a toxic or compromised component, abandon and replace it.
· Recovery: Regain what you lost. Plan ahead with partners who can freeze funds, reverse transactions, and assist in investigations.
Principles
These principles guide us on specific actions to take for each layer of defense.
Heavy Use of Cutting-Edge AI
Employ cutting-edge AI models to scan your codebase and configurations in bulk, hunt for vulnerabilities, and conduct red team testing across a broad surface: try to find vulnerabilities in the front end and see if they can reach the back end. Attackers do this. What you can find through defensive scans, their offensive scans found long ago.
Use tools like pashov, nemesis, as well as AI platforms like Cantina (Apex) and Zellic (V12) to swiftly scan codebases before full audits are submitted.
Time and Friction are Good Defenses
Add multi-step processes and time locks to any operation that could cause harm. You need enough time to intervene and freeze when anomalies are detected.
The reason against time locks and multi-step setups in the past was the friction it would bring to the protocol teams. Now, this shouldn't concern you too much: AI can effortlessly click through this friction in the background.
Invariants
Smart contracts can be defensively built by writing down immutable 'truths': if these truths are broken, the whole protocol logic collapses.
You usually have only a few invariants. Be judicious about elevating them to the code level; enforcing multiple invariants in every function can become unwieldy.
Power Balance
Many hacking attacks stem from compromised wallets. You need a setup where even if a multi-sig is breached, you can quickly contain the damage and bring the protocol back to a governable state.
This requires striking a balance between governance (which decides everything) and recovery (the ability to restore governability but not replace or overturn governance itself).
Something Will Always Go Wrong
Always assume from the outset: no matter how smart you are, you will be hacked. Your smart contract or dependencies might fail. You could fall victim to social engineering attacks, and new upgrades might introduce vulnerabilities you had not anticipated.
Once you start thinking this way, rate limiting damage and having protocol circuit breakers in place will be your best friends. Limit the damage to 5-10%, then freeze, and then map out your response plan. No one can make the best decisions in the heat of the moment.
The Best Time to Plan Is Now
Think about your response plan before a hack occurs. Encode processes as much as possible and practice with your team so you are not caught off guard when the shock hits. In the age of AI, this means having the skills and algorithms to present vast amounts of information as quickly as possible and sharing summaries and long-form with your inner circle.
You do not need perfection, but you must survive. No system is bulletproof from day one; through multiple iterations, you will become anti-fragile by learning from your mistakes.
The absence of evidence of being hacked does not mean you will not be hacked. The point of maximum comfort is often the point of maximum danger.
Preventive Measures
Smart Contract Design
Once immutables are determined, elevate them to runtime checks. Ponder carefully which immutables are actually worth enforcing.
This is the FREI-PI (Function Requirements, Effects, Interactions, Protocol Invariants) pattern: at the end of each function that touches value, revalidate the crown invariants that the function has committed to uphold. Many attacks like drain attacks through CEI (Checks-Effects-Interactions) (flash loan sandwich, oracle-assisted settlement grief, cross-function pay-out ability drain) can be captured by invariants checks at the end of functions.
Thorough Testing
Stateful fuzzing generates random call sequences against the full public surface of a protocol and asserts invariants at each step. Most vulnerabilities in production involve multi-transaction scenarios, and stateful fuzzing is almost the only reliable way to discover these paths before attackers.
Use invariant testing to assert that properties hold across all call sequences the fuzzer can generate. Complemented with formal verification, it can prove that properties hold across all reachable states. Your crown invariants should absolutely undergo this treatment.
Oracle and Dependencies
Complexity is the enemy of security. Every external dependency expands the attack surface. If you are designing primitives, empower users with the choice of who and what to trust. If dependencies cannot be removed, diversify them so that no single point of failure can break your protocol.
Extend the audit scope to simulate how oracles and dependencies can fail and impose rate limits on the severity of the catastrophes that could result from their failure.
A recent example is the KelpDAO vulnerability: they inherited the LayerZero default configuration of requiredDVNCount=1, which was outside their audit scope. The breach eventually occurred on off-chain infrastructure outside the audit scope.
Surface Attacks
Most surface attacks in DeFi have already been enumerated. Go through each category, ask if it applies to your protocol, and then implement controls against that attack vector. Cultivate red team skills to have your AI agent actively search for vulnerabilities in your protocol; this is already a basic requirement.
Possess Native Recovery Capabilities
In vote-based governance, power initially centralizes in the team's multisig, taking time to diffuse. Even with widespread token distribution, delegation often concentrates authority into a few wallets (sometimes even n=1). When these wallets are breached, the game is over.
Deploy "guardian wallets" with strictly scoped authorization: they can only pause the protocol and, at the>=4/7 threshold, may, in extreme cases, rotate damaged delegations to predefined replacement wallets. Guardians can never execute governance proposals.
This way, you have a rescue layer that can always restore governable stability without the power to overturn governance. The worst-case probability of losing>=4/7 guardians is very low (given holder diversity), and once governance is mature and diversified, this layer can be gradually phased out.
Wallet and Key Topology
A multi-signature wallet is a basic requirement, minimum 4/7. No single individual should control all 7 keys. Rotate signers frequently and do so stealthily.
Keys should never touch everyday devices. If you use a signing device to browse the internet, send emails, or open Slack, consider that signer compromised.
Have multiple multisigs, each with different purposes. Assume at least one full multisig will be compromised and plan from there. No one individual should have enough control to compromise the protocol, even under extreme duress (kidnapping, torture, etc.).
Consider Bounties
If you have the resources, setting a high-value bug bounty relative to the protocol TVL is very worthwhile; even if you are a relatively smaller protocol, bug bounties should be as generous as possible (e.g., a minimum of 7-8 figures).
If you are facing a nation-state actor attack, they may not negotiate, but you can still participate in a "white hat safe harbor" program, authorizing white hats to act on your behalf to secure funds and take a percentage of the bug bounty as a fee (effectively paid by the depositor).
Find a Good Auditor
I have written before that as large language models get smarter, the marginal value of hiring auditors will diminish. I still hold that view, but my perspective has shifted.
Firstly, a good auditor 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 merely increasing token amounts has not proven effective at discovering novel vulnerabilities. You do not want to be the first sample point for a unique vulnerability.
Secondly, an underrated benefit: hiring an auditor is a commitment backed by their reputation. If they sign off and you get attacked, they are highly incentivized to help. Building relationships with those whose profession is security is a massive advantage.
Practice Operational Security
Consider operational security a success metric. Conduct phishing exercises; hire (trusted) red teams to attempt social engineering attacks on the team. Have backup hardware wallets and devices ready to replace the entire multisig when needed. You do not want to scramble to buy these things on D-day.
Mitigation Measures
Your exit path is your loss limit
The maximum cap of any path that moves value out of the protocol is the maximum theoretical loss in case of path abuse. In simple terms: without a per-block limit on minting function, it's like giving a blank check to any infinite minting exploit. Without a weekly limit on the redeem function, it's like giving a blank check to any asset balance exploit.
Carefully consider a specific numerical value for your exit path. This number needs to strike a balance between the maximum loss you are willing to bear and the most extreme UX demand from users. In case of trouble, this is what can save you from total destruction.
Whitelist (and Blacklist)
Most protocols have a list of transactions, calls, or recipients that are allowed, as well as a list of things users absolutely must not do. Even if implicit, these are trust boundaries and should be formalized.
Formalizing them allows you to set up a two-step setter, creating meaningful friction. An attacker must first be added to the whitelist (and/or removed from the blacklist) before they can act. Having both means that when an attacker sneakily introduces a new vector, they must breach both processes simultaneously: they must be allowed on the market (integration/listing) and the action cannot be prohibited (security review).
Recovery
Algorithmic Monitoring
If no one is watching, the kill switch is useless. Off-chain monitors should continuously watch for invariants and algorithmically trigger alarms in case of issues. The final path should lead to a human hand holding the guardian multisig, providing enough context for them to make a decision within minutes.
Pause and Reassess
If you've been compromised, you need to stop the bleeding first, not make decisions under duress. For the protocol, this is the kill switch (also reflected on the UI): a button to pause all value-transfer paths in a transaction. Have a "pause-all" auxiliary script ready, enumerating all pausable components and pausing them atomically.
Only governance can unpause, so the kill switch should not be able to pause the governance contract itself. If the guardian layer can pause the governance contract, a breached guardian layer could permanently deadlock the recovery process.
Activate Your War Room
Freeze, stop the bleeding, and then bring all your trusted individuals (a small circle, pre-agreed upon) into a communication channel. You want to keep the circle small to prevent information leakage to attackers, the public, or malicious arbitrageurs.
Role-play the roles your team needs: a decision-maker; an operator skilled in executing defense scripts and pausing operations; a person to refactor the exploit and identify the root cause; a point of contact with key parties; a person to log observations, events, and decision timelines.
When everyone knows their role and has practiced, you can respond by procedure rather than scrambling at the worst moment.
Consider Chain Reactions
Assume your attacker is highly sophisticated. The initial exploit may be a decoy, a seed for a later attack. The attack could be about luring you into doing something completely wrong, triggering the real exploit.
The pause must be fully researched, entirely controllable, and non-exploitable itself. The pause should be a full protocol freeze: you don’t want to be lured into pausing one component only to open up another. Once you find the root cause and attack vector, explore the adjacent exposed surface and chain reactions, fixing all at once.
Rotate Pre-Committed Successors
Rotation is only secure when you know the successor ahead of time. I like the idea of a pre-committed successor registry: it makes it harder for an attacker to swap out a healthy guardian/governance wallet for a compromised one. This aligns with the concept of “whitelisting / blacklisting” in mitigations as well.
Register a successor address for each critical role. The only rotation primitive the emergency layer can perform is “replace role X with its successor.” This also lets you assess successors in peacetime: take it slow, do due diligence, fly them out and meet the requestor.
Exercise Caution with Upgrades
Once you know the root cause and scope, you need to ship an upgrade. This may be the riskiest code you're about to deploy: written under duress, targeted by attackers who have proven they know enough about your protocol and found vulnerabilities.
Delay the release without sufficient testing. If there's no time for an audit, rely on white-hat relationships, or set up a 48-hour race pre-deployment for a fresh adversarial review.
Recovery
Act Quickly
Stolen funds have a half-life; once the exploit lands, they rapidly enter the laundering pipeline. Be prepared ahead with on-chain analysis providers like Chainalysis to tag attacker address clusters in real-time and notify exchanges to tag and track as they jump chains.
Prep a list ahead of centralized exchange compliance teams, cross-chain bridge admins, custodian admins, and other authorized parties who can freeze cross-chain messages or specific incoming deposits.
Negotiation
Yes, it's very painful, but you should still try to engage with the attacker. Many things in life can be resolved through negotiation. Offer a time-bound bug bounty and publicly state that no legal action will be taken if the full amount is returned before the deadline.
If you are dealing with a nation-state actor, you may be out of luck, but you may be dealing with a less sophisticated attacker who just stumbled upon your vulnerability and is looking to exit at a lower cost.
Be sure to have legal counsel present before doing so.
Conclusion
Hacking attacks will not stop, and as AI becomes smarter, attacks will only increase. Simply making the defenders "more agile" is not enough. We need to use the same tools the attackers use, conduct red team testing on our protocols, maintain continuous monitoring, and have hard limits on damages so we can survive the worst-case scenario.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
