Trustwallet connects to dApps through compatible networks and signing methods
Trustwallet uses WalletConnect to connect its mobile app with decentralized applications (dApps) on compatible networks. Signing through that connection requires a network and request method both the wallet interface and dApp support. A visible token balance establishes neither compatibility with the application nor permission to spend through its contracts.
The dApp supplies the interface, the wallet handles authorization, and the blockchain executes on-chain requests. Problems can arise at any of these layers, so the available access route matters alongside the selected network.
The dApp Interface and Wallet Connection
In-wallet browsing opens application websites inside the mobile app, while WalletConnect links an external website to the mobile wallet. The browser extension provides another connection route from a desktop browser. These interfaces let applications request access to an account and ask the wallet to sign supported operations. The application defines the activity, such as interacting with a trading contract or accessing a non-fungible token (NFT) service. The wallet supplies signing access; it does not implement every function the application might offer. Application support, connection support, and blockchain execution therefore remain separate requirements.
Read-only application views can work without wallet signing. Actions requiring a signature need access to an account capable of signing.
Network Support Along Each Access Route
The mobile WalletConnect integration supports Ethereum, Ethereum Virtual Machine (EVM) chains, and Solana. That coverage describes this connection method, not every network the wallet can manage. Some networks lost built-in support on September 15, 2026. Affected EVM networks such as Aurora can be added as custom networks using trusted parameters and RPC endpoints; affected non-EVM networks such as Stride require another compatible wallet. In-wallet browser integrations also provide interfaces for Cosmos and Aptos applications. Those interfaces use different network APIs, so their availability does not establish identical support through WalletConnect. A network appearing in the asset list means the wallet can manage supported assets there; a dApp connection needs an applicable interface for the operation it requests.
A multichain application may offer several deployments. Its selected deployment must match the wallet connection's chain. Switching the displayed application network changes which deployment is relevant, without transferring assets between blockchains.
Signing Methods Within the Session
WalletConnect sessions define the accounts and operations a dApp can request, with permissions negotiated when the connection is established. A WalletConnect session limits chain-specific requests to the networks its permissions authorize. Signing methods describe the operation the wallet must perform: signing a message differs from authorizing a transaction. Support for one method does not establish support for every other method on that chain. A dApp requesting an unavailable method can therefore encounter a compatibility error even when its network is supported.
Adding an account or chain outside an existing session's permissions requires an appropriate session update or a new approved session. Session updates depend on the wallet and dApp implementing that part of WalletConnect. The integration must handle permission changes and keep its account and network state synchronized with the wallet.
QR Codes and Mobile Deep Links
WalletConnect uses QR codes and deep links to carry pairing information between the dApp and the mobile wallet. A QR code suits a website open on another screen; a deep link can open the wallet from a mobile browser. Both routes still require an accepted session proposal. Merely opening the wallet does not establish approval. Browser restrictions can block a popup used to open the wallet. On iOS Safari, that popup must open directly in response to a user gesture. That browser behavior differs from an unsupported blockchain.
In-Wallet Browsing and Desktop Extensions
The in-wallet browser gives compatible dApps direct access to the wallet's supported provider interfaces, avoiding an external-browser handoff. A provider is the interface an application uses to request accounts and signing operations. The site must recognize the relevant interface and handle its network's request format. Opening a page inside the wallet does not supply missing application code.
The desktop extension exposes its own supported network interfaces to websites running in the browser. Its integration coverage includes Ethereum-compatible chains, Bitcoin, Solana, Tron, and TON. These networks require their respective integration methods; an Ethereum interface cannot automatically serve all of them. Choosing desktop access changes the connection interface, without making an unsupported dApp operation available.
The Active Account and Chain
The connected account and selected chain determine the balances and contract state relevant to the dApp's activity. A wallet may contain multiple accounts, while the session exposes only its approved account set. A site showing a different account can therefore show different holdings even if the wallet's overall portfolio looks familiar. Wallet and application network selections must also agree. The same address format can appear on different EVM chains, so matching address text alone does not identify the blockchain containing the required balance.
Token Contracts and Fee Funding
A dApp needs the specific asset its contracts accept on the selected network, not simply a matching token name. For contract-based tokens, the network and token contract identify the relevant asset. Adding a custom token to the wallet improves its display and management on a supported network. That addition does not deploy the token into a different application, move a balance across chains, or add a missing signing method. A dApp can recognize an asset independently of whether the wallet currently displays it in the portfolio.
On-chain activity also needs a valid fee-payment arrangement for that network. Standard transactions generally use the chain's native asset for fees, while supported alternatives can change the payment asset. Trustwallet's FlexGas applies to supported sending and swapping actions; its availability there does not establish support for every external dApp request. The applicable fee method belongs to the specific operation, rather than the wallet's combined portfolio value.
Connection Approval and On-Chain Execution
Connection approval permits communication with the agreed account, while an application's on-chain operation needs the relevant authorization and successful execution. A connected indicator establishes a session, not a completed contract action.
Message signatures can authenticate an account without broadcasting a blockchain transaction. Their meaning depends on the signed content. For tokens implementing a permit mechanism, a signed message can authorize a spending allowance for later on-chain submission. A request labelled as a signature therefore deserves review even when signing itself incurs no network fee.
Token spending approvals have a different scope from session permissions. An ERC-20 allowance authorizes a particular spender to transfer that token up to the allowance. Granting it establishes spending authority; it does not prove a later swap or deposit succeeded.
Transaction signing authorizes transaction data, and submission sends it for network processing. A returned transaction identifier alone does not establish successful execution. The chain's transaction result determines whether the contract action succeeded or failed.
A pending transaction has no confirmed execution result; a failed transaction did not complete the requested contract action. Application-specific completion can also require additional processing beyond the first transaction.
Transport Errors and Unsupported Requests
A connection failure can arise from the browser handoff, session state, missing authorization, or an unsupported chain or method. These causes require different responses. A website failing to open the mobile app presents a different problem from a wallet rejecting the requested network. An approved connection can also coexist with a failed later request. When a dApp surfaces EIP-1193 provider errors, code 4200 means an unsupported method, while 4901 means the provider is connected to another chain but not the requested one. A rejected request or missing account permission calls for a different response.
Refreshing a connection can clear stale session state. It cannot add a signing method or network the selected interface does not support.
After submission, a request may instead fail during blockchain execution. Session renewal does not repair a contract's failed conditions, and repeated authorization can produce additional requests. Diagnosis needs the actual request state, not only the website's connected indicator.
A Mobile dApp Compatibility Checklist
Before connecting an external dApp to the mobile wallet, establish whether its required network and request methods work through WalletConnect. If you plan to trade a token, the account holding the dApp's accepted asset must be available for approval on the selected network.
- Confirm the application's selected network is supported through the mobile WalletConnect integration.
- Check the dApp offers WalletConnect for that network, rather than only an incompatible browser interface.
- Confirm the intended account is available for the connection and can sign any requested operation.
- Review the requested accounts, networks, and signing methods before approving the session.
- For on-chain activity, confirm the accepted asset and fee-payment requirements on the selected network.
When those requirements match, the dApp proposes a connection and the wallet presents its approval request. After approval, the website can show the agreed account and send permitted requests. That visible account confirms the connection context; a later operation still requires its own applicable authorization.
If the route lacks a required chain or method, stop before approving an unrelated network. Another wallet interface is a fallback only when it supports the same operation on the required network. Otherwise, compatible wallet or dApp integration support is necessary. A fresh session can resolve stale permissions, but repeated QR scans cannot supply an absent capability.
Session Disconnection and Contract Allowances
Disconnecting a WalletConnect session ends that connection, while token spending allowances remain part of the relevant blockchain's contract state. Closing a website alone does not establish either session disconnection or allowance revocation. The wallet provides controls for viewing and disconnecting active WalletConnect sessions. Its approval-management feature separately supports reviewing and revoking token permissions. Those controls address different forms of access, and a particular permission belongs to its token, spender, account, and network.
A confirmed allowance change affects the spender's future token access. It does not reverse transfers the contract already completed.
Permission review remains relevant even when a dApp no longer connects or its website becomes unavailable. Keep an allowance only when you still intend that spender to use the particular token; ending the session serves a separate purpose.
Trustwallet - your questions answered
Does Connecting a dApp to Trustwallet Require My Recovery Phrase?
A dApp connection does not require your recovery phrase or private keys. WalletConnect passes connection and signing requests to the wallet, which retains the secret material needed to authorize them. A website asking you to enter a recovery phrase to connect, synchronize, or validate the wallet is seeking access beyond an ordinary dApp session.
What Can a Connected dApp Learn From My Public Address?
A connected dApp can learn the accounts you approve for the session and examine their publicly accessible blockchain activity. Depending on the network, that can include token balances, transfers, and contract interactions. Disconnecting limits the active wallet connection, but it does not erase public records or information the site already associated with an address.
Are Required and Optional WalletConnect Networks Treated Differently?
Required networks and methods must be satisfied for a WalletConnect session proposal to succeed. The wallet may approve some, all, or none of the optional permissions. An application can therefore connect with reduced optional coverage, while a missing required network prevents that proposal from succeeding. The dApp decides which requirements its connection proposal makes mandatory.
How Does a Trustwallet WalletConnect Connection Affect Network Fees?
Establishing a WalletConnect session does not itself create a blockchain transaction or network gas charge. A dApp can subsequently request a transaction, which brings that network's applicable fee requirements. Any application or service charges belong to the requested activity.
Is a Missing Trustwallet Security Scanner Warning Proof a dApp Is Safe?
The absence of a Security Scanner warning does not prove a dApp or signing request is safe. The scanner identifies risk signals on supported networks, including known suspicious destinations and dangerous permissions. Off-chain messages, including permit approvals and marketplace order signatures, may not be fully covered by transaction simulation. Review the actual request's recipient, spending authority, and operation even when no warning appears.
When Must I Approve a New WalletConnect Session in Trustwallet?
An expired WalletConnect session needs a new approved session before requests can continue through that connection. A successful extension can keep an existing session active where the wallet and dApp implement that feature. An earlier approval does not authorize a replacement session automatically. Ending or replacing the connection also leaves existing on-chain token allowances unchanged.