| name | atomic-leaked-key-response |
| description | Use when the user reports or suspects a Solana wallet key has leaked, been shared, was found in version control, or is being watched by sweeper bots, and they need a step-by-step incident-response plan. Triggers on "key leaked", "wallet compromised", "sweeper draining my wallet", "creator key shared", "private key in git", "find leak", "what do I do my key is out there", "recover funds from leaked wallet", or "key in chat". Drives the user through the multi-step Jito-bundle recovery sequence with explicit decision branches. |
atomic-leaked-key-response — incident playbook
The single highest-stakes scenario this repo addresses. Treat every step as time-critical: sweeper bots typically drain SOL within 1–3 seconds of any deposit and Token-2022 within 2–4 seconds. The goal of this skill is to walk the operator through the right sequence of atomic flows in the right order, with the right inputs, so that funds escape the compromised wallet before competing actors take them.
This skill is the orchestrator; it does not implement anything itself. It points at atomic-collect, atomic-consolidate, atomic-rescue, atomic-audit, and the helper tools.
Triage: is this actually a leak?
Before running anything, confirm. False alarms are common and the wrong response (panic-sweeping to a destination you don't fully control, or to a sweeper-watched safe wallet) makes things worse.
| Signal | Interpretation |
|---|
| Key string ever pasted in chat / Discord / forum / commit message / log file | Treat as fully leaked. Indexers scrape these in seconds |
| Key on a shared dev box / CI runner / colleague's laptop | Leaked from the moment more than one human had access |
| Wallet shows outgoing txs you didn't sign | Confirmed active compromise. Skip triage, go to "Sequence" now |
.env file committed to a public repo (even briefly) | Leaked. GitHub history is irreversible |
.env committed to a private repo with external collaborators | Treat as leaked. Audit every collaborator |
Wallet generated by solana-keygen on a host that ran an unverified `curl | bash` script in the last year |
| You followed a "pump.fun bot" tutorial that asked for your private key | 100% leaked. The tutorial author has every key it asked for |
If two or more of the above apply, escalate immediately.
Pre-conditions
Before running the recovery sequence, the operator needs:
- The leaked secret (
CREATOR_SECRET). Without this, you cannot sign the collect / consolidate / rescue txs.
- A clean funder wallet with at least
0.05 SOL for tips and ATA-create rent. This wallet must:
- Have no transaction history with the leaked wallet (otherwise chain analysis links them);
- Be loaded from a key that lives only on the operator's host (not on the same host the leaked key was exfiltrated from);
- Be different from
DESTINATION.
- A safe destination pubkey (
DESTINATION) — a wallet only the operator controls. Confirm:
- Generated on a clean host;
- Not previously used as a sweep destination for other leaks (chain analysts cluster these);
- Not a CEX deposit address (atomic guarantees end at custodial boundary).
- A paid RPC (Helius / Triton / QuickNode). Public mainnet rate-limits at exactly the worst moment.
If the operator lacks any of these, generate them first. Do not skip.
Sequence — run back to back
The order is load-bearing. Each step closes off an attack surface; running them out of order leaves windows.
Step 1 — Sweep the pump.fun creator vault
Sweepers most often target the coinCreatorVault PDA because it accrues SOL automatically from buys/sells of the coin. This is the highest-yield target for a same-key adversary.
DESTINATION=<safe-wallet> \
FUNDER_SECRET=<clean-funder> CREATOR_SECRET=<leaked-creator> \
JITO_TIP=0.01 \
npm run collect
Notes:
- Start
JITO_TIP=0.01, not 0.005. You are racing other holders of the same key.
- If the bundle returns
Invalid, jump to atomic-bundle-debug. Most likely: tip too low (escalate) or tip-account list drifted.
- If the bundle lands but the vault still has SOL afterwards: another collector landed in the same slot. Re-run immediately.
See atomic-collect for the script details.
Step 2 — Consolidate residual SOL
Drains any SOL still sitting in the creator wallet (and funder, if the operator decides) to DESTINATION in one Jito bundle.
DESTINATION=<safe-wallet> \
FUNDER_SECRET=<clean-funder> CREATOR_SECRET=<leaked-creator> \
JITO_TIP=0.01 \
npm run consolidate
Notes:
- After this lands, the creator wallet holds only the rent-exempt minimum (~0.002 SOL). That is unrecoverable without closing the account, but its value is negligible.
- If the funder is genuinely clean and you want to keep using it for future operations, check the script's flags — some variants drain the funder too. Read the source before running.
See atomic-consolidate.
Step 3 — Inventory token balances on the leaked wallet
Before rescuing tokens, you need to know what's there. Use the balance checker:
npx tsx tools/check-balances.ts <leaked-creator-pubkey>
This prints every non-zero SPL + Token-2022 holding. Sweepers may have already moved some; treat what remains as the recovery scope.
Step 4 — Rescue tokens
For each mint with a balance, run rescue-tokens.js. Iterate over the output of Step 3.
SOURCE_SECRET=<leaked-creator> \
DESTINATION=<safe-wallet> \
MINT=<token-mint> \
RENT_PAYER_SECRET=<clean-funder> \
JITO_TIP=0.005 \
npm run transfer-tokens
Decision branches:
- Token-2022 with transfer hooks: if the bundle fails with
MissingAccount, the hook program is unknown to the script. Either:
- Look up the hook's required accounts in its program docs and patch the script (loses atomicity briefly during the patch test), OR
- Accept the loss for that mint if its value < the cost of integration.
- No SOL in leaked wallet: set
RENT_PAYER_SECRET to the clean funder. The leaked wallet contributes no SOL; the funder pays tip + destination-ATA-create rent.
- Tokens land in a wallet that is itself a sweep target: the
DESTINATION must be a wallet the operator alone controls. Verify with Step 5.
See atomic-rescue.
Step 5 — Verify destination is clean
If DESTINATION was itself seeded by pump.fun (which sometimes happens with fresh wallets generated via pump's UI), some downstream rewards-distribution programs may classify it as Sybil and exclude it. Audit:
npx tsx tools/check-pump-funding.ts <safe-wallet>
Expected output: RED (not pump-seeded). If GREEN, either:
- Generate a new
DESTINATION and re-sweep to that (one more Jito bundle), OR
- Accept the lineage and document it.
See atomic-audit.
Step 6 — Verify recovery completeness
Re-check the leaked wallet:
npx tsx tools/check-balances.ts <leaked-creator-pubkey>
Expected: SOL ≤ 0.002 (rent-exempt), 0 tokens. If anything else remains, repeat Step 3–4 for those mints.
After the sweep — operational hygiene
- Permanently flag the leaked address as watched. Do not deposit to it again. Sweeper bots index leaked keys indefinitely.
- Rotate every key that touched the compromised host. Even keys you "didn't paste anywhere" — if the host is compromised, every secret on it is compromised.
- Generate a fresh creator wallet if continuing operations. Run
npm run grind (or solana-keygen grind) on a clean host.
- Audit the leak vector. Was it a committed
.env? A shared dev box? A chat paste? A malicious tutorial? Fix the upstream, not just the symptom.
- If the leak was via this assistant (PAT, key, or
.env pasted in chat): rotate the PAT or generated artifact too, separately from the wallet.
Post-incident forensics
These are useful but lower-priority than the recovery itself. Do them after Step 6.
- Reconstruct the leak path. When was the key first exposed? Cross-reference with the first competing sweeper tx on Solscan to estimate how long ago the leak happened.
- Identify the sweeper operator(s). Cluster the destinations of competing sweeps. Sometimes one operator runs many sweepers; sometimes a single sweep tx reveals a multi-wallet ring.
- Quantify loss. Compare the leaked wallet's full historical inflows to what you recovered. The gap is the loss attributable to sweepers (plus your own legitimate spending).
- Document publicly? Only if you trust your operational security posture is now sound. A public post-mortem can be a recruiting signal for attackers if it reveals exploitable habits.
Edge cases
- Leaked wallet is also the funder for live operations. Pause those operations first; otherwise you'll keep funding the sweeper. Generate a fresh funder, re-route, then run recovery.
- Multiple leaked keys, one host compromise. Treat them as a single incident. Run the sequence for each leaked role (creator, funder, separate vanity wallets). Funds should converge on a single fresh
DESTINATION.
- Leak suspected but not confirmed. Run the sweep anyway. Sweep cost (tips + rent) is ~0.05 SOL total; that's cheap insurance against an unconfirmed compromise.
- Leak occurred more than a year ago and the wallet still has value. Surprisingly common — some sweeper operators index recent leaks and miss older ones. Run the sweep ASAP; you may be in a window where the leak exists but isn't actively watched.
- Coin was launched from the leaked wallet but is currently inactive (zero trade volume). Vault won't accrue more until trading resumes. Decision: sweep now (zero gain, ~0.01 SOL cost) or wait for accrual and run
watch-collect.js with a low threshold (better cost-efficiency, but you must trust the watcher's vigilance).
What this skill does NOT cover
- Recovering from a leaked exchange API key — exchange-side, not on-chain.
- Recovering from a compromised hardware wallet seed — physically rotate the device; this repo cannot help.
- Reversing on-chain transfers — Solana is irreversible. There is no "undo".
- Legal recourse against sweeper operators — possible in some jurisdictions but out of scope.
- Recovering tokens that have already left the leaked wallet — gone. Focus on what remains.
Related
