TL;DR

In 2024, crypto platforms lost about $2.2B to hacks across 303 incidents, which works out to almost one major incident every day.
The first 5 minutes determine whether you contain the blast radius or fund an attacker’s exit liquidity. You need a clear decision path for pausing, scoping, and freezing flows.
Effective response today includes on-chain evidence capture, coordinated communication, and fast engagement with exchanges, stablecoin issuers, and bridge operators; in 2024, one incident response firm helped freeze over $112M in stolen funds while Tether and Circle froze over $553M in USDT/USDC.
A good postmortem template is how you make sure you don’t get exploited twice by the same mistake.

Why you need a 30-minute plan at all

The Web3 security data for the last few years is blunt. CertiK’s 2024 Hack3d report recorded about $2.36B lost across 760 on-chain incidents. Chainalysis counted around $2.2B stolen from crypto platforms in the same year, a 21% increase over 2023, with incidents rising from 282 to 303. Beosin’s global Web3 report put total 2024 losses, including phishing and rug pulls, at roughly $2.51B, with 131 major attacks alone causing about $1.79B in damage.

At the same time, defenders are getting better at reacting. SlowMist reports that in 2024 they and their partners helped freeze over $112M in stolen funds, while Tether froze about $540M in USDT and Circle froze over $13M in USDC in response to compromise events. Those numbers tell a simple story: if you act quickly and know who to call, you can sometimes turn an eight-figure disaster into a survivable incident.

The teams that do well aren’t perfect. They just have a clear playbook for the first 30 minutes.

Minutes 0–5: Freeze scope and stop the bleeding.

The very first decision is simple: “Is this an incident or not?” That sounds trivial until you have three conflicting pings in Slack, half the team is asleep, and the market is moving.

You need three things already agreed upon before anything happens: who is allowed to declare an incident, what “incident” means for your protocol, and what authority that declaration unlocks. If someone sees anomalous transfers, unexpected minting, or obviously malicious contract interaction, they should be able to hit a big red button that does not require a committee meeting.

In the first five minutes, your focus is not to fully understand the exploit. It is to contain it. For a protocol with a pause mechanism, that means deciding whether to pause. For a more complex system, that may mean disabling specific entry points, raising fees to discourage activity, or temporarily limiting certain flows.

On-chain, this often boils down to calling a small set of emergency functions.

A very simple example is a pausable token or core contract:

contract CoreProtocol is Ownable {
    bool public paused;

    modifier whenNotPaused() {
        require(!paused, "paused");
        _;
    }

    function pause() external onlyOwner {
        paused = true;
    }

    function unpause() external onlyOwner {
        paused = false;
    }

    function sensitiveAction(...) external whenNotPaused {
        // core protocol logic
    }
}

In a mature setup, onlyOwner is not a single EOA; it is a constrained multisig or governance mechanism with clear emergency rules. The important part is that in minute three of a live exploit, someone with the agreed authority can call pause() without having to ask whether pausing is “good optics”.

During these first minutes, you are also scoping which contracts are affected, which networks, which pools or vaults. Even a rough classification-“core “lending paused, staking still safe”-helps you avoid making the incident bigger by reacting blindly.

Minutes 5–15: Capture evidence and communicate

Once the bleeding is slowed, the next risk is losing evidence or losing trust.

On-chain, every transaction is permanent, but context is not. Chat logs, CI pipelines, access keys, node logs, and internal dashboards can all change as people scramble. The quiet task in this window is to preserve a snapshot of reality before too many hands touch it.

A minimal evidence step can be scripted. For example, a simple internal tool that tags an incident, captures key views, and posts into a dedicated channel:

// pseudo-code
async function openIncident(incidentId: string, txHash: string) {
  const tx = await provider.getTransaction(txHash);
  const block = await provider.getBlock(tx.blockNumber);

  const snapshot = {
    incidentId,
    txHash,
    blockNumber: tx.blockNumber,
    timestamp: block.timestamp,
    affectedContracts: [CORE_ADDR, VAULT_ADDR],
  };

  await saveToStorage(snapshot);
  await postToWarRoom(snapshot);
}

At the same time, communication has to start. External silence for an hour while wallets are drained is catastrophic for trust. That does not mean you need a full explanation; it means you need a brief, accurate statement: that you are aware, that you have taken specific immediate actions, and that you will share more when facts are confirmed.

Internally, you should have a single incident channel where engineers, leadership, and communications people coordinate. CertiK’s Q1 2024 data shows that private key compromises alone accounted for nearly $239M in losses across just 26 incidents, almost half of all losses that quarter. Many of those situations spiraled not because the exploit was especially novel, but because coordination was slow.

A simple rule helps: engineers discuss facts and hypotheses in the war room; only one designated person talks to the public.

Minutes 15–30: Coordinate with the rest of the ecosystem

In Web3, your incident is rarely just your problem. Funds move through bridges, centralized exchanges, stablecoin issuers, and other protocols. That is bad news if you are slow and excellent news if you are ready.

The SlowMist report mentioned earlier notes that in 2024, fund freezes involved not just security firms but also Tether and Circle, which together froze over $553M worth of USDT and USDC in response to compromise events. That level of recovery only happens when incident data reaches the right counterparties fast, with enough context for them to act.

By minute 30, your goal is to have:

A list of attacker addresses and key transaction hashes
A rough amount of value at risk and already moved
A clear contact route to major exchanges, stablecoin issuers, and bridge operators your users rely on

A lightweight playbook here is to maintain an internal run sheet with emergency contacts and required fields: how to format an abuse report to an exchange, which information Tether or Circle typically require to consider freezing funds, which bridges you integrate with and how to reach their incident teams.

You will not always succeed in recovering funds, but the difference between acting in minute 25 and hour three is measurable when you look at ecosystem-wide freezing and clawback stats.

After the first half hour, the postmortem you actually learn from

When the immediate crisis is stabilized, the real work starts. The postmortem is where you decide whether this exploit was a one-off or the beginning of a pattern.

A useful template is simple and ruthless:

What exactly happened on-chain, from the attacker’s first interaction to the last?
Which assumptions in your design, tests, or monitoring did reality falsify?
What signals existed that this was possible, and why weren’t they acted on?
Which controls-technical, process, or organizational-would have prevented or reduced the impact?

You also need one more section that many teams skip: “How do we ensure we are never vulnerable to this class of issue again?” That might mean adding invariants to your tests, turning on a new type of alert, redesigning a privilege model, or changing how you handle secrets. It may also mean adjusting your incident contract with users: what you will disclose and how fast.

The numbers from 2024 and early 2025 show that while total losses remain high, the blast radius of some big incidents has been reduced by better response frameworks and faster ecosystem coordination. CertiK’s 2025 Hack3d update notes that after a brutal first quarter with about $1.67B lost, the next quarter saw a roughly 52% drop in value stolen, with improved on-chain monitoring and response cited as key factors. That is what “don’t get exploited twice” looks like at scale: learning, standardizing, and reacting faster each time.

References

CertiK — Hack3d 2024 Annual Report: $2.36B lost across 760 on-chain incidents.
Chainalysis — 2024 Crypto Hacking Report: about $2.2B stolen in 303 incidents, a 21% increase year-over-year.
Beosin — 2024 Global Web3 Security Report: $2.513B total losses; 131 major attacks causing $1.792B.
SlowMist — 2024 Blockchain Security and AML Report: over $112M Loss

Where Exploitless fits into this

At Exploitless, we focus on all parts of security. That means designing the incident response runbook before anything goes wrong: defining who can pause, how anomalies are detected, how evidence is captured, and how to contact ecosystem partners in the first thirty minutes.

We also work with teams post-incident, turning painful exploits into structural improvements. That can be a redesigned privilege model, new invariants and fuzzing around the exploited logic, or a full runtime security review that connects design, code, and operations.

If you are running a protocol or integration that holds real value and your current incident “plan” is just a hope that nothing goes wrong, it is a good time to turn that hope into a concrete 30-minute playbook. Exploitless exists to help you do exactly that.

Learn More at Exploitless

Incident Response for Web3 Teams: The 30-Minute Playbook