How to Check a Wallet After a Seed-Generation Vulnerability or Wallet-Drain Report
To check a wallet after seed vulnerability warnings or an unexplained wallet drain, start with public evidence rather than the recovery phrase. Identify the exact address and blockchain, establish when suspicious activity began, inspect outgoing transfers and funding paths, review counterparties, decode questionable transactions, examine token permissions, and repeat the analysis across every relevant chain. These checks can reveal what happened on-chain and how assets moved. They cannot prove that a recovery phrase had strong entropy, remained secret, or was generated by trustworthy software. If seed compromise remains plausible, every account derived from that seed should be treated as potentially exposed until assets are moved to a genuinely new wallet generated from independent secure randomness.
TL;DR
- Wallet investigation and seed-security analysis answer different questions. Public blockchain evidence can show transactions, counterparties, approvals, funding paths, contract calls, balances, and timing. It normally cannot reveal the private entropy that created a recovery phrase.
- Never paste a seed phrase, private key, wallet password, keystore secret, or recovery code into a wallet-risk checker. A public-address investigation does not require those credentials.
- Start with the exact wallet address and correct blockchain. The same-looking asset can exist on several networks, and an address may have unrelated histories across different chains.
- Preserve transaction hashes, timestamps, destination addresses, token contracts, wallet versions, and any relevant security warning before taking extensive investigative actions.
- Look for full-balance sweeps, rapid sequences of outbound transfers, unfamiliar counterparties, newly funded gas activity, asset consolidation, and repeated timing across related accounts.
- Do not label every outgoing transaction a drain. Bridges, swaps, staking contracts, exchanges, account abstraction, token migrations, smart-account execution, and ordinary self-transfers can produce unfamiliar transaction paths.
- Use transaction decoding when a suspicious EVM transaction hash exists. The transaction sender, called contract, decoded method, internal calls, transfers, approvals, logs, and execution status can help distinguish direct key use from delegated token spending.
- ERC-20 approvals deserve separate review. A private key can remain secure while a previously authorized spender moves approved tokens through transferFrom.
- Disconnecting a wallet from a website does not revoke an on-chain token allowance. Check the live permission on the correct token, owner, spender, network, and permission system.
- Typed permit signatures and NFT operator permissions can create authority that does not look like a simple ERC-20 approve transaction.
- For EVM addresses, TokenToolHub Wallet Risk Scanner can review supported identity, assets, activity, approvals, counterparties, funding evidence, risk signals, confidence, and coverage using public data.
- For Solana, examine signatures, token movements, account authorities, delegates, program activity, counterparties, and funding behavior using the Solana Wallet Risk Scanner and appropriate explorer evidence.
- A clean wallet scan does not prove the seed is safe. It means the supported public evidence analyzed so far did not establish the specific risk being searched for.
- If a recovery phrase may have been generated by a known weak RNG, exposed to malware, entered into a phishing page, photographed, shared, or otherwise compromised, treat the problem as root-key exposure rather than only a suspicious-transaction problem.
- When root compromise is plausible, creating a second account under the same recovery phrase is not enough. Generate an independent new recovery phrase and migrate relevant assets carefully.
- Review every chain and account derived from the old seed. Moving only the most visible Ethereum balance can leave Solana, Bitcoin, secondary EVM addresses, tokens, NFTs, staking positions, or future deposits exposed.
If a tool, support agent, social-media account, chatbot, website, or supposed security specialist asks you to submit your recovery phrase in order to check whether the wallet was compromised, stop. A recovery phrase provides control of the wallet. Public-chain investigation should use public-chain identifiers.
What wallet checks can reveal, and what they cannot
A wallet-drain report creates immediate uncertainty. Users want one answer: is my wallet compromised?
Blockchain evidence rarely answers that question with a single yes or no. It provides observations that need to be interpreted according to the possible compromise mechanism.
A wallet scanner can show that an address sent its entire balance to an unfamiliar destination. A transaction decoder can show that a third-party contract used transferFrom to move an ERC-20 token. An allowance checker can show that the spender still has authority. A Solana transaction history can show a new delegate, authority change, token-account movement, or sequence of outbound instructions.
Those are observable facts.
They do not necessarily reveal how an attacker obtained authority.
On-chain evidence can answer what happened
Useful questions include which assets moved, when they moved, whether the wallet directly submitted the transaction, which contract executed, whether a spender used an existing allowance, which recipient received value, whether several accounts were drained in sequence, and whether the funds later converged at common addresses.
On-chain evidence usually cannot answer how a seed was generated
A public Ethereum or Solana address does not contain a record of the random-number generator that created its private key.
A wallet derived from excellent entropy and a wallet derived from weak entropy can look identical on-chain until their behavior diverges.
Before investigating deeply, determine whether funds are still at immediate risk
Investigation is important, but protecting remaining assets can be more urgent than producing a perfect forensic explanation.
If unauthorized transfers are actively occurring and you have credible reason to believe the root signing key is compromised, remaining assets under that seed may be exposed while you investigate.
Do not spend hours tracing collector addresses while substantial value remains under a key an attacker may already control.
Evidence of active root-key compromise deserves urgency
Examples include transactions directly signed by the wallet that you did not authorize, several unrelated assets being swept from the same account, simultaneous drains across addresses derived from one seed, or credible confirmation that the recovery phrase was generated through a known vulnerable process.
Approval abuse requires a different response
If one token moved because an authorized spender called transferFrom while the wallet's native asset and unrelated tokens remain untouched, an approval compromise may be more likely.
That can require revoking permissions and investigating the spender rather than immediately concluding that every private key has been stolen.
The wallet investigation workflow
A disciplined workflow keeps evidence separate from assumptions. Start from the public account, narrow suspicious events, identify the authorization mechanism, then decide whether the problem is local to one permission or broad enough to require root-seed migration.
Identify the address and chain
Confirm the exact public address, network, affected asset, and approximate incident time before drawing conclusions.
Review wallet behavior
Inspect outgoing transfers, funding paths, counterparties, assets, approvals, timing, failures, and unusual changes.
Preserve suspicious hashes
Record transaction hashes, destinations, token contracts, amounts, timestamps, and any relevant application history.
Decode the transaction
Determine whether the wallet signed directly or whether a spender, permit, operator, contract, or internal call moved the assets.
Review live permissions
Check token allowances and other authorization systems rather than assuming that disconnecting a website removed access.
Compare relevant chains
If the same recovery phrase controlled multiple networks, review related EVM, Solana, and other accounts systematically.
Migrate if the root is unsafe
If seed or private-key compromise remains credible, create an independent new wallet and move relevant assets carefully.
Step 1: identify the exact public address and chain
Every investigation should begin with the smallest set of facts you know with confidence.
Write down the wallet address, blockchain network, suspicious asset, and approximate date or time of the warning or unexpected movement.
This sounds obvious, but wallet investigations often become confused because users mix activity from several chains or addresses.
Network identity matters
The hexadecimal address used on Ethereum may also be usable on Base, Arbitrum, BNB Chain, Polygon, Optimism, Avalanche, and other EVM networks. Those networks maintain independent transaction histories and balances.
An address that looks compromised on Ethereum does not automatically have the same activity history on Arbitrum.
If the root key itself is compromised, however, the attacker may be able to control all compatible accounts using that key.
Do not investigate only the token symbol
Token symbols are not unique identifiers. Several unrelated assets can share the same ticker.
Record the actual token contract or mint where relevant. This prevents confusion between a legitimate asset and a copy or unrelated contract with the same display name.
Separate the currently used wallet app from the seed origin
If the warning concerns a seed-generation vulnerability, determine which application originally generated the phrase.
A phrase created in one wallet can later be imported into another. The current interface does not rewrite the generation history.
Preserve evidence before the story becomes harder to reconstruct
Blockchain records are durable, but surrounding evidence can disappear. Wallet interfaces change, labels are updated, social posts are deleted, applications are removed from stores, and users forget exactly what happened immediately before the drain.
Record these details when available
- The public wallet address.
- The exact blockchain network.
- Transaction hashes for suspicious movements.
- Approximate date and time each event occurred.
- Asset contract or mint addresses.
- Amounts transferred.
- Destination addresses.
- The application currently used to access the wallet.
- The application that originally generated the recovery phrase, if known.
- Approximate wallet-creation date.
- Recent dApps, bridges, mints, staking applications, claims, or swaps used before the incident.
- Any signatures or transactions the user remembers approving.
- Any security notification, wallet-drain report, or vulnerability notice that triggered the review.
Step 2: review the wallet as an account, not only as one transaction
One suspicious transaction provides a narrow snapshot. Account-level investigation adds context.
The TokenToolHub EVM Wallet Risk Scanner accepts a public EVM address and analyzes supported public-chain evidence without requiring a wallet connection, seed phrase, signature, or private key.
The current scanner can surface wallet identity and age, supported token exposure, activity patterns, approval evidence, counterparties, funding context, risk signals, confidence, freshness, and unresolved coverage.
Begin with identity and wallet age
First-observed activity helps establish whether an address is new, dormant, or historically active.
A wallet created years ago and suddenly emptied during a known drain campaign deserves a different interpretation from a wallet created minutes before making one intentional transfer.
Review native and token holdings
Compare current balances with historical movement where available. A drain may remove everything, only highly liquid assets, only one token family, or only assets covered by a particular permission.
The pattern matters.
Review transaction direction and cadence
Look for sudden changes from the wallet's historical behavior.
A wallet that typically makes one transaction every few weeks but suddenly submits many outbound transfers in several minutes may warrant closer inspection.
Cadence alone is not proof of compromise. Users sometimes consolidate wallets, migrate networks, rebalance portfolios, or interact with batch execution tools.
How to recognize an outgoing sweep
A sweep is a pattern in which substantial or nearly complete assets are transferred away from an address, often within a short period.
Attackers who obtain private keys may prioritize liquid assets and transfer them quickly before a victim can react.
Common sweep characteristics
Evidence can include a large portion of the native balance leaving, multiple ERC-20 balances moving, several transactions occurring in rapid succession, previously inactive tokens suddenly transferring, or multiple related addresses sending to shared destinations.
A full-balance transfer is not automatically malicious
Users legitimately consolidate wallets, move from hot storage to cold storage, rotate keys, migrate from vulnerable software, deposit into exchanges, or bridge assets.
The transfer must be compared with user intent and destination context.
Repeated drain timing can strengthen the signal
If several addresses that appear related are emptied during the same short time window and send toward overlapping counterparties, the pattern becomes more significant.
This type of timing analysis helped researchers understand coordinated wallet incidents where individual transactions initially looked like ordinary valid transfers.
Review unfamiliar counterparties carefully
A counterparty is another address or contract that appears in the wallet's interaction history.
Counterparty analysis can reveal exchanges, bridges, protocol routers, deployment addresses, collectors, known malicious infrastructure, or previously unseen destinations.
Labels are supporting evidence, not identity proof
An address label can help orient the investigation, but labels can be incomplete, stale, disputed, or based on external intelligence.
Interaction with a labeled malicious address does not automatically prove that the wallet owner was malicious or compromised. The transaction path and context still matter.
Unlabeled does not mean safe
Attackers frequently use fresh addresses that have no reputation history.
A newly created destination receiving assets from several drained wallets may be highly relevant even before public labeling services recognize it.
Funding paths can explain how suspicious activity was prepared
Funding analysis looks at how an address obtained the native asset required to transact and which addresses supplied value before or during the suspicious activity.
On EVM networks, an attacker-controlled address often needs ETH, BNB, MATIC, or another native asset to pay gas unless transaction sponsorship or another execution model is used.
Unexpected gas funding can be informative
Suppose a dormant wallet receives a tiny amount of the native asset from an unfamiliar address immediately before several tokens are moved out. That funding may be relevant to the incident.
It is not conclusive on its own. Exchanges, bridges, gas services, friends, faucets, and users themselves can also fund transaction fees.
Trace funding in both directions
Investigate not only where the victim wallet's funds went but also whether suspicious counterparties were funded from common sources.
Patterns across several addresses can reveal coordinated infrastructure that one transaction does not expose.
Use timing as evidence, not as proof
Transaction timing can help distinguish isolated user mistakes from automated sweeping.
Automation tends to produce repeated intervals, near-simultaneous activity across several accounts, rapid asset prioritization, or coordinated movement across chains.
Cross-chain timing can be particularly revealing
If an Ethereum account, a Base account, and a Solana account associated with the same wallet setup all begin losing assets within a narrow interval, the hypothesis of root-secret compromise becomes stronger.
That still requires caution. A legitimate user performing emergency migration could create the same pattern.
Step 3: decode suspicious transactions
A transaction hash is one of the most valuable pieces of evidence in an EVM investigation because it allows the transaction to be examined independently of the wallet interface that originally displayed it.
The TokenToolHub Transaction Decoder and Intent Explainer can inspect supported contract methods, token movements, approvals, internal calls, gas use, execution paths, and transaction consequences.
Start with the outer transaction sender
On a standard EVM transaction, the sender is the account whose signature authorized that outer transaction.
If the victim wallet is the sender of an unauthorized transaction, someone or something with signing capability submitted it.
That can point toward private-key compromise, malicious wallet software, delegated smart-account execution, or another signing path that requires deeper analysis.
Then inspect the called address
The transaction may call a token contract directly, a router, bridge, marketplace, vault, multisig, proxy, approval manager, or arbitrary smart contract.
The final asset recipient can differ from the transaction's top-level destination because contracts can invoke additional contracts internally.
Decode the method
Human-readable method interpretation can distinguish a simple token transfer from approve, transferFrom, swap, bridge, multicall, permit, stake, unstake, claim, or other contract operations.
Review internal calls and logs
Complex transactions can trigger many contract-to-contract calls.
An outer transaction that appears harmless may cause token transfers deeper in the execution path. Conversely, a scary-looking contract call may ultimately revert and change no state.
Execution status matters.
Direct key use versus delegated spending
This distinction is central to wallet-drain investigation.
| Evidence | Direct key or wallet execution | Delegated approval execution |
|---|---|---|
| Outer transaction sender | Victim wallet or authorized smart-account execution path | Often attacker, bot, spender contract caller, or relayer |
| Token owner | Victim wallet | Victim wallet |
| Typical token action | transfer, swap, send, contract call | transferFrom or another delegated permission mechanism |
| Private key must be stolen? | Possible, though smart-account or authorized-session mechanisms must also be considered | Not necessarily. Existing permission can be enough. |
| Main remediation question | Is the root signing authority still trustworthy? | Which permissions remain active and what spender controls them? |
Step 4: review approvals and token permissions
ERC-20 approvals allow a specified spender to withdraw tokens from an owner's balance up to an approved amount.
The token standard implements this through approve, allowance, and transferFrom.
This permission model enables decentralized exchanges, bridges, lending protocols, vaults, payment systems, staking applications, and countless other workflows.
It also means a wallet can lose tokens even when the attacker never learns the recovery phrase.
Approval exposure can outlive the original interaction
A user may approve a router during a swap and never use the application again. The allowance can remain in the token contract until changed.
If that spender is later compromised, upgraded maliciously, or was never trustworthy in the first place, the lingering allowance can become relevant.
Unlimited allowances increase residual exposure
Many applications historically request extremely large approval amounts to avoid repeated approval transactions.
An unlimited approval does not prove malicious intent, but it means the spender may have access to future eligible balances as well as the amount currently held.
Disconnecting a dApp does not revoke an allowance
Wallet connection and token authorization are separate concepts.
Disconnecting removes the website's active connection to the wallet interface. It does not alter the allowance stored inside the token contract.
Use the Approval Allowance Checker for exact permissions
The TokenToolHub Approval Allowance Checker is designed around one precise EVM permission relationship: owner, token contract, spender, and network.
It can read the live ERC-20 allowance and help users determine whether access remains active, unlimited, or larger than necessary.
Confirm the exact spender
Do not revoke random contracts merely because they appear unfamiliar.
Identify the spender shown in the original approval, decoded transaction, explorer event, protocol documentation, or application interface.
Review the live state, not only historical events
An old Approval event tells you what was authorized at that moment. Later approvals may have changed the allowance.
The current allowance is the important state when determining whether the spender can still move eligible tokens.
Recheck after remediation
If you revoke or reduce an allowance, wait for the transaction to confirm and verify the resulting live value.
Do not overlook permit signatures and other authorization systems
Not every token-spending permission begins with a traditional approve transaction initiated directly by the token owner.
ERC-2612 introduces permit, allowing an allowance to be established through a signed message that another party can submit on-chain.
Other permission managers and application-specific systems extend the concept further.
A signature can create future authority
Users sometimes think a signature is harmless because it has no gas fee and does not immediately move tokens.
A signed authorization can still be security-sensitive.
Review spender, value, nonce, deadline, chain, and verifying contract
These fields help define what a typed authorization permits and where it is valid.
A transaction decoder can help explain supported permit patterns when they later appear on-chain.
NFT operator permissions deserve attention too
ERC-721 and ERC-1155 ecosystems use authorization systems such as setApprovalForAll that can grant an operator authority over collections or token sets.
If NFTs disappear while fungible tokens remain untouched, investigate operator permissions rather than assuming a weak seed immediately.
Again, the exact transaction path matters.
Step 5: compare activity across relevant chains
Seed-level compromise is broader than one blockchain.
A recovery phrase can derive accounts across multiple ecosystems depending on the wallet's derivation schemes and user activity.
If the seed itself may be compromised, investigate all meaningful accounts derived from it rather than limiting the review to the chain where the first drain was discovered.
Review EVM networks independently
Check Ethereum, BNB Chain, Base, Arbitrum, Polygon, Optimism, Avalanche, and any other networks where the wallet held value or interacted with protocols.
Each network has its own balances, approvals, nonce history, transaction sequence, and contract state.
Look for drain order
An attacker may prioritize the most valuable chain first, then sweep smaller networks later.
A clean secondary chain immediately after the first drain does not guarantee it will remain untouched.
Investigating the Solana side of a multichain wallet
Solana uses a different account and transaction model from EVM networks, so evidence should be interpreted according to Solana's architecture.
The TokenToolHub Solana Wallet Risk Scanner can help review supported Solana wallet activity, token exposure, counterparties, funding behavior, delegates, authorities, staking context, and program interactions using public information.
Transaction signatures provide the history entry points
Solana's public RPC supports retrieving signatures associated with an address and then retrieving confirmed transaction details for a selected signature.
This enables investigators to reconstruct activity without access to private keys.
Review token-account authorities and delegates
Solana token accounts can contain authority and delegate relationships that differ from ERC-20 allowances.
Do not force an Ethereum permission model onto Solana. Review the relevant Solana account and program semantics.
Program interactions can explain unfamiliar movements
Swaps, staking operations, token-account creation, compressed assets, aggregators, DeFi protocols, and other Solana programs can produce transactions that look complex to users unfamiliar with instruction-level execution.
Complexity alone is not evidence of a drain.
Compare funding behavior across chains
Funding patterns can become more informative when viewed across several networks.
Suppose an attacker controls a common staging address family used to provide gas or transaction funding before sweeps. Repeated funding relationships may connect incidents that initially appear unrelated.
However, centralized exchanges and bridges can also create common funding relationships among legitimate users, so attribution should remain cautious.
When Smart Contract Diff becomes relevant
A seed-generation vulnerability is an off-chain secret-generation problem. Comparing smart contracts cannot tell you whether a mnemonic was created from weak randomness.
Smart-contract comparison becomes useful when the suspicious workflow involved an upgradeable spender, smart-account implementation, protocol contract, router, wallet module, or proxy whose behavior may have changed.
The TokenToolHub Smart Contract Diff and Upgrade Analyzer can compare supported verified source, ABI, permissions, token controls, proxy state, and runtime bytecode between EVM contracts.
Contract changes can explain a new approval threat
A spender may have been trustworthy when the user originally approved it but later gained new privileged behavior through an upgrade.
In that case, the key may remain secure while the approved contract's risk profile changes.
Do not use contract diffing outside its evidence layer
It cannot prove who signed a transaction, who generated a recovery phrase, whether malware exists on a device, or whether a private key leaked.
Classify the incident before choosing remediation
At this stage, evidence should be grouped into possible mechanisms.
| Incident pattern | Evidence to prioritize | Likely security boundary |
|---|---|---|
| Multiple directly signed outbound sweeps across unrelated assets | Outer transaction senders, timing, device history, seed history, related accounts | Private key, seed, wallet software, smart-account authority |
| One ERC-20 token moved through transferFrom | Spender, allowance, original approval, decoded call path | Delegated token permission |
| NFTs transferred through operator authorization | setApprovalForAll history, operator identity, transaction caller | NFT operator permission |
| Several addresses drained at similar times after known RNG disclosure | Wallet generation provenance, derived accounts, transaction timing, collector patterns | Potential seed-generation weakness |
| Loss follows suspicious wallet signature request | Signed data, permit fields, approval changes, subsequent transactions | Signature-based authorization or phishing |
| Assets lost from protocol position while wallet itself remains intact | Contract incident, protocol transactions, affected users, contract upgrades | Protocol or smart-contract layer |
Step 6: if seed compromise is plausible, expand the risk boundary
If the evidence points toward the recovery phrase or private key itself being compromised, reviewing one suspicious transaction is not enough.
A seed phrase acts as a root from which multiple accounts can be derived.
Anyone who possesses or can reconstruct that seed can potentially derive the same accounts.
Treat all relevant derived accounts as potentially exposed
This does not mean every account is guaranteed to be drained. It means the security assumption that only the legitimate owner can derive them is no longer reliable.
Creating account number two under the same phrase does not fix the root
Additional account indexes remain deterministic children of the same seed.
A root compromise requires a new root.
Changing the wallet password is not enough
A wallet application's local password usually protects local encrypted storage or interface access. It does not change blockchain private keys derived from the mnemonic.
Changing applications is not enough
Importing the same phrase into another wallet simply reproduces the same deterministic keys.
Generate a genuinely new wallet when root compromise is credible
A secure migration creates an entirely independent recovery phrase from a trustworthy cryptographic random source.
That new phrase should have no deterministic relationship to the compromised one.
Dedicated signing hardware can improve the new security boundary
For users moving away from a potentially compromised software-generated seed, a current hardware wallet such as Ledger can be one option for generating and isolating a new recovery phrase within dedicated signing hardware.
The important action is generating a fresh phrase. Restoring the compromised or weak phrase onto hardware does not change its entropy or secrecy.
Verify new destination addresses independently
Malware can replace clipboard addresses. Verify the destination using a trusted wallet display or independent check where possible.
Use test transactions where circumstances allow
If the wallet is not under active attack, a small transfer can confirm the destination before large-value migration.
If assets are actively disappearing, excessive delay can create its own risk. Prioritize remaining value according to the circumstances.
Build a complete migration inventory
Assets and relationships to review
- Native coins on every relevant chain.
- ERC-20, SPL, and other fungible tokens.
- NFTs and collection assets.
- Staked assets.
- Lending deposits and collateral.
- Liquidity-provider positions.
- Vault shares.
- Claimable protocol rewards.
- Bridge positions and pending withdrawals.
- Secondary addresses derived from the same recovery phrase.
- Exchange withdrawal whitelists pointing to old addresses.
- Payment, payroll, donation, merchant, mining, or validator destinations.
- ENS or other identity records that route users toward the old wallet.
- Saved addresses in dApps, contacts, or business workflows.
Do not forget future deposits
A compromised wallet does not become secure because its current balance reaches zero.
If the old private key remains exposed, funds sent there months later may also be vulnerable.
Attackers can monitor old addresses automatically.
Update recurring payment destinations
Check exchanges, clients, employers, payment pages, public profiles, trading counterparties, airdrop systems, validators, mining pools, OTC relationships, and saved withdrawal forms.
A practical TokenToolHub investigation workflow
Each tool answers a different question. Using them in sequence helps prevent one signal from being treated as a complete diagnosis.
Start with account intelligence
Use Wallet Risk Scanner for EVM identity, activity, assets, approvals, counterparties, funding context, risk evidence, confidence, and coverage.
Decode suspicious execution
Use Transaction Decoder when a transaction hash exists and you need to understand methods, transfers, approvals, internal calls, traces, fees, or failure behavior.
Check live permissions
Use Approval Allowance Checker to inspect the current ERC-20 allowance for the exact owner, token, spender, and network.
Compare contract changes
Use Smart Contract Diff when the incident may involve an upgraded spender, proxy, wallet implementation, or other changed EVM contract.
Wallet Risk Scanner walkthrough
For an EVM incident, open the Wallet Risk Scanner and select the network where the suspicious activity occurred.
Paste only the public 0x address.
Review identity first
Confirm that you entered the intended address and inspect wallet age, contract-account context, first observed activity, transaction count, and other supported identity evidence.
Move to activity
Look for transfers, calls, transaction direction, cadence, failed attempts, and behavioral changes.
Review approval exposure
Identify supported outstanding spenders, unlimited allowances, and other approval warnings. Missing approval data should remain unresolved rather than being interpreted as no approvals exist.
Review counterparties and funding
Look at the addresses the wallet interacted with and any observed first-funding evidence.
Focus on patterns rather than one unfamiliar address.
Read confidence and coverage
No public scanner has perfect historical coverage across every chain, token, internal transaction, label source, or permission system.
A professional report should tell you where the evidence ends.
Transaction Decoder walkthrough
If you find a suspicious EVM transaction, copy the exact transaction hash and choose the corresponding network in the Transaction Decoder.
Confirm basic transaction facts
Check sender, destination, block, status, value, fees, and execution outcome.
Read the decoded method
Determine whether the transaction called transfer, approve, transferFrom, a swap router, a bridge, multicall, permit-related logic, an NFT operator function, or another supported method.
Review asset movement separately from the top-level call
A transaction can move multiple assets and invoke several contracts. Follow token transfers and internal execution rather than assuming the top-level destination received all value.
Review approval events
If the transaction creates or changes permission, identify the spender and amount.
Check failures and reverted subcalls
A requested malicious action that reverted may create less exposure than a successful one. Conversely, one reverted subcall does not necessarily mean the entire transaction failed.
Approval investigation walkthrough
When a suspicious token movement appears to involve delegated spending, identify the token and spender before changing anything.
Find the owner
The owner is the wallet whose token balance can be spent.
Find the token contract
Do not use the token symbol alone.
Find the spender
The spender is the address authorized to use the allowance. It may not be the eventual recipient of the stolen tokens.
Read the current allowance
The live value answers whether permission remains after the incident.
Revoke or reduce only after confirming the permission
A rushed investigation can cause users to interact with the wrong contract or network. Verify before signing remediation transactions.
What a clean wallet scan really means
A clean result is not a guarantee of private-key safety.
It means that the supported evidence available to the scanner did not establish certain risk indicators within its analyzed scope.
A weak seed can remain dormant
If nobody has reconstructed it yet, the blockchain history can look completely ordinary.
A stolen seed can remain unused
An attacker may wait for larger balances or future deposits.
An undiscovered spender can exist outside current indexing
Approval datasets and labels can have coverage limitations.
Unresolved should remain unresolved
Absence of evidence should not silently become evidence of safety.
Avoiding false positives during wallet-drain investigation
Users reacting to a security warning can interpret every unfamiliar transaction as malicious.
That can produce unnecessary panic and poor remediation decisions.
Bridges can create unfamiliar destinations
Assets may be locked or burned on one chain while corresponding value is released elsewhere.
Routers can obscure the final swap path
A swap aggregator may interact with several contracts in one transaction.
Centralized exchanges can use changing deposit infrastructure
Funds sent intentionally to an exchange may later move through addresses the user does not recognize.
Smart wallets can separate user intent from outer transaction submission
Account-abstraction systems, relayers, modules, and sponsored execution can make transaction authorship more complicated than a basic EOA model.
Avoiding false negatives matters just as much
Familiar-looking destinations can still be dangerous.
A malicious spender can use a verified contract. An attacker can reuse an old exchange deposit route. A labeled protocol can be upgradeable. An address with no previous malicious history can be a newly created collector.
Reputation should never replace transaction interpretation
Inspect what authority was exercised and what value moved.
Signs that deserve closer investigation
Unexpected broad outbound movement
Several unrelated assets leave within a short window, especially when the wallet owner did not initiate a migration.
Unfamiliar counterparties
Previously unseen addresses receive significant assets, particularly if the same destinations appear across several wallets.
Unexpected funding immediately before activity
A dormant wallet receives a small native balance shortly before unauthorized transfers begin.
Repeated automated timing
Transactions execute quickly across several assets or chains in patterns inconsistent with the user's normal behavior.
Unknown active spender
A token allowance remains active for an application the user does not recognize or no longer trusts.
Direct transactions the owner never signed
Unauthorized outer transactions from the wallet raise the possibility that signing authority itself has been compromised.
None of these signals is proof on its own
Security investigation works by combining independent pieces of evidence.
A newly funded wallet can be normal. A full-balance transfer can be intentional. An unlimited approval can belong to a legitimate protocol. A transaction to an unlabeled address can be a self-transfer.
The objective is not to find one alarming field. It is to determine whether several observations support the same explanation.
Worked examples: interpreting real wallet-drain patterns
Example one: ETH and several tokens leave directly
A wallet that was inactive for months suddenly sends ETH, USDC, and two other ERC-20 tokens to three unfamiliar addresses. Each outer transaction shows the wallet itself as sender.
The user denies authorizing the transactions.
This pattern deserves immediate investigation of signing authority, device compromise, wallet software, recovery phrase exposure, and any known generation vulnerability. Approval revocation alone would not solve direct key compromise.
Example two: only one token disappears
ETH remains in the wallet. NFTs remain. Several other tokens remain. One ERC-20 balance is transferred through transferFrom by a third-party spender.
The decoded transaction shows that the wallet owner was not the outer transaction sender.
Check the live allowance and original approval before concluding that the seed was stolen.
Example three: an unlimited approval exists but nothing has moved
The user notices an old unlimited allowance to a protocol router.
This is exposure, not evidence that a theft occurred.
Investigate whether the spender is still trusted and whether continued permission is necessary. Reduce or revoke access according to the user's intended relationship with the protocol.
Example four: several chains drain around the same time
Ethereum tokens move at 14:03, a Base balance moves at 14:07, and a Solana account begins transferring assets shortly afterward. All accounts were derived from the same recovery phrase.
Cross-chain timing strengthens the hypothesis of root-secret compromise because one permission on Ethereum cannot normally authorize arbitrary Solana transactions.
Other explanations still need consideration, including legitimate emergency migration, but the risk boundary should expand immediately.
Example five: old wallet implicated in seed-generation advisory
A user learns that the application that originally created the recovery phrase used a documented weak random generator during the relevant version period.
The wallet has never been drained.
A clean on-chain history does not repair the generation problem. The user should evaluate migration because the security concern exists independently of observed theft.
Example six: suspicious signature but no immediate transfer
The user signed typed data on an unfamiliar website. No tokens moved at that moment.
Later, a spender submits an authorization and uses transferFrom.
The investigation should include permit or signature-based permissions rather than relying only on traditional approve transactions.
Example seven: protocol upgrade changes spender behavior
The wallet granted an allowance months ago to a legitimate upgradeable protocol. After a contract implementation change, suspicious transfers begin.
The seed may remain secure. Compare the relevant deployed contracts and investigate the spender's upgrade path.
Example eight: user intentionally migrated but forgot
A wallet shows rapid full-balance transfers to an unfamiliar destination. Later, the user confirms the destination is a cold wallet created during an emergency migration.
The transaction pattern looked like a sweep because, technically, it was a sweep. Intent distinguishes protective migration from theft.
Root compromise and permission compromise require different containment
Seed or private-key compromise
Assume relevant derived accounts may be exposed. Generate independent entropy, migrate assets, update future deposit destinations, and stop trusting the old root.
Approval or delegated-access compromise
Identify the exact spender or operator, revoke unnecessary authority, decode previous use, and determine whether the underlying signing key remains trustworthy.
Continue monitoring after the immediate incident
Post-incident monitoring can reveal additional collector addresses, late sweeps, accidental deposits to old accounts, and permission use that was not obvious initially.
Watch the old address
Do not reuse it for funds if the root is compromised, but continued observation can preserve forensic value.
Watch collector destinations
Movement from the first recipient to exchanges, bridges, mixers, or other consolidators may add context.
Watch secondary derived accounts
If they remain temporarily active during migration, prioritize assets and avoid new deposits.
When contacting exchanges or other services makes sense
Blockchain transactions are generally not reversible simply because the owner reports theft.
However, if stolen funds reach identifiable custodial infrastructure, preserving accurate transaction evidence can matter.
Provide evidence, not speculation
Include the originating wallet, transaction hash, destination, asset, amount, network, timestamp, and explanation of why the transaction was unauthorized.
Do not send seed phrases or account passwords to support teams.
Safety rules during wallet investigation
Keep these boundaries throughout the investigation
- Never enter a seed phrase into a wallet-risk scanner.
- Never send a private key to a support agent.
- Never give remote desktop access to someone offering wallet recovery.
- Never sign a transaction merely because a supposed investigator says it will secure the wallet.
- Verify remediation contract addresses independently.
- Do not trust direct messages claiming funds can be recovered by synchronizing or validating the wallet.
- Use public transaction hashes and public addresses for blockchain research.
- When migrating, verify destination addresses carefully.
- Keep the new recovery phrase completely separate from the compromised environment.
- Do not reuse the old phrase in a new wallet and assume the problem has been solved.
What no public wallet scanner can guarantee
Public-chain intelligence is powerful because blockchains preserve transaction evidence, but it has fundamental limits.
It cannot certify private-key entropy
A public address alone usually does not reveal whether its private key came from 128 bits of secure entropy, a compromised wallet application, or a weak RNG.
It cannot prove private identity
Labels and transaction relationships may suggest context, but an address is not automatically tied to a legally verified person.
It cannot predict future compromise
A clean wallet can sign a malicious transaction tomorrow.
It cannot guarantee complete indexing
Historical internal calls, obscure assets, custom protocols, approvals, labels, and chain-specific behavior may not be fully captured by every provider.
It cannot replace human intent
A transfer can look like theft on-chain while being an intentional migration. Investigation requires comparing technical evidence with the owner's expected actions.
A practical decision framework
| Finding | Interpretation | Next step |
|---|---|---|
| No suspicious public activity and no known seed exposure | No compromise established by current evidence | Maintain normal security hygiene and monitor important wallets |
| Old or unnecessary approvals | Residual delegated-access exposure | Verify spender and revoke or reduce permissions as appropriate |
| Unauthorized transferFrom by known spender | Approval abuse possible | Revoke permission, decode history, investigate spender |
| Unauthorized transactions directly signed from wallet | Signing authority may be compromised | Protect remaining assets, investigate key and device security, consider new seed |
| Confirmed vulnerable seed-generation path | Root secret may be computationally recoverable | Create independent new seed and migrate relevant accounts |
| Multiple chains drained from same seed family | Root compromise becomes a strong concern | Treat all relevant derived accounts as exposed |
| Suspicious behavior tied to changed contract implementation | Application or spender-layer risk possible | Compare contracts, permissions, and upgrade authority |
Wallet checks are also useful before an incident
Users do not need to wait for a drain report to examine wallet exposure.
Periodic review can surface forgotten approvals, unexpected counterparties, abandoned wallets still receiving funds, or asset concentration that increases consequences if one key is compromised.
Review long-lived approvals
Permissions that made sense during one DeFi transaction may no longer be needed months later.
Review wallet segmentation
Holding long-term savings in the same wallet used for experimental mints, unknown contracts, and frequent dApp signatures increases the consequences of one mistake.
Separate long-term custody from active interaction where appropriate
A dedicated long-term wallet can reduce the amount of value exposed to routine application interactions.
The complete wallet-check sequence
Conclusion: investigate the wallet without turning the investigation into another compromise
When a seed-generation vulnerability, wallet-drain warning, or unexplained transfer appears, the safest investigation begins with public evidence.
Identify the exact address and blockchain. Establish the incident window. Preserve transaction hashes. Review wallet activity, outgoing sweeps, funding paths, counterparties, and timing. Decode suspicious transactions. Check active token permissions. Compare relevant chains and accounts.
Those steps can answer an important question: what authority actually moved the assets?
That distinction matters because wallet drains have different root causes.
A malicious ERC-20 spender can move approved tokens even though the private key remains secure. An NFT operator can transfer assets through delegated authority. A compromised smart contract can affect many users while their recovery phrases remain private. A phishing page can steal a perfectly strong seed. A weak random-number generator can make a phrase recoverable even when the user never revealed it.
Do not collapse all of those incidents into one generic hacked-wallet explanation.
For EVM account-level review, the Wallet Risk Scanner can help examine activity, assets, approvals, counterparties, funding evidence, supported risk signals, confidence, and coverage. When a particular transaction is questionable, the Transaction Decoder can help determine what the transaction executed. If delegated ERC-20 authority is involved, use the Approval Allowance Checker to inspect the live owner-token-spender relationship. For Solana accounts, use the Solana Wallet Risk Scanner to investigate public wallet behavior according to Solana's account model.
If the incident involves an upgradeable smart-account implementation, spender, router, or protocol contract whose behavior changed, the Smart Contract Diff and Upgrade Analyzer can help evaluate the contract layer separately.
None of these public tools should ask for your recovery phrase.
And none of them can look at an ordinary public address and certify that the original seed was generated with strong entropy.
If credible evidence points toward root-seed compromise, broaden the response. Treat relevant derived accounts as potentially exposed, create an independent new recovery phrase through a trustworthy cryptographically secure process, verify new destination addresses, move assets carefully across every relevant chain, and update future deposit destinations so value does not return to the old wallet.
The objective of wallet investigation is not to produce a dramatic risk label. It is to establish what the blockchain actually shows, identify where authority came from, state what remains uncertain, and take proportionate action before uncertainty becomes additional loss.
Start with public wallet evidence
Use the wallet address and transaction hashes to investigate activity. Keep seed phrases, private keys, wallet passwords, and recovery codes completely offline.
FAQs
How do I check a wallet after a seed vulnerability warning?
Start with the public wallet address and correct blockchain. Review wallet activity, outgoing transfers, counterparties, funding paths, approvals, and suspicious transaction hashes. If seed compromise remains credible, investigate every relevant account derived from that recovery phrase and prepare to migrate to a genuinely new seed.
Can a wallet checker tell whether my seed phrase is compromised?
A public wallet checker can identify observable on-chain evidence but usually cannot determine whether the private seed was leaked or generated from weak entropy. Seed security depends on generation and confidentiality history that is not normally encoded in the public address.
Should I enter my seed phrase into a wallet risk checker?
No. Never enter a recovery phrase, private key, wallet password, keystore secret, or recovery code into a public wallet scanner. Public-address analysis does not require wallet credentials.
What are common signs of a compromised crypto wallet?
Potential signs include unauthorized directly signed transactions, broad asset sweeps, unfamiliar counterparties, rapid repeated outbound transfers, suspicious new funding before a drain, unexpected active permissions, and similar activity across several accounts. None of these signs is conclusive by itself.
What is a wallet sweep?
A sweep is a pattern where most or all available assets are transferred away from an account, often rapidly. Sweeps can be malicious or legitimate, such as when a user intentionally migrates to a new wallet.
Does one unfamiliar outgoing transaction mean my seed was stolen?
No. The transaction may represent a swap, bridge, contract interaction, approval-based transfer, exchange deposit, smart-wallet execution, or intentional transfer. Decode the transaction before attributing it to seed compromise.
How can I tell if a token was stolen through an approval?
Inspect the transaction sender and decoded token call. If a third-party spender used transferFrom against the victim wallet's token balance, an existing allowance may have enabled the movement without the spender possessing the wallet's private key.
Does disconnecting my wallet from a dApp revoke token approvals?
No. Disconnecting a website does not change an ERC-20 allowance stored in the token contract. The live allowance must be checked and changed on-chain if necessary.
What is an unlimited token allowance?
It is a very large allowance that effectively lets a spender use an eligible token balance without requiring a new approval for each normal interaction. It can create residual exposure while the permission remains active.
Can a permit signature put tokens at risk without an approve transaction?
Yes. Standards such as ERC-2612 allow approval authority to be created through signed messages that can later be submitted on-chain. Review spender, value, nonce, deadline, chain, and verifying contract when investigating permit-based authorization.
Can NFTs be moved without my seed being stolen?
Yes. NFT operator permissions such as setApprovalForAll can allow authorized operators to transfer eligible assets. Review operator authorization history before concluding that the root key is compromised.
What can TokenToolHub Wallet Risk Scanner review?
For supported EVM networks, it can analyze public evidence including wallet identity and age, holdings, activity patterns, approvals, counterparties, funding context, supported risk signals, confidence, freshness, and coverage.
Does Wallet Risk Scanner require me to connect my wallet?
No. The EVM wallet scanner can begin from a public address and does not require a seed phrase, private key, or transaction signature.
What does a clean wallet-risk result mean?
It means the supported public evidence analyzed did not establish certain risk indicators within the available coverage. It does not prove the private key or recovery phrase is guaranteed safe.
Why should I decode a suspicious transaction?
Decoding can show the actual method, sender, destination, token transfers, approvals, internal calls, status, and execution path. This helps distinguish direct wallet signing from delegated spending and ordinary contract activity.
What should I record when I discover an unauthorized transaction?
Record the transaction hash, blockchain network, wallet address, destination addresses, affected asset, amount, timestamp, token contract where relevant, and any related security notification or wallet-generation history.
Can funding paths help identify a wallet drainer?
Funding evidence can reveal relationships among addresses, such as a common account providing gas before several suspicious transactions. It is supporting evidence rather than definitive proof of common ownership.
Why does repeated drain timing matter?
Near-simultaneous activity across several assets or addresses can suggest automation or coordinated control. Legitimate emergency migration can produce similar timing, so context remains necessary.
Should I check every EVM chain if one address is compromised?
If the private key or seed itself may be compromised, review all relevant networks where that key or recovery phrase controls value. Ethereum, Base, Arbitrum, BNB Chain, Polygon, Optimism, Avalanche, and other EVM histories are independent even when the same address format is used.
Should I check Solana if the same recovery phrase was used there?
Yes. If Solana accounts were derived from the same root recovery phrase, root compromise may expose them too. Review Solana transactions, token activity, counterparties, delegates, authorities, and program interactions separately.
Can an Ethereum token approval compromise my Solana wallet?
An ordinary ERC-20 allowance is specific to its EVM token and network and does not directly authorize Solana transactions. If both Ethereum and Solana accounts are drained, broader seed or device compromise deserves stronger consideration.
When is Smart Contract Diff useful in a wallet investigation?
It is useful when suspicious behavior may involve an upgraded EVM contract, spender, proxy, smart-account implementation, router, or protocol. It does not determine whether a private seed was generated securely.
What should I do if my seed phrase itself may be compromised?
Generate an independent new recovery phrase through a trustworthy secure process, verify the new wallet addresses, inventory assets across every relevant account and chain, migrate them carefully, and stop using the old root for future deposits.
Can I create another address under the same recovery phrase instead?
No. If the root recovery phrase is compromised, additional account indexes derived from that phrase remain connected to the same compromised root.
Does changing my wallet password protect me after seed compromise?
No. A local wallet password usually protects application storage. It does not change private keys derived from the recovery phrase.
Does importing the seed into another wallet app make it safe?
No. Importing the same recovery phrase recreates the same underlying wallet keys.
Does importing a compromised seed into a hardware wallet fix it?
No. Hardware can isolate signing but cannot add entropy or secrecy to an already compromised recovery phrase. A secure migration requires generating a new seed.
Should I move funds immediately if I suspect compromise?
If unauthorized activity is ongoing or credible evidence indicates root-key compromise, protecting remaining assets may be more urgent than completing a full forensic analysis. Use a trustworthy new wallet and verify destinations carefully.
Should I send a test transfer when migrating?
A small test transfer is useful when time permits because it confirms the destination. During an active drain, delaying every major asset transfer for repeated tests may create additional exposure, so urgency and verification need to be balanced.
What happens to an old compromised wallet after I empty it?
It should not be reused for future value. Update exchange whitelists, payment addresses, contacts, payroll destinations, donation pages, and other systems that may still send funds to it.
Can a wallet remain compromised even if it currently has a zero balance?
Yes. If the underlying private key remains exposed, future deposits to the same address can also be taken.
Can wallet labels prove who controls an address?
No. Labels are useful supporting context but may be incomplete or wrong and do not prove private identity or ownership.
What if the suspicious transaction reverted?
A reverted transaction may have failed to change state, but inspect the full transaction and supported internal execution evidence before assuming nothing happened. Some complex transactions contain multiple calls whose effects depend on the overall execution structure.
Can an old approval become dangerous later?
Yes. A permission can remain active long after the original interaction. Future deposits of the approved token may become accessible to the spender if the allowance remains sufficient.
What is the safest starting point after a wallet-drain warning?
Start with the exact public address, network, suspicious transaction hashes, and a read-only review of wallet behavior. Keep the recovery phrase offline while determining whether the incident involved direct signing authority, delegated permissions, contract behavior, or another mechanism.
References and further reading
The following standards and technical documentation provide additional background on transaction receipts, token allowances, delegated permissions, and public blockchain transaction analysis.
- Ethereum JSON-RPC API Documentation
- ERC-20 Token Standard
- ERC-2612 Permit Extension for ERC-20
- Solana getSignaturesForAddress RPC Documentation
- Solana getTransaction RPC Documentation
This guide is educational security research and does not guarantee recovery of stolen assets or determine private identity, ownership, criminal intent, or future wallet safety. Blockchain data providers, labels, approval indexes, traces, and historical coverage can be incomplete. Never provide TokenToolHub or any public wallet scanner with a recovery phrase, seed phrase, private key, wallet password, keystore secret, one-time code, or exchange login credentials.
