Wallet Drain Playbook: Prevention + Incident Response Checklist

What Makes Wallet Drains Hard to Handle Well?

Wallet drains are difficult because teams often detect the visible transfer after the real security failure already happened. The actual failure might have been an approval granted days earlier, a risky signature accepted under pressure, an unbounded session, or a compromised frontend that quietly changed the trust context around a signing event.

That is why this page exists as the response-oriented companion to the wallet threat model. The threat model explains the loss classes. This playbook explains how to contain them once the situation becomes active.

What Should Teams Do in the First Hours of a Wallet Drain?

What Must Happen in the First 15 Minutes?

The first response window is not about perfect forensic certainty. It is about reducing attacker optionality. Teams should confirm the event, define the most likely path, and narrow the number of trust lanes still capable of moving assets.

• Confirm the incident with transaction evidence and impacted wallet scope.
• Classify whether the path is approval-based, key compromise, session abuse, or frontend compromise.
• Move coordination into one incident channel with one owner.
• Preserve evidence before cleanup steps destroy useful context.

If the incident path is approval-driven, the next operational step usually depends on the allowance revoke workflow. If the issue is live session trust, the more relevant follow-up is WalletConnect session hijacking defense.

What Prevention Work Makes This Playbook Easier to Run?

Incident response gets easier when the system already has boundaries. Teams should reduce authorization surface before the incident by limiting hot wallet use, separating operational roles, hardening signing environments, and monitoring risky permissions as first-class security state.

• Reduce hot-wallet exposure wherever possible.
• Train signers to treat permissions and sessions as live risk, not passive metadata.
• Protect frontend delivery paths that can influence user authorization behavior.
• Maintain response owners and a written runbook before incidents happen.

Which Containment Actions Should Happen Before Broad User Messaging?

Teams should not let public urgency outrun technical containment. Before broad messaging expands, responders should confirm which wallets are exposed, whether approvals or sessions remain active, whether frontend distribution is still trustworthy, and whether treasury or protocol-linked signers could inherit the same failure path.

• Verify whether the incident is isolated to one wallet class or reflects a wider trust failure.
• Contain active approval, session, or signer lanes before publishing optimistic recovery language.
• Separate user guidance for retail wallets from responder guidance for treasury or protocol signers.
• Keep one incident owner responsible for message checkpoints and containment status.

Which Early Signals Should Teams Treat as Serious?

The earliest useful signal is often not the transfer itself. It is the authorization behavior that makes the transfer possible. Teams should monitor for a small set of high-signal patterns and connect them directly to responder actions.

{
  "incident": "wallet-drain",
  "priority": "critical",
  "signals": ["unknown_spender", "permit2_change", "multi_token_sweep"],
  "next_action": "trigger_containment_runbook"
}

What Should a Simple Internal Runbook Template Include?

The best runbooks are operationally boring. They reduce ambiguity. They define owners, status, hypotheses, and the next checkpoint. That way the team does not waste the first 10 minutes inventing structure while funds are moving.

• Incident name and UTC timestamp.
• Incident lead and backup owner.
• Likely path: approval, key, session, or frontend compromise.
• Immediate actions taken and verification notes.
• Next communication checkpoint.

A good runbook should also define when the incident escalates from wallet cleanup to broader platform investigation, especially if frontend trust, session infrastructure, or multisig signer policy may be affected.

Frequently Asked Questions

What should teams do in the first 15 minutes of a wallet drain?

Confirm the event, classify the path, freeze further risky actions, and move communications into a single incident lane.

What is the most common wallet drain mistake?

Treating wallet drains as one generic problem instead of distinguishing approvals, key compromise, session abuse, and frontend compromise.