SAYLOR The result you are building
A contained wallet incident: remaining assets moved using a clean device/wallet path when safe, malicious approvals/delegates/sessions addressed where applicable, evidence preserved, exchange/provider reports filed, and the compromised trust boundary permanently retired.
Use this guide when: unexpected transfers, signing prompts, seed exposure, a malicious dApp, browser compromise, or a wallet drain are suspected and you need a safe evidence-and-recovery sequence.
Do not use it as a substitute for: entering the compromised seed into any website, bot, support DM, or "recovery" tool — never do this — or sending more gas to a swept wallet without understanding active sweeper risk.
Before you change anything, collect: chain/public addresses, transaction signatures/times, and assets affected; what was exposed (seed/private key, signer session, approval/delegate, device/browser, or unknown); remaining assets/positions/stakes/NFTs and any time-sensitive controls; a clean device/profile and a new wallet generated independently.
Stop before proceeding: if the seed/private key may be exposed, treat the wallet as permanently compromised. Never reuse it for custody even if assets are later recovered or permissions appear revoked.
Understand the system before fixing it
- Containment outranks attribution. Move safe remaining value and stop signing before spending time identifying the attacker.
- Revocation cannot repair a leaked seed. Approvals/delegates can be revoked, but anyone holding the private key retains full signing authority regardless.
- Every new signature during recovery is a risk decision. Malicious tokens/NFTs/sites and a still-compromised device can steal again mid-recovery.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Seed/private key exposed | Key compromise | Assume full authority loss | Create a clean wallet, move/recover assets via trusted paths, retire the old wallet |
| Only one token approval/delegate | Permission compromise | Inspect on-chain approvals/delegates and the transaction | Revoke from a trusted interface, but still investigate device/session for key compromise |
| Assets transfer immediately after gas | Sweeper | Observe attacker automation and asset-claim dependencies | Don't feed gas blindly; consider a specialist/private-bundle option if legitimate and understood |
| Unknown NFT/link appears | Spam/phishing | Do not interact; inspect metadata isolated | Hide/burn only via a trusted wallet feature, and understand the transaction first |
Step-by-step procedure
01. Stop interaction and preserve evidence. Disconnect the affected wallet/sites, close suspicious browser sessions, and preserve public addresses/signatures/screenshots/times/domains/extensions/device state — without ever exposing the seed. Classify seed/key compromise vs approval/session vs unknown, then switch to a clean device/profile for recovery.
02. Create a clean trust boundary. A new wallet generated on the same compromised device or from the same seed is not new trust. Generate a new wallet with verified software/hardware, a new seed offline, secure backups, and low test funding, verifying the address independently. No secret should ever cross chat, cloud clipboard, or a compromised browser.
03. Inventory remaining positions. Wallet UIs can omit stakes/LPs/NFTs/token accounts — use read-only explorers/RPC to list balances, positions, stakes, authorities, delegates, and pending actions. Prioritize liquid, high-value, recoverable assets and don't interact with spam assets.
04. Move/revoke with minimum signing. Every transaction risks alerting a sweeper or executing a malicious instruction. For key compromise, transfer standard assets/positions using official/trusted program interfaces to verified destinations. For a limited permission issue, revoke the exact approval/delegate and move critical assets if warranted. Confirm every signature and destination on-chain, and stop on any unknown instruction or program.
05. Secure accounts and report. Wallet compromise can extend to email/exchange/browser/cloud. Rotate related passwords/API keys/sessions, remove malicious extensions, scan/reinstall as appropriate, and notify exchanges/providers/law enforcement with signatures — through official support channels only, and ignore anyone offering "recovery" services unsolicited.
06. Reconcile and retire. Compare pre/post assets and transactions, record loss/cost, keep watching the old wallet, revoke/release any remaining recoverable permissions, mark the old address compromised, and never fund or store value there again.
Worked example
Starting problem: after connecting to an airdrop site, tokens leave the wallet and any added SOL disappears within seconds.
Evidence collected: unauthorized transactions use valid wallet signatures after the seed was entered into the site; small SOL deposits are swept within seconds; several LP/NFT positions remain; the browser still has a suspicious extension installed.
Decision: this is full key compromise with an automated sweeper — revoking one site's access will not restore control.
Actions taken: stopped funding and preserved signature/domain evidence; created a new wallet on a clean device; planned official position recovery with specialist help where a gas race was required; rotated related accounts and retired the compromised seed/address.
Proof of completion: all safely recoverable assets are confirmed in the new wallet; the old address is monitored and marked compromised; no new value is sent there; the incident/audit record is complete.
Why this matters: the correct end result is a genuinely new trust boundary — not just making the old wallet appear quiet.
Verify, recover, and hand off
An incident is complete only when: the compromise class and evidence are documented; the new wallet/seed/device path is independent and verified; remaining assets/positions and every recovery signature reconcile; related account sessions/keys are rotated and malicious access removed; reports/case IDs and a loss record are preserved; and the old seed/address is permanently retired.
Blockchain transfers are usually irreversible, so rollback may not exist — if a recovery transaction is uncertain, stop before signing and seek vetted specialist or official support instead. If support asks for the seed, that's a scam — official support never needs it. If gas keeps getting swept, stop funding it and use a vetted recovery strategy or specialist instead. If a new wallet also loses funds, the device, browser, cloud backup, or secret-handling process is still compromised — stop all transfers and rebuild the clean boundary from scratch.
Reusable handoff record: timeline, public addresses, signatures, domains/apps, and compromise class; remaining asset/position inventory and recovery priority; clean-wallet creation and verified-destination evidence; recovery/revocation/account-rotation transaction record; loss/report/case IDs and a permanent-retirement plan.
For agents
An agent assisting with this workflow should never accept a seed phrase or private key as an ordinary input under any framing, and should treat "the user wants to recover a drained wallet" as an automatic trigger to refuse any action requiring one. Read-only inventory and containment steps (checking balances, drafting revoke transactions for a human to review and sign) are appropriate; anything that requires the compromised key to sign is not something an agent should attempt to route around.
Official references: https://consumer.ftc.gov/articles/what-know-about-cryptocurrency-and-scams · https://solana.com/docs
*This is educational technical and risk-analysis information, not financial, investment, legal, or tax advice. Blockchain transactions can be irreversible and no checklist can guarantee safety or profit.*