A Trust Wallet confirmation screen is the final checkpoint before a signature can change onchain state. The built-in Security Scanner can flag known malicious addresses, risky dApps, suspicious tokens and dangerous contract interactions, but a warning is decision support rather than a substitute for understanding the request. This guide explains how to separate a connection from a signature, read transaction details, control token approvals, recognize address poisoning and respond proportionately after an unsafe interaction.

Last reviewed: October 17, 2026. Trust Wallet interfaces, Scanner warnings, risk providers, supported networks, approval controls and transaction decoding can change. Confirm current behavior in the latest verified mobile app or browser extension. This independent guide is educational, is not affiliated with Trust Wallet and is not financial, legal or professional incident-response advice.

Quick answer: treat a Security Scanner warning as a reason to stop, not as a box to dismiss. Verify the exact domain, network, recipient, token, amount, spender and contract action from independent sources. A green or absent warning does not prove that a transaction is safe, profitable or consistent with your intention. If the request remains unclear, reject it. After a suspicious interaction, disconnect the dApp, review and revoke relevant approvals, inspect the transaction on the correct explorer and move unaffected assets to a newly secured wallet when credible compromise exists.

What this guide covers

  1. What Trust Wallet Security Scanner can assess and where its protection ends.
  2. The differences between connecting, signing a message, approving a token and sending a transaction.
  3. How token allowances persist and how the built-in Approvals view can help.
  4. How to review a dApp, contract, recipient and transaction before signing.
  5. Why address poisoning, copied domains and deceptive prompts bypass habits rather than cryptography.
  6. How to respond after a connection, signature, approval, transfer or recovery-phrase disclosure.

What Trust Wallet Security Scanner does

Trust Wallet describes Security Scanner as a built-in system that assigns risk information to supported transactions and warns about potential threats. Signals may include known malicious addresses, unsafe dApps, suspicious tokens or contract behavior identified by Trust Wallet and its security data providers. It operates within supported Trust Wallet flows rather than requiring the user to paste a recovery phrase into an external scanner.

The Scanner is most valuable as a pause mechanism. A warning interrupts momentum and gives the user a chance to reject the request, verify the source and inspect what authority would be granted. It does not make the wallet custodial: Trust Wallet cannot normally cancel a confirmed transaction, retrieve a disclosed secret phrase or restore assets sent to an attacker.

A warning is not the same as transaction blocking

Self-custody means the signer retains final authority. Depending on the risk and current interface, the wallet may display information, require another acknowledgement or prevent a known-dangerous flow. Do not build a safety process around the assumption that every threat will be blocked.

When a warning appears, read the exact reason instead of treating every alert as identical. A domain reputation warning, malicious-address alert, risky token label and unlimited approval describe different hazards. The response begins by identifying which object is being flagged.

No warning does not mean “verified safe”

Threat databases are necessarily incomplete. A new phishing domain, newly deployed contract or recently compromised legitimate website may not yet carry a negative reputation. Some harmful outcomes also arise from valid functionality: an authentic DeFi contract can still liquidate a risky position, and a legitimate swap can still have severe price impact.

A quiet confirmation screen therefore means only that no displayed warning stopped the flow. It does not prove that the project is honest, the token is liquid, the contract is bug-free, the recipient belongs to the intended person or the transaction matches the user’s plan.

Scanner result Reasonable interpretation Unsafe interpretation
High-risk or malicious warning Reject and investigate independently Proceed because the website says it is a false positive
Caution or unknown risk Information is incomplete; inspect every field Assume medium risk means acceptable
No visible warning Continue normal verification Assume Trust Wallet guarantees the transaction
Simulation or decoded action Use it to understand likely effects Assume every hidden or future effect is covered

Four requests that users often confuse

A dApp can present several requests in sequence. The familiar Connect button can create false confidence when the next prompt has much greater consequences. Classify each prompt before approving it.

Request Typical effect Main question
Connect wallet Shares a public address and selected network with the site Do I want this site to associate itself with this address?
Sign message Proves control or authorizes structured data without necessarily moving funds immediately What statement or permission am I signing?
Approve token Authorizes a spender contract to transfer up to an allowance Which spender, token and amount receive permission?
Send transaction Changes onchain state: transfer, swap, mint, stake or another contract action Do the decoded effects match my intention?

Connecting a wallet is not spending permission

A standard wallet connection usually exposes the selected public address, network and limited session information. It does not disclose the private key or automatically authorize a token transfer. Nevertheless, connection has privacy and social-engineering consequences: the dApp can observe the address, its public activity and often its balances.

A connected site can immediately request a signature or transaction. Users who believe the original connection “already approved everything” may stop reading subsequent prompts. Treat every new request as a separate decision. Disconnect unused sessions, but remember that disconnection does not remove permissions already recorded onchain.

Message signatures can carry authority

“No gas” does not mean “no risk.” A message signature may log in to a service, accept terms, prove address ownership or authorize an action that another party can later submit. Structured signing formats can display domain, spender, token, amount, nonce and deadline, but a deceptive interface may summarize them poorly.

Reject requests containing an unexpected domain, unlimited amount, long deadline, unknown spender or unreadable message. Never sign a message only because a stranger says it is needed to verify, synchronize, validate or recover the wallet.

What a token approval actually grants

Many token contracts require an approval before a decentralized exchange, lending protocol or marketplace can move the user’s token. The wallet owner authorizes a specific spender address to transfer up to a defined allowance. The later spending action may not require another approval signature as long as the allowance remains valid.

The approval concerns the named token and spender, not the entire wallet in every case. However, approving a valuable token to a malicious or compromised spender can put that token balance at risk. NFT approvals can cover a specific item or an operator’s access to a broader collection, depending on the standard and method.

Limited versus unlimited approval

A limited approval covers a defined amount, such as the quantity intended for one swap. An unlimited approval uses the maximum possible allowance so future transactions do not need a new approval. Unlimited access improves convenience but expands the exposure if the spender becomes malicious or vulnerable.

Choose a limited amount when the interface and protocol support it, particularly for a one-time or unfamiliar interaction. Re-check the token’s decimals and displayed units. A number that appears small in raw contract data may represent a different human-readable amount after decimal conversion.

Approvals can remain after leaving a dApp

Closing a browser tab, removing a bookmark or disconnecting WalletConnect does not rewrite blockchain state. An allowance normally persists until it is spent, expires under a specific permit design, or is changed by another onchain transaction. This is why stale approvals can remain months after the original dApp interaction.

Trust Wallet’s built-in Approvals feature is designed to show active permissions and identify some risky allowances. Review it periodically and after using an unfamiliar dApp. Availability can vary by wallet version, platform and network.

How to review approvals in Trust Wallet

  1. Update Trust Wallet through its verified app-store listing or official extension channel.
  2. Open the wallet and account whose permissions need review.
  3. Select the current Approvals area shown in the assets interface.
  4. Confirm the blockchain network before interpreting the list.
  5. Review the token, spender, approved amount and any displayed risk flag.
  6. Identify permissions tied to unknown, obsolete or no-longer-trusted dApps.
  7. Revoke deliberately and review the gas fee before confirming.

Do not connect to an unknown “approval checker” discovered through an advertisement. The built-in feature reduces dependence on external sites. If an external explorer or tool is necessary for an unsupported network, verify its exact official domain independently.

Revoking an approval is an onchain transaction

Revocation generally sets an allowance to zero or removes an operator permission. Because it changes blockchain state, it usually requires native gas on that same network. ETH on Ethereum cannot pay a revocation fee on BNB Smart Chain, even if the wallet address looks identical.

A failed revocation does not remove access. Check its status on the correct explorer and confirm the allowance afterward. Avoid repeatedly submitting replacements without understanding nonce and fee conditions.

What revocation cannot repair

Revocation is preventive from the point it confirms. It cannot reverse a completed malicious transfer, cancel an unrelated approval on another network or invalidate a leaked recovery phrase. It also does not disconnect a browser session automatically.

If assets have already moved, preserve transaction hashes and examine which permissions remain. If the recovery phrase or private key was disclosed, revoking approvals on the compromised wallet is not a complete solution because the attacker can sign directly as the owner.

How to verify a dApp before connecting

  1. Reach the project through a saved bookmark or independently verified official source.
  2. Compare the complete domain, including spelling and top-level domain.
  3. Avoid sponsored search results and links sent by unsolicited support accounts.
  4. Check whether the requested network matches the service being used.
  5. Confirm relevant contract addresses through the project’s established documentation.
  6. Use a separate low-value wallet for experimental applications.

A padlock icon only means the connection to that domain uses HTTPS. It does not prove that the domain belongs to the real project. A copied interface can look perfect while directing signatures to an attacker contract.

Read the confirmation screen as a change list

Before signing, translate the prompt into a plain-language sentence: “This account will allow contract X to spend amount Y of token Z on network N,” or “This account will send amount Y to address X.” If that sentence cannot be formed from the available details, the request is not understood well enough to approve.

Review the selected account, network, asset, amount, recipient or spender, contract method, expected received assets and network fee. Watch for multiple actions bundled into one flow. A visible mint or claim label on the website does not control what the signed transaction actually executes.

Pre-sign checklist

  • The active Trust Wallet account is the intended one.
  • The network matches the dApp and intended asset.
  • The complete domain was reached independently.
  • The recipient or spender is expected and verified.
  • The token and amount are correct.
  • The approval is limited where practical.
  • The decoded action matches the purpose described by the dApp.
  • The gas fee and expected output are acceptable.
  • No Scanner warning remains unexplained.

What to do with a high-risk warning

Reject the request and leave the site. Do not follow troubleshooting instructions supplied by the same page that triggered the warning. Record the domain, network and requested contract address without signing, then compare them with official sources from a separate browser session.

If the project claims a false positive, wait for a verifiable public explanation and updated official documentation. Urgency is not evidence. A legitimate opportunity can still be unsafe while a compromised site or contract is under investigation.

Unknown or medium risk still requires a decision

An unknown contract may simply be new, but newness means reputation data is limited. A medium-risk label is not a numerical statement that a transaction is “half safe.” Determine the flagged behavior and whether it is necessary for the intended action.

For a new protocol, consider a separate wallet funded only with the amount required for the test plus gas. This limits impact but does not convert a malicious transaction into a safe one. Do not use the same wallet that stores long-term assets or valuable approvals.

Address poisoning targets transaction-history habits

In an address-poisoning attack, a scammer creates an address resembling one the victim previously used and places it in transaction history through a small transfer or zero-value token event. Later, the victim copies the familiar-looking address from history and sends assets to the attacker.

Matching the first and last few characters is insufficient because the attacker deliberately optimizes those visible fragments. Obtain a fresh deposit address from the intended recipient and compare the complete value. For repeated destinations, save an address-book entry only after full independent verification.

A token name and icon do not identify a contract

Anyone can deploy a token using a familiar name, ticker or copied logo. The meaningful identifier is the contract address on the correct network. Even an accurately identified token may still have dangerous owner privileges, transfer restrictions, concentrated supply or inadequate liquidity.

Scanner information can highlight known problems, but it is not investment research. Do not infer that a token is economically sound because the wallet displays a price or no warning.

Unexpected NFTs and claim links

Spam collectibles can include a website, QR code or reward message intended to lead the holder into a malicious signature. Receiving an NFT does not give its sender control of the wallet. The risk usually begins when the user visits its link, connects, signs or tries to “unlock” value.

Hide or report unwanted assets using current wallet controls when available. Do not interact merely to remove the item. Verify real claims through independent project channels, never through metadata embedded by the unknown asset creator.

Security Scanner and App Lock solve different problems

App Lock and biometrics help prevent someone with physical device access from opening the wallet or authorizing actions. Security Scanner evaluates supported transaction risks. Neither replaces the other, and neither protects a recovery phrase voluntarily entered into a phishing site.

Enable authentication for app access and transaction signing where supported. Use a strong device passcode, current operating system and verified Trust Wallet build. Device security, secret backup and transaction review are separate layers.

Security Scanner and MEV Protection solve different problems

Security Scanner focuses on suspicious addresses, contracts, tokens and transaction risks. MEV Protection aims to reduce exposure of eligible swaps to public-mempool ordering attacks. A protected route can still interact with a bad token, and a legitimate transaction can still receive a malicious-address warning.

Likewise, Scanner does not remove slippage, price impact, token taxes or liquidity risk. The separate Trust Wallet MEV guide on this site covers those swap-execution questions.

Disconnecting versus revoking

Action What it changes What may remain
Close the dApp Ends the visible browser session Connection records and onchain approvals
Disconnect session Stops that connection from requesting through the session Token allowances and past signatures
Revoke approval Changes a specific onchain allowance or operator permission Other tokens, networks and sessions
Move assets to a new wallet Reduces assets controlled by old keys after confirmation History, dust, approvals and any assets left behind

Response level 1: only the site was opened

If no wallet was connected and nothing was signed, close the site and clear any downloaded file. If credentials or secrets were not entered, onchain authority was not granted merely by viewing a webpage. Still review the browser for an installed extension or unexpected download.

Response level 2: the wallet was connected

Disconnect the dApp session through the current Trust Wallet interface. Review whether any signature or transaction followed the connection. A connection alone normally does not permit token transfer, but it may expose the public address and enable further targeted phishing.

Response level 3: a message was signed

Save the domain, time and signed data. Determine whether it was a simple login challenge, structured authorization or permit. If the content cannot be decoded, treat the risk seriously and consult reliable technical help without sharing private keys. Review token movements and approvals associated with the address.

Response level 4: a token approval was granted

Identify the network, token, spender and allowance. Revoke the relevant approval using Trust Wallet’s built-in view when supported, and confirm the revocation on the correct explorer. Check for approvals on other tokens and networks because phishing flows can request more than one permission.

If a valuable balance is immediately exposed and the spender is believed malicious, prioritize moving unaffected assets to a securely created wallet while accounting for gas, pending attacker activity and approval scope. Avoid signing additional “rescue” transactions supplied by strangers.

Response level 5: a malicious transaction confirmed

Confirmed blockchain transfers are generally irreversible. Record the transaction hash, destination, contract calls, token movements and timestamp. Revoke remaining approvals when doing so does not create additional risk, and migrate assets still controlled by uncompromised keys.

Report the relevant domain and addresses through official channels. Be suspicious of recovery services demanding an upfront fee or seed phrase. Publicly visible stolen funds do not mean a person claiming to trace them can recover them.

Response level 6: recovery phrase or private key was exposed

Treat every account derived from that secret as compromised. Create a completely new wallet with new recovery material on a trusted, updated device. Verify the new backup offline, then move remaining assets to addresses controlled by the new wallet.

Changing the Trust Wallet app passcode does not rotate blockchain keys. Deleting the phishing app or revoking token approvals also cannot prevent an attacker who knows the private key from signing as the owner. Do not reuse the exposed phrase.

Practical scenario: a mint requests unlimited token access

A page advertised as a free mint asks for unlimited access to a valuable fungible token. The request does not match the visible purpose: receiving an NFT should not ordinarily require broad spending authority over an unrelated token. Reject the approval, verify the project’s real domain and contract, and report the page if it is impersonating a known collection.

Practical scenario: Scanner is quiet but the recipient changed

A transfer preview has no warning, yet the destination differs from the address supplied by the intended exchange. The absence of a flag is irrelevant—the request fails the user’s own verification. Reject it, obtain a fresh address from the exchange deposit screen and investigate clipboard malware or address substitution before trying again.

Practical scenario: the dApp says to ignore the warning

A website displays instructions claiming that Trust Wallet always produces a false positive and asks the user to continue. The warning and that pressure are independent reasons to stop. A legitimate project should be able to publish verifiable contract addresses and explain the requested permission without requiring immediate action.

Practical scenario: revoke transaction remains pending

Check the transaction on the correct explorer. Confirm the sender, nonce and gas conditions. Do not assume the allowance is removed until the revocation confirms and the approval view reflects the change. If another transaction with the same nonce replaced it, inspect which transaction actually confirmed.

Common Trust Wallet signing mistakes

  • Treating every Connect request as harmless.
  • Signing unreadable data because no network fee is displayed.
  • Approving an unlimited allowance for a one-time task.
  • Believing disconnect automatically revokes permissions.
  • Ignoring a Scanner warning because a chat administrator says it is safe.
  • Assuming no warning is equivalent to an audit or guarantee.
  • Copying a destination from transaction history.
  • Comparing only shortened address fragments.
  • Using a valuable main wallet to test an unknown dApp.
  • Entering a recovery phrase into an alleged scanner or support form.

A monthly Trust Wallet security review

  1. Install official application and operating-system updates.
  2. Review connected dApp and WalletConnect sessions.
  3. Open Approvals for each actively used account and supported network.
  4. Revoke obsolete or unknown allowances after verifying gas and scope.
  5. Inspect recent transactions for unrecognized recipients or contracts.
  6. Review saved address-book entries against their authoritative sources.
  7. Confirm App Lock, device security and offline recovery readiness.
  8. Separate long-term storage from experimental dApp activity.

Frequently asked questions

Does Trust Wallet Security Scanner guarantee a transaction is safe?

No. It provides risk information and warnings for supported flows. New threats, legitimate-but-risky transactions and user errors can remain, so independent review is still necessary.

Should I continue after a malicious dApp warning?

No. Reject the request and verify the domain and contract independently. Do not rely on explanations supplied by the flagged page.

Does disconnecting a dApp revoke token approvals?

No. Disconnection ends a session; an onchain allowance remains until it is changed or revoked on the relevant network.

Why does revoking an approval cost gas?

Revocation changes blockchain state, so the network requires its native gas coin. Check that the transaction confirms before assuming the permission is removed.

Can a signature move funds without a normal transfer screen?

Some structured signatures can authorize later actions such as token spending. Read the domain, spender, amount, nonce and deadline rather than assuming a gasless message is harmless.

What if I approved a suspicious token but no funds moved?

Identify and revoke the allowance promptly, then monitor the address. Check other tokens and networks for related permissions.

Can Trust Wallet recover assets sent through a malicious transaction?

Trust Wallet is self-custodial and generally cannot reverse confirmed blockchain transactions. Preserve evidence, secure remaining assets and report the incident through official channels.

Is a displayed token price proof that a token is legitimate?

No. Names, tickers, logos and displayed prices can be misleading. Verify the exact contract and independently assess liquidity and contract risk.

Final transaction-review checklist

  • Open Trust Wallet and the dApp through verified official channels.
  • Confirm the active account and network.
  • Classify the request: connect, message, approval or transaction.
  • Verify the full recipient or spender address.
  • Check the token, amount, allowance and expected result.
  • Reject warnings that cannot be independently resolved.
  • Do not treat a quiet Scanner result as a guarantee.
  • Use limited approvals and a separate activity wallet where practical.
  • Confirm revocations and transfers on the correct explorer.
  • Never disclose a recovery phrase or private key to scan, verify or recover a wallet.

Final takeaway

Trust Wallet Security Scanner adds an important layer between a deceptive request and an irreversible signature, but the strongest protection is a repeatable review process. Identify the type of request, verify the domain and network, translate the transaction into plain language and confirm every recipient, spender, token and amount. Reject unexplained warnings, limit persistent permissions and separate experimental activity from long-term storage. After a mistake, respond according to the authority actually granted—connection, signature, approval, confirmed transaction or exposed key—rather than treating every incident as the same.

Official Trust Wallet sources and further reading

Visit Trust Wallet ↗Official website