Wallet Security
Wallet Drain Response Checklist
A printable wallet drain response checklist gives the team a single sheet to contain an active drain, revoke the approvals and sessions that can still move value, preserve evidence, and restore confidence. Print it before the incident so the first 15 minutes are structure, not improvisation.
Direct answer
What the wallet drain response checklist includes
A printable wallet drain response checklist gives the team a single sheet to contain an active drain, revoke the approvals and sessions that can still move value, preserve evidence, and restore confidence.
Cyproli recommends printing it before the incident so the first 15 minutes are structure, not improvisation.
Cyproli recommends starting with the wallet drain playbook so the checklist is backed by the full response sequence.
Download / print
Within this package
Printable checklist
Wallet Drain Response Checklist
Work top to bottom. Every box is a pass/fail gate; a blank box means the response is not ready for the next stage.
| Done | Phase | Check | Owner |
|---|---|---|---|
| Contain | Confirmed the drain with on-chain evidence and named the affected wallet scope | Security lead | |
| Contain | Classified the path: approval-based, key compromise, session abuse, or frontend compromise | Security lead | |
| Contain | Moved coordination into a single incident channel with one owner | Incident commander | |
| Contain | Froze risky sessions and restricted further authorization to reduce attacker optionality | Wallet ops | |
| Revoke | Revoked the approval the drain used as the first revocation | Wallet ops | |
| Revoke | Swept for unbounded approvals, Permit2 allowances, and delegated spenders on the affected wallet | Security + engineering | |
| Revoke | Revoked active sessions and paired apps, and inspected the connected app path | Wallet ops | |
| Preserve | Preserved transaction hashes, timestamps, approvals, and session activity before any cleanup | Security + engineering | |
| Assess | Confirmed no active approval or session can still move value from the affected wallet | Security lead | |
| Recover | Rotated exposed keys, sessions, and signer authority with a separated recovery lane | Security + engineering | |
| Recover | Validated that the frontend and monitoring match the verified build before reopening | Engineering lead | |
| Harden | Documented the timeline and scheduled the postmortem with owners for each gap | Security + product |
Why Print a Wallet Drain Response Checklist at All?
Wallet drains are rarely one bug. They are usually a fast chain of small failures across approvals, signatures, sessions, and frontend trust, and the response is equally multi-lane. A printable checklist turns the response from improvisation into a deterministic sequence: contain, revoke, preserve, assess, recover. The first 15 minutes are where teams lose the most optionality, and that window is exactly when a checklist matters most.
This checklist is the operational companion to the wallet drain playbook, which explains the reasoning behind each lane. When the drain is approval-driven, the revocation step runs through the allowance revoke workflow; when it is session-driven, the WalletConnect session hijacking defense covers the connected-app path.
Which Revocation Checks Are Easy to Get Wrong?
The obvious revocation is the spender the drain used, but stopping there leaves the same wallet exposed through Permit2 allowances, delegated spenders, and live sessions. A wallet drain response checklist should force the sweep, not just the first revoke. Skipping the sweep is how a team stops one drain and then watches a second one from the same wallet.
| Check | Why it is skipped | Failure it prevents |
|---|---|---|
| Sweep for unbounded approvals | The visible spender seems like the only lane | Second drain from a hidden allowance |
| Revoke Permit2 allowances | Permit2 is an invisible aggregation layer | Multi-asset exposure survives the first revoke |
| Revoke active sessions | Session activity is treated as passive metadata | Paired app keeps signing on the same wallet |
| Preserve evidence before cleanup | Cleanup feels more urgent than logging | No recovery basis or postmortem context |
How Does This Checklist Map to the Wallet Playbook?
The checklist compresses the wallet drain playbook timeline into pass/fail gates. The containment phase maps to the playbook's first 15 minutes, the revoke phase to the approval and session lanes, and the recover phase to the session revocation strategy and the access revocation trigger framework. For prevention between incidents, the token approval exploit prevention page explains why these approvals became a risk in the first place.
{
"checklist": "wallet-drain-response",
"phases": ["contain", "revoke", "preserve", "assess", "recover", "harden"],
"gates": 12,
"next_action": "print-and-run-in-the-first-15-minutes"
}FAQ
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 coordination into a single incident lane.
Which permission should be revoked first in a drain?
Revoke the approvals and sessions that can still move value. Start with the spender the drain used, then sweep for unbounded approvals and active sessions on the affected wallet.