Web Radio

A user deposits funds to an Arbitrum or Optimism address, receives confirmation that the transaction succeeded, then opens Trezor Suite to check the portfolio. The balance shown is zero. The address exists on-chain, the transaction is irreversible, but the wallet displays nothing. This is not a loss of funds; the assets are secure on the hardware device. The problem is visibility: Trezor Suite is not connecting to the right network endpoint, or the application has not been configured to recognize Layer 2 assets at all.

Layer 2 networks like Arbitrum, Optimism, and Polygon exist as separate blockchain systems that settle to Ethereum but maintain their own transaction history, token balances, and smart contracts. Trezor Suite, as a non-custodial application managing private keys stored on hardware, must connect to appropriate RPC endpoints to retrieve balances and construct transactions. When those connections fail, when endpoints are misconfigured, or when a network is not yet fully integrated, assets become invisible despite being perfectly secure. Understanding the distinction between a display problem and an actual security problem is essential for recovering access and preventing panic.

How Trezor Suite discovers and displays Layer 2 balances

Trezor Suite is built around a principle of key isolation: the private keys that control your cryptocurrency remain stored exclusively on the hardware device. The application itself is stateless with respect to secret material; it never sees, stores, or handles private keys. Instead, it performs two separate functions. First, it queries blockchain data—asking “what is the balance at this address?”—through RPC endpoints. Second, when you approve a transaction, Trezor Suite sends that transaction data to the hardware device, where the device signs it using the private key, and returns only the signed transaction ready for broadcast.

For Ethereum and Layer 1 assets, this process is straightforward. Trezor Suite connects to a standard Ethereum RPC, queries the address balance, and displays the result. Layer 2 networks complicate this because they are separate chains. A Bitcoin address on the Arbitrum network is a different ledger entry than the same address on Optimism or Polygon. Trezor Suite must know which network to query and must be able to construct transactions according to that network’s specific rules. If the application is not configured to recognize a given Layer 2, or if its RPC endpoint for that network is unreachable or misconfigured, the balance will not appear even though the funds exist on-chain.

The recovery of an address derived from your Trezor’s seed phrase is deterministic. The same seed phrase, on any compatible device or application, will always generate the same addresses in the same order. That means your Layer 2 funds are never lost; they are simply not being displayed by the current configuration. The practical consequence is that visibility and accessibility can be restored by correcting the network settings, changing the RPC endpoint, or using an alternative wallet application that has proper Layer 2 support.

RPC endpoints: why the network connection matters more than you think

An RPC endpoint is essentially a server that holds a complete copy of a blockchain and responds to queries about balances, transaction history, and the state of smart contracts. Trezor Suite, like any blockchain wallet application, must connect to at least one working RPC endpoint for each network you use. For Layer 2 networks, the endpoint must be specifically configured for that chain—an Arbitrum endpoint cannot query Optimism balances, and an Optimism endpoint will not see Polygon transactions.

Trezor Suite includes built-in RPC endpoints for commonly supported networks. These are curated by Trezor and selected for reliability, but they are not infinite resources. If many users connect simultaneously, an endpoint can become slow or rate-limited. More commonly, an RPC endpoint may become temporarily unreachable due to maintenance, provider outages, or network congestion. When this happens, the wallet cannot retrieve balance information and displays zero or a stale cached value. This is not a permanent problem, but it creates the impression that your funds have disappeared.

The solution is to verify that the RPC endpoint is working and to switch to an alternative if needed. Trezor Suite allows users to configure custom RPC endpoints, which is essential if the default endpoint is unreliable or if you are using a network that Trezor has not yet fully integrated. Services like Alchemy, Infura, QuickNode, and various public endpoint providers offer Layer 2 RPCs. Confirming that your chosen endpoint is currently synchronizing the network and responding to queries is a critical troubleshooting step that many users skip.

Layer 2 network configuration in Trezor Suite

Trezor Suite’s desktop application provides direct access to network settings, while the mobile version is more limited. On desktop, you can access the Settings panel and navigate to the network or RPC configuration section. For fully supported networks like Arbitrum, Optimism, and Polygon, the application should automatically include default endpoints. However, if these endpoints are not responding, or if you are using a less common Layer 2 (such as Zksync, StarkNet, or a new rollup), you may need to add a custom network.

The manual configuration process requires specific details: the network name, chain ID, RPC URL, and optionally the block explorer URL and native currency symbol. Getting any of these wrong will cause balance queries to fail silently. A common error is using an HTTP endpoint when the RPC provider requires HTTPS, or providing an endpoint that is not actually synchronized. Before adding a custom network, verify that the endpoint is live and responding by testing it directly, either through a separate tool or by checking the provider’s status page.

If your Layer 2 network is not listed at all in Trezor Suite, the application may not yet support deriving addresses on that specific chain. In this case, the funds are still secured by your hardware device, but you cannot access them through Trezor Suite. The alternative is to use a Trezor Suite download of the latest version to ensure you have the most recent network support, or to import your Trezor’s recovery seed into a compatible third-party wallet that does support the desired Layer 2. Be extremely cautious when entering a recovery seed into any application other than a hardware wallet; doing so exposes your private keys to internet-connected software and should only be considered a temporary measure to access funds before returning them to secure custody.

Manual address recovery and balance verification on-chain

If Trezor Suite continues to show zero balance despite network configuration changes, a practical approach is to verify the balance directly on-chain without relying on the wallet application. You can take your receiving address (which you can generate through Trezor Suite or retrieve from your transaction history) and check it on the appropriate Layer 2 block explorer. For Arbitrum, Etherscan provides an Arbitrum explorer. For Optimism, the Optimism Explorer displays all transactions and balances. For Polygon, Polygonscan serves this purpose.

Paste your address into the explorer and confirm that the balance is nonzero and that your deposit transaction appears in the history. If the balance is confirmed on the public explorer but Trezor Suite shows zero, the problem is definitely with the wallet’s network configuration or RPC endpoint. If the explorer also shows zero, the funds were never received—check the sending transaction on the originating network to confirm it was routed to the correct Layer 2 address.

Once you have confirmed on-chain that the funds exist, the recovery path is to restore network connectivity in Trezor Suite. Clear any cached data for that network, try a different RPC endpoint, or update the application to the latest version. In some cases, restarting Trezor Suite or even rebooting your computer can help re-establish a working connection. These are not elegant solutions, but they address the most common cause of balance display failures: transient network issues or endpoint misconfiguration.

When a Layer 2 is not yet supported by Trezor

Trezor’s list of supported cryptocurrencies continues to expand, but new Layer 2 networks are launched more quickly than wallets can integrate them. If you have deposited funds to a Layer 2 that Trezor Suite does not recognize, your options are limited but not catastrophic. The funds remain under your hardware device’s control because the address was derived from your seed phrase using standard Ethereum derivation paths (such as BIP-44). However, without proper application support, you cannot easily send or trade those assets from Trezor Suite.

The most direct approach is to wait for Trezor to officially add support for the network, which typically happens within months of a network reaching significant adoption. You can check the Trezor firmware and software roadmap to see what networks are planned. Alternatively, you can import your recovery seed into a compatible wallet that does support the desired Layer 2—MetaMask, Ledger Live (if you own a Ledger device), or other non-custodial applications with broader Layer 2 support can often help. This is a temporary measure; once you have access to your funds, you can move them to a more secure setup or wait for Trezor Suite to add native support.

The time to wait for expanded Layer 2 support depends on your risk tolerance and the amount at stake. Leaving funds on a Layer 2 that your primary wallet does not support means you cannot quickly respond to market movements or security events. If the amount is significant, moving the funds through an intermediate wallet is worth the temporary key exposure risk. If the amount is modest or the Layer 2 is highly secure and well-established (like Arbitrum or Optimism), waiting for Trezor to catch up is reasonable.

Testing Layer 2 access with a small test transaction

Before trusting Trezor Suite to manage a large Layer 2 balance, send a small test amount to your Trezor address on that network and verify that the wallet displays it correctly. This validates that your network configuration is working and that the address derivation is correct. If the test transaction appears on-chain but does not appear in Trezor Suite after several minutes, you have confirmed the display problem and can troubleshoot the RPC endpoint or network settings without risking significant funds.

The test transaction should be large enough to be unmistakable but small enough that loss would not be catastrophic. A typical test amount is 0.01 or 0.001 of a Layer 2’s native currency, plus a small amount of a token if you are testing token balances. Wait at least one full block confirmation on the Layer 2 before concluding that Trezor Suite has failed to display the balance. Network confirmation times vary: Arbitrum and Optimism finalize transactions within seconds, while Polygon may take a few minutes depending on network activity.

If the test balance appears in Trezor Suite, your configuration is correct and you can proceed with larger deposits. If it does not appear, go back through the RPC endpoint configuration, verify the network chain ID, ensure the endpoint is responding to queries, and try a different endpoint provider. Each iteration should be documented so you can pinpoint the exact setting that resolves the issue. Once the test balance appears, repeat the test with a different token or currency to ensure the configuration is robust.

Desktop vs. mobile: feature and integration differences

Trezor Suite’s desktop version, available for Windows, macOS, and Linux, provides the most complete Layer 2 support and the most granular control over network settings. This is where you should perform troubleshooting, add custom RPC endpoints, and test new Layer 2 configurations. The mobile version of Trezor Suite, available on Android and iOS, focuses on core functions: receiving funds, sending transactions, and accessing basic trading features. Mobile Trezor Suite supports some Layer 2 networks, but the list may be smaller and the network configuration options are more limited.

If you are managing Layer 2 assets, use the desktop application as your primary interface. Mobile Trezor Suite can send and receive, but if a Layer 2 network is not yet fully supported or your RPC endpoint is misconfigured, the mobile app will not help you diagnose or fix the problem. The desktop environment gives you the flexibility to switch endpoints, enable custom networks, and verify balances through alternative means if needed. Keep your mobile app updated, but do not rely on it as your sole access point for emerging Layer 2 networks.

Preventing Layer 2 visibility problems before they occur

The best practice is to verify wallet connectivity before you deposit funds to a Layer 2 address. Create a small test deposit and confirm it displays in Trezor Suite on all networks you intend to use regularly. This one-time verification step prevents the panic of discovering that a large deposit is invisible. It also gives you a chance to add custom RPC endpoints, adjust network settings, or decide whether you need to update the application before committing significant funds.

Maintain a list of the RPC endpoints you use for each Layer 2, including backup providers. When your primary endpoint becomes unreliable, switching to a backup endpoint should be a straightforward configuration change. Document which networks and endpoints you have tested, and periodically verify that your primary endpoints are still responding. Layer 2 infrastructure is rapidly improving, but endpoint outages and rate limits remain common disruptions.

Finally, recognize that Layer 2 visibility in Trezor Suite is a convenience feature, not a guarantee. Your funds are secured by the hardware device and the Ethereum blockchain, regardless of whether the wallet application displays them correctly. If Trezor Suite fails to show your Layer 2 balance, the funds are not lost; the application configuration needs adjustment. This distinction between wallet failure and key security allows you to troubleshoot methodically rather than panic.