A Solana wallet may be compromised: contain the problem and identify what changed

Separate an unwanted asset from an unwanted action

Anyone can send an unsolicited token or collectible to a public address. Its arrival alone does not show that someone obtained your signing key. The dangerous step can be a later request to visit a link, sign a message or approve a transaction connected to that asset.

Leave unknown assets alone while investigating. Hide them through the wallet's supported controls if needed. Do not follow a recovery or reward URL embedded in token metadata. Use a known explorer to inspect transaction history by public address; reading a public record should not require your recovery phrase.

Identify the boundary that failed

A website connection lets an application interact with the wallet interface. Disconnecting it closes that connection. A token delegate exists in onchain account state and needs the applicable onchain revocation. A changed authority can give another address a different control role. An exposed signing key lets another person authorize actions as that key.

Write down the actual evidence: the requesting domain, transaction signature, affected token account, program and changed role. If the wallet shows a normal transfer you did not authorize, inspect the signer and resulting movements. If it shows an approval, inspect the delegate and remaining allowance.

A browser password change does not replace an exposed recovery phrase. Nor can a token-delegate revocation remove someone else's copy of a private key. The response must address the specific authority the attacker can exercise.

Replace exposed keys through a clean setup

If you disclosed the recovery phrase or private key, create a new wallet with independently generated recovery material using a trusted setup. Secure its backup before moving assets. Follow the wallet provider's migration guidance and stop using the exposed address for new receipts.

First inventory what remains. A wallet may hold liquid tokens while separate stake accounts, lending positions, open orders or leveraged positions require additional actions. Work out which authorities control each position and which exit steps the product supports. Do not assume an ordinary token transfer migrates a loan or native stake account.

An active attacker can compete for transactions and assets. Repeatedly adding SOL to an address that loses every new deposit can increase the loss. If normal control is no longer reliable, seek help through the provider's official incident channel rather than approving a stranger's proposed rescue transaction.

An ordinary allowance is a bounded permission

Handle an isolated token approval

Suppose a teaching example starts with 500 units in one token account. You approved a delegate for 100 units, and its transactions used 30. Inspect the current onchain delegate and allowance rather than relying on the original wallet preview. If the unwanted permission is still active and you control the required role, use the supported revoke operation.

After acceptance, read the account again and confirm that the ordinary delegate field is cleared and its delegated amount is zero. Other token accounts can have separate approvals. Mint-level features and a changed token-account owner require their own investigation.

This example illustrates a permission response. It does not establish that the keys were safe in a real incident. If the same attacker can sign as the owner, they may create another approval after you revoke the first.

Preserve evidence and reduce repeat exposure

Keep public signatures, timestamps with time zones, affected addresses, domains and a factual list of actions you took. Do not include secrets in that record. Report through the provider's official channel and the relevant service when a custodial account or fiat payment is involved.

Support can explain records and supported controls. A wallet provider generally cannot undo an accepted onchain transfer or reset the recovery phrase of a self-custodial address. Treat offers of guaranteed recovery, paid unlocking or secret validation as a new request that needs independent verification.

Before returning to ordinary use, check the replacement wallet's receipt and signing route, update saved receiving addresses and review the positions you intentionally retained. Preserve the old public history for reconciliation instead of deleting the only evidence of what happened.