A crypto incident response plan is the documented, tested sequence an institution follows to detect, contain, and recover from an on-chain incident such as a wallet drain, a compromised signer, or key loss. The plans that fail have a common flaw: they stop at detection. An alert that arrives after the assets have moved is a post-mortem, not a response. For digital assets, response has to act inside the settlement window, not describe what happened after it closed.

Detection without response only produces post-mortems. This page walks the full detection-to-recovery lifecycle for on-chain incidents, explains why alerting-only tooling structurally cannot contain a drain, and shows how automated response and recovery, both set up in advance, act before assets leave the wallet. It closes with a direct answer to the question every operator eventually asks under pressure: how do you stop a wallet drain that is already in progress.

What is a crypto incident response plan?

A crypto incident response plan is a defined set of procedures for identifying, containing, eradicating, and recovering from security incidents that affect digital assets and the systems that control them. It adapts the classic incident response lifecycle to the reality of on-chain settlement: irreversible transactions, bearer assets, and a containment window measured in seconds rather than hours.

Traditional IT incident response has room to breathe. When a server is compromised, responders can isolate it, take an image, and investigate before restoring, because the damage is usually contained and reversible. Digital assets remove that slack. Once an attacker controls a key and broadcasts a transfer, the loss is final at block confirmation. A plan built on the traditional cadence of detect, escalate, convene, decide, act will finish its first two steps after the assets are already gone. The plan has to compress the whole lifecycle into the window before broadcast, which for most of it means removing the human from the critical path.

The detection-to-recovery lifecycle for on-chain incidents

An effective plan moves through the same phases as any incident response framework, but each phase is re-timed for on-chain reality. The phases below are ordered as they occur during an incident.

1. Detect. Continuously monitor wallet activity and the mempool for anomalous or unauthorized transactions. On-chain, detection cannot wait for a transaction to confirm, because confirmation is the loss. Detection has to happen at the point a malicious transaction is proposed or broadcast, not after it settles.
2. Triage. Classify the event: is this an authorized movement, a policy violation, or an active drain. For time-critical events this classification has to be automated, because a human triage step reintroduces the delay that lets the attacker win.
3. Contain. Stop the assets from leaving institutional control. This is the phase alerting-only tools skip entirely. Containment means acting on the transaction before it settles, or moving the assets to safety before the attacker can, not sending a notification.
4. Recover. Move the assets to a pre-approved, safe location and restore normal operations. For digital assets this means sweeping assets to a pre-approved vault using pre-signed transactions, without depending on the compromised key. See digital asset recovery.
5. Learn. After the assets are safe, investigate root cause, close the failure mode, and update the plan. This is the only phase where the traditional, unhurried cadence is appropriate, because it happens after containment, not instead of it.

The critical insight is that steps 1 through 4 have to happen inside the settlement window. Any plan that puts a human decision between detection and containment has effectively deleted the containment step, because the human cannot read, decide, and act faster than an automated attacker can broadcast.

Why do alerts without actions fail?

Alerting-only tooling fails because it separates knowing from doing. It tells you an incident is happening, but it does not stop it. By the time an analyst reads the alert, opens the console, confirms the event, and initiates a response, the on-chain transaction has confirmed and the assets are gone. The alert is accurate and useless at the same time.

The failure is structural, not a matter of tuning. Consider the timeline of an automated wallet drain against an alerting-only stack:

• Second 0: the malicious transaction hits the mempool, and monitoring detects it.
• Seconds later: an alert is generated and routed to on-call.
• Seconds to minutes: a human sees and opens the alert, depending on attention and time of day.
• More minutes: the human confirms it is a real incident through manual investigation.
• Too late: the human initiates a manual response, if a response path even exists.
• Often within one block: the attacker's transaction confirms and the assets leave the wallet.

Every human step in that sequence is slower than the block. The alerting-only model assumes a response window that on-chain settlement does not grant. This is why "we have monitoring" is a detection claim, not a response claim, and why a plan that ends at detection generates post-mortems rather than saved assets. The related failure modes are catalogued in digital asset failure modes.

What is automated crypto threat response?

Automated crypto threat response is the closing of the gap between detection and containment by having a system act on a detected threat directly, without waiting for a human decision. Instead of routing an alert to a person, it executes a pre-authorized containment action in the same window the threat appears in.

This is what makes response viable against on-chain attacks. The action is decided in advance, encoded as policy, and triggered automatically when detection fires, so the sequence of detect, triage, and contain runs in machine time rather than human time. Circuit Response provides exactly this: it monitors the mempool and contains attacks in under 2 seconds, acting before assets leave the wallet. The human role moves from being in the critical path during the incident to defining the policy before it and reviewing after it.

Automated response does not mean uncontrolled response. The containment actions and destinations are pre-approved under governance: assets can only be swept to vaults the institution designated in advance, and the triggers are defined by the institution's own policy. Automation compresses the timeline; governance constrains the outcomes.

How automated response and recovery work together

Response and recovery are two functions, and a complete plan needs both. Response contains the threat in the moment. Recovery ensures that even in the worst case, where prevention and containment are bypassed, the assets can still be moved to safety without the compromised key. Recovery that does not rely on the private keys is what search terms call keyless recovery. Together, response and recovery cover the two functions a prevention-only stack leaves open. Circuit's third product, Key Backup, sits behind both as the trustless encrypted backstop for the key material itself, distinct from Response and Recovery and used when the wallet stack is what failed. For how this maps to the broader framework, see operational resilience for digital assets.

The mechanism that makes both possible is the pre-signed transaction. A pre-signed transaction is authorized in advance and refreshed as balances change, so a valid, current recovery transaction always exists and is ready to broadcast without any key access at the moment of the incident. This is the core of Automatic Asset Extraction (AAE), the technology that powers both Circuit products: pre-signed, continuously updated transactions sweep assets to pre-approved vaults when wallets are compromised or inaccessible, without requiring access to private keys.

The division of labor:

• Circuit Response handles the Respond function: mempool monitoring and automated containment in under 2 seconds, acting before assets leave the wallet.
• Circuit Recovery handles the Recover function: disaster recovery via pre-signed transactions, moving assets to a pre-approved vault even when the key is lost, stolen, or in an attacker's hands, without needing that key. See how recovery works without the keys.

Because both are set up in advance and neither depends on holding a key at incident time, they act inside the window that alerting-only tooling misses. Circuit is not a custodian and cannot access, use, or reconstruct your keys; it is the response and recovery layer that runs alongside custody.

How to stop a wallet drain in progress

To stop a wallet drain in progress, you need a pre-authorized, automated containment and recovery capability that is already in place before the drain starts, because there is no time to build or trigger a response manually once assets begin moving. In practice, that means one of two things is true at the moment of the drain: either an automated system contains the malicious transaction before it settles, or a pre-signed recovery transaction sweeps the remaining assets to a safe vault faster than the attacker can extract them.

If you have this capability set up in advance, the sequence is:

1. Detection fires automatically the moment the malicious transaction appears in the mempool or wallet activity deviates from policy.
2. Automated containment executes within the settlement window, acting on the threat before assets leave the wallet.
3. Recovery sweeps the remaining balance to a pre-approved vault using a current pre-signed transaction, without needing the compromised key.
4. Investigation and root-cause follow after the assets are safe.

If you do not have this capability set up in advance, the honest answer is that a drain already in progress usually cannot be stopped by manual action. By the time a person can react, the attacker's transaction has confirmed. There is no reliable way to reverse a confirmed on-chain transfer. This is why the meaningful decision about stopping a drain is made before the incident, when the automated response and pre-signed recovery paths are established, not during it. The window is too short to improvise. The related recovery mechanics are covered in digital asset recovery.

What incident response does not do

Precision about limits keeps the plan honest:

• It does not reverse confirmed transactions. Nothing does. Once an attacker's transfer confirms and the funds are off-ramped, they are gone. The entire value of response is acting inside the window before that point, which is why speed and setting up in advance are the whole game.
• Automated response does not replace prevention. Custody, MPC, and access controls remain the first line. Response and recovery are what you have when prevention is bypassed, not a substitute for it.
• Circuit does not hold keys or custody assets. It monitors, contains, and recovers. It is not custody, a wallet, or insurance. Circuit is backed by the Lloyd's Central Fund, and insurers offer premium discounts of up to 15%, but Circuit itself does not underwrite loss.
• Recovery destinations are constrained, not open-ended. Assets are swept only to vaults the institution pre-approved. Automation compresses the timeline; it does not hand an attacker or a misconfiguration a blank destination.

Frequently asked questions

What should a crypto incident response plan include?
It should cover the full lifecycle: automated detection of anomalous or malicious transactions, automated triage and containment inside the settlement window, recovery to a pre-approved vault without needing the compromised key, and post-incident learning. The defining feature is that detection is wired to action, not just to an alert queue.

Why do alert-only crypto monitoring tools fail during an attack?
Because they separate knowing from doing. On-chain settlement is often complete within one block, so by the time a human reads the alert, investigates, and tries to respond, the attacker's transaction has already confirmed. The alert is accurate but arrives after the assets are gone.

What is automated crypto threat response?
It is a system that acts on a detected threat directly, executing a pre-authorized containment action without waiting for a human decision. Circuit Response uses this model to monitor the mempool and contain attacks in under 2 seconds, before assets leave the wallet.

How do you stop a wallet drain in progress?
With a pre-authorized automated containment and recovery capability already in place. It contains the malicious transaction before it settles, or sweeps the remaining balance to a pre-approved vault using a pre-signed transaction, faster than the attacker can extract. Without a capability set up in advance, a drain in progress generally cannot be stopped by manual action.

Can Circuit recover assets after they have already been stolen?
No. Circuit acts inside the incident window, before or during the attack, to contain the threat and move assets to safety. It cannot reverse a transaction that has already confirmed and off-ramped. This is why the capability has to be set up in advance, before an incident, not deployed after one.