Custody model
Self-custody
The user controls the recovery phrase and transaction authority.
T
Self-custody wallet · Evidence assessment
Trust Wallet
Multi-chain self-custody software wallet
Trust Wallet provides broad multi-chain access through mobile and browser products. The decision turns on recovery discipline, extension security, third-party transaction routes and whether breadth is worth the larger integration surface.
Evidence state
Public sources reviewed
Assessment reflects the cited public record and product documents.
Decision focus
Multi-chain surface and release security
Chain coverage claims need product-scope and version context.
Editorial assessment
The decision in plain language.
Trust Wallet is a practical option for users who value multi-chain breadth, but it should be adopted with a conservative recovery and extension-update routine. The December 2025 browser-extension incident is a central part of the current assessment, not a footnote.
Best suited to
Users who want a broad multi-chain wallet and understand that they—not the provider—must safeguard recovery material.
Primary trade-off
Wide network and dapp coverage increases convenience while expanding integration, signing and release risk.
Evidence-backed strengths
- Clear self-custody model with documented recovery options.
- Broad chain and application access across mobile and browser surfaces.
- The Wallet Core library is public under an Apache licence, giving researchers a useful technical artefact.
"Limitations to resolve"
- Losing or exposing the recovery phrase can be irreversible.
- A malicious browser-extension release in December 2025 caused material losses and an ongoing reimbursement process.
- No added wallet fee does not mean swaps, bridges or transfers are cost-free.
Evidence review
What the public record currently supports.
Each conclusion is bounded by its product, jurisdiction and source type.
01Evidence reviewed
Recovery is the security boundary
Trust Wallet documents a 12-word recovery phrase and optional encrypted cloud backup. Those paths have different dependencies, but both leave the user responsible for protecting access and rejecting anyone who asks for the phrase.
02Evidence reviewed
Breadth needs scope
Trust Wallet markets support for more than 100 blockchains, while the Wallet Core library documents a different technical coverage figure. These statements refer to different product layers and should not be presented as interchangeable.
03Evidence reviewed
Fees belong to the full route
Trust Wallet says it does not add a wallet fee for ordinary use, but network fees, exchange-provider pricing, bridge costs and slippage still affect the outcome. The displayed quote and destination amount matter more than a 'free wallet' label.
04Evidence reviewed
Privacy and controller
The reviewed privacy notice identifies Dapps Platform Bahrain W.L.L. as controller and describes data categories and service providers. Self-custody limits one type of control but does not automatically remove analytics or third-party data flows.
05Evidence reviewed
Incident record
Trust Wallet says browser extension version 2.68 was malicious and affected users, and its July 2026 update reported 2,520 addresses and approximately $8.5 million while reimbursement and investigation continued. Users should verify extension provenance and current incident guidance before installation.
Decision dossier
From evidence to an accountable decision.
Ten separate modules prevent product scope, legal status, cost, control and remedy from collapsing into one brand impression. Sources were retrieved on .
Answer first
Trust Wallet is a practical multi-chain choice for users who will protect a recovery phrase, verify the official distribution channel and treat every dapp approval as an irreversible instruction. Its breadth is valuable, but the extension-release incident raises the importance of version provenance.
Source register · retrieved 17 Aug 2026Who should not choose it
It is a poor fit for anyone who expects support to restore a lost phrase, assumes optional cloud backup removes recovery risk, or chooses a wallet by chain count without checking the exact app, version and action.
Source register · retrieved 17 Aug 2026Product and legal-entity scope
Mobile app, browser extension and the Wallet Core library are related but not interchangeable. Wallet Core’s Apache-2.0 repository is inspectable evidence for a component, not proof that every interface, backend or store binary has identical scope.
Source register · retrieved 17 Aug 2026Custody and security controls
The conventional 12-word phrase controls recovery; optional encrypted cloud backup moves part of the risk into cloud credentials and service dependencies. Release provenance, signing clarity and extension updates are as important as seed storage.
Source register · retrieved 17 Aug 2026Regulation and customer protection
Self-custody does not create exchange-like asset protection or a provider-funded recovery right. Third-party swap, bridge, purchase or dapp services must be evaluated separately for entity, permissions and remedy.
Source register · retrieved 17 Aug 2026Fees and total-cost recipe
For one fixed swap, record the amount sent, route, liquidity source, service/bridge charge if any, network fee, slippage tolerance and minimum/final amount received. ‘No extra wallet fee’ describes only one component of the receipt.
Source register · retrieved 17 Aug 2026Funding, withdrawal and exit
The wallet can receive and send across supported networks, but wrong-network and address mistakes may be irreversible. A controlled route should verify chain identifiers, token contract, destination support and finality before any material transfer.
Source register · retrieved 17 Aug 2026Execution, API or wallet permissions
Tests should focus on transaction simulation, spending approvals, dapp connections, chain switching and the consistency of mobile versus extension prompts. Wallet Core support for a chain does not guarantee the consumer interface exposes every action.
Source register · retrieved 17 Aug 2026Privacy and telemetry
The privacy notice and third-party services should be mapped by app surface. Self-custody limits provider key control but does not eliminate IP, device, analytics, address or transaction data exposed to RPCs and integrated services.
Source register · retrieved 17 Aug 2026Support and dispute route
Support cannot safely request the recovery phrase or reverse a valid chain transaction. Incident and reimbursement questions should use official case channels, preserve reference numbers and distinguish version-specific harm from general product support.
Source register · retrieved 17 Aug 2026Fit boundary
Four situations, before a brand preference.
Broad multi-chain access matters and you can manage recovery securely.
The wallet is designed around a wide chain surface and user-held signing control.
You verify official distribution and exact version before updating.
Provenance discipline directly addresses the disclosed extension risk.
You expect support to restore a lost phrase or reverse a transfer.
The self-custody responsibility boundary prevents either promise.
You equate component source availability with full app assurance.
Wallet Core does not prove every interface, backend or distributed binary.
Reproducible scenarios
The next evidence, already specified.
These are protocols, not claimed results. Inputs remain fixed so later observations can be repeated or challenged.
Recovery path comparison
Fixed inputs: Disposable wallet with conventional phrase and, separately, optional backup path if available; no valuable assets.
Capture: Dependencies, warnings, recovery success, cloud-account exposure and imported-account boundary.
Mobile versus extension signing
Fixed inputs: Same controlled approval and transfer on current official builds.
Capture: Version provenance, spender/amount display, simulation, warning, rejection and revocation path.
Multi-chain total-cost route
Fixed inputs: One source token, destination token, amount, network and observation window.
Capture: Provider route, service/bridge fee, gas, slippage, minimum received and final chain result.
Incident-support and provenance
Fixed inputs: Current official extension build, saved store/release identifiers and a non-sensitive incident-policy question.
Capture: Binary provenance, version warning, case ownership, reimbursement-policy explanation and official escalation route.
Incident and change timeline
What changed the risk picture.
- Trust Wallet identified browser extension version 2.68 as malicious.
Official-channel and exact-version checks are direct asset controls, not housekeeping.
- A provider update reported 2,520 drained addresses and about USD 8.5 million affected.
The event remains material to release governance and remedy assessment while staying bounded to the disclosed extension incident.
- Privacy, recovery, repository, fee and incident sources re-retrieved.
A fresh mobile/extension scenario run is still required before rating.
Alternatives
Choose by responsibility, not fame.
MetaMask
EVM dapp conventions, hardware-wallet use and granular EVM workflows matter more than broad chain coverage.
Hardware wallet
Offline key isolation is more important than a mobile-first multi-chain interface.
Evidence confidence
Medium confidence, with a visible stop gate.
- Supported
- Official recovery, privacy and incident materials plus the Wallet Core repository support the current boundaries.
- Unresolved
- Current app/extension provenance, signing UX, data flows, route costs and incident remedy outcomes are the variables most likely to change the conclusion.
- What would change the conclusion
- Verified release-control improvements and strong cross-surface signing tests could raise confidence; another distribution failure or misleading recovery/fee behaviour would lower it.
Method applied
How this file is challenged.
- Name mobile, extension or Wallet Core and record the exact version.
- Use disposable wallets to test recovery and signing.
- Trace route fees and data recipients end to end.
- Bound incident conclusions to the disclosed build, affected surface and update date.
Dossier change log
Material editorial changes.
Added release-provenance, recovery-responsibility, multi-chain cost and incident-remedy decision chains with specified controlled protocols.
FAQ
Questions that decide whether the product fits.
Can Trust Wallet restore a lost recovery phrase?
Not through ordinary provider support. Optional backup changes the dependency path but does not remove compromise or loss risk.
Was every Trust Wallet user affected by v2.68?
No. The provider disclosure concerns a named browser-extension version; conclusions should not be expanded to every mobile user.
Does open-source Wallet Core prove the whole app?
No. It is valuable component evidence, not full binary or service provenance.
Is optional cloud backup automatically safer?
It can reduce one loss path while adding cloud-account and service dependencies. The right choice depends on the user’s threat model and recovery discipline.
Applicable scorecard
Self-custody wallet scoring framework.
Weights are published in advance. An evidence gate can still block the final calculation.
Source register
Documents behind the assessment.
Primary records establish legal and regulatory facts. Product documents establish current contractual or functional claims; they do not prove solvency or future performance.
S01
Trust Wallet — privacy noticeContract / product document · checked 18 Aug 2026
S02Trust Wallet — seed phrase lifecycleContract / product document · checked 18 Aug 2026
S03Trust Wallet Core repositoryIndependent technical record · checked 18 Aug 2026
S04Trust Wallet — product FAQContract / product document · checked 18 Aug 2026
S05Trust Wallet — security overviewProvider claim · checked 18 Aug 2026
S06Trust Wallet — browser extension v2.68 incident updatePrimary record · checked 18 Aug 2026
Change control
Assessment history.
Material changes remain visible. A log entry records editorial work and the evidence behind each change.
C01
· Editorial assessment updated from cited primary records and product documentation.