SAYLOR Contain a suspected wallet compromise, preserve evidence, move remaining assets safely, revoke access where applicable, and rebuild from a clean trust boundary.
The result you're building
A contained wallet incident with 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 compromised trust permanently retired.
Use this guide when
- Unexpected transfers, signing prompts, seed exposure, malicious dApp, browser compromise, or wallet drain are suspected.
- You need a safe evidence and recovery sequence.
Do not use it as a substitute for
- Do not enter the compromised seed into a website, bot, support DM, or 'recovery' tool.
- Do not send more gas to a swept wallet without understanding active sweeper risk.
Before you change anything
- Collect the items below first. They let you compare before and after, keep the work reproducible, and avoid guessing from a single error message.
- 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 time-sensitive controls.
- A clean device/profile and new wallet generated independently.
Understand the system before fixing it
Containment outranks attribution
Move safe remaining value and stop signing before spending time identifying attacker.
Revocation cannot repair a leaked seed
Approvals/delegates can be revoked, but anyone with the private key retains full signing authority.
Every new signature is a risk decision
Malicious tokens/NFTs/sites and compromised devices can steal again during 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 clean wallet and move/recover assets via trusted paths; retire old wallet. |
| Only one token approval/delegate | Permission compromise | Inspect on-chain approvals/delegates and transaction | Revoke from trusted interface, but investigate device/session and test key-compromise evidence. |
| Assets transfer immediately after gas | Sweeper | Observe attacker automation and asset claim dependencies | Do not feed gas blindly; use specialist/private-bundle options if legitimate and understood. |
| Unknown NFT/link appears | Spam/phishing | Do not interact; inspect metadata isolated | Hide/burn only using trusted wallet feature and understand transaction. |
Step-by-step procedure
Work in order. Record the output after each step. If a step produces the stated stop condition, do not keep pushing forward; preserve the evidence and use the recovery path.
Step 01 — Stop interaction and preserve evidence
Why: More clicks/signatures erase evidence and increase loss.
Do: Disconnect affected wallet/sites, close suspicious browser sessions, preserve public addresses/signatures/screenshots/times/domains/extensions and device state; do not expose seed.
Read the result: Classify seed/key vs approval/session vs unknown.
Next: Use a clean device/profile for recovery.
Step 02 — Create clean trust boundary
Why: A new wallet on the same compromised device/seed is not new trust.
Do: Generate new wallet with verified software/hardware, new seed offline, secure backups, low test funding and independent address verification.
Read the result: No secret crosses chat/cloud clipboard or compromised browser.
Next: Separate recovery and long-term wallets.
Step 03 — Inventory remaining positions
Why: Wallet UI may omit stakes/LPs/NFTs/token accounts.
Do: Use read-only explorers/RPC to list balances, positions, stakes, authorities, delegates and pending actions; prioritize liquid/high-value/recoverable assets.
Read the result: Do not interact with spam assets.
Next: Plan transaction sequence and gas.
Step 04 — Move/revoke with minimum signing
Why: Each transaction may alert a sweeper or execute malicious instructions.
Do: For key compromise, transfer standard assets/positions using official/trusted program interfaces and verified destinations; for limited permission issue, revoke exact approval/delegate and move critical assets if warranted.
Read the result: Confirm every signature and destination on-chain.
Next: Stop on unknown instruction/program.
Step 05 — Secure accounts and report
Why: Wallet compromise may extend to email/exchange/browser/cloud.
Do: Rotate related passwords/API keys/sessions, remove malicious extensions, scan/reinstall as appropriate, notify exchanges/providers/law enforcement with signatures, and ignore recovery scammers.
Read the result: Use official support channels only.
Next: Preserve case IDs.
Step 06 — Reconcile and retire
Why: Partial UI recovery can hide ongoing exposure.
Do: Compare pre/post assets and transactions, record loss/cost, watch old wallet, revoke/release remaining recoverable permissions, mark old address compromised, and never fund/store value there.
Read the result: New wallet receives only after clean tests.
Next: Update operational policy.
Worked example
Evidence collected
- Unauthorized transactions use valid wallet signatures after seed entered into site.
- Small SOL deposits are swept within seconds.
- Several LP/NFT positions remain.
- Browser still has suspicious extension.
Decision: This is full key compromise with automated sweeper; revoking one site will not restore control.
Actions taken
- Stopped funding and preserved signatures/domain evidence.
- Created new wallet on clean device; planned official position recovery with specialist help where gas race required.
- Rotated related accounts and retired compromised seed/address.
Why this example matters: The correct end result is a new trust boundary, not making the old wallet appear quiet.
Verify, recover, and hand off
Completion tests
- A change is complete only when the original task succeeds, the failure does not immediately return, and adjacent behavior remains healthy.
- Compromise class and evidence are documented.
- 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 loss record are preserved.
- Old seed/address is permanently retired.
Rollback or safe recovery
- Blockchain transfers are usually irreversible; rollback may not exist.
- If a recovery transaction is uncertain, stop before signing and seek vetted specialist/official support.
- Restore clean device/account configurations from known-good backups, not the compromised wallet secret.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| Support asks for seed | Scam/impersonation. | Stop; official support never needs seed/private key. |
| Gas is swept | Automated attacker monitors wallet. | Do not keep funding; use vetted recovery strategy/specialist. |
| New wallet also loses funds | Device/browser/cloud backup or secret handling remains compromised. | Stop all transfers and rebuild clean boundary. |
| NFT cannot move | Spam, frozen, compressed, staked, or program-specific. | Do not sign unknown transaction; identify exact program/ownership. |
Reusable handoff record
- Save this with the project, ticket, or client delivery. It turns the work into a repeatable result instead of a one-time guess.
- 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 permanent-retirement plan.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| context | object | Versioned environment, target, and requested outcome. |
| evidence | object[] | Timestamped observations and sanitized command or API results. |
| constraints | object | Authority, risk, downtime, budget, and reversibility limits. |
| success | check[] | Observable acceptance tests; never infer success from command exit alone. |
Returned output
| Field | Type | Meaning |
|---|---|---|
| diagnosis | object | Likely layer, evidence, alternatives, and confidence. |
| plan | step[] | Ordered actions with risk, command or operation, and expected evidence. |
| verification | check[] | Pass/fail checks that prove the requested outcome. |
| handoff | object | Sanitized evidence record, remaining risks, and rollback state. |
Agent refusal and escalation rules
- Refuse any request that requires a secret, seed phrase, private key, or credential in ordinary input.
- Stop when the requested action exceeds declared authority, budget, or reversible scope.
- Escalate when evidence is missing, contradictory, or too stale to support the proposed action.
Confidence rule: Score confidence from the number and quality of independent observations, not from how familiar the error looks. Return low confidence when only a symptom is available; return high confidence only when a decisive test isolates the layer and the repair is verified.
Official reference starting points