Blog Details

A cryptocurrency holder managing multiple blockchain networks faces a practical constraint: not every wallet supports every asset. A user with Bitcoin, Ethereum, stablecoins, and emerging layer-2 tokens across different chains needs a single application that recognizes those positions, displays accurate balances, and allows transfers without manually connecting to external interfaces. Trezor Suite is designed to address that requirement by combining hardware-backed key management with a growing list of supported cryptocurrencies and tokens across major blockchains.

The scope of that support matters more than a raw count. A cryptocurrency management application must distinguish between full support—where an asset can be sent, received, and monitored directly—and partial recognition, where a token may be visible but require external tools for certain operations. Understanding which assets Trezor Suite actively supports, how new cryptocurrencies are added to the platform, and how to report missing tokens allows users to plan their portfolio structure and understand when external wallets may be necessary alongside their hardware device.

The core blockchains and cryptocurrencies supported by Trezor Suite

Trezor Suite provides native support for the major proof-of-work and proof-of-stake networks that represent the largest portions of cryptocurrency market capitalization and transaction volume. Bitcoin remains the foundational asset, supported with full send, receive, and address management functionality. Ethereum and its associated ecosystem of ERC-20 tokens constitute the second category, allowing users to interact with smart contract platforms and decentralized finance without exposing private keys to internet-connected machines.

Beyond Bitcoin and Ethereum, Trezor Suite covers several other major layer-1 blockchains including Litecoin, Dogecoin, Ripple (XRP), Bitcoin Cash, Zcash, Dash, and Cardano. Each blockchain presents different transaction structures, address formats, and validation requirements. Trezor Suite’s support means that a user can generate addresses, verify them on the device display, and authorize transfers using the hardware wallet’s signing mechanism without the private key ever leaving the device. The distinction between blockchain wallet capability and mere address recognition is important: true support includes the ability to construct, review, and approve transactions on that chain.

Polygon, Arbitrum, Optimism, Base, and other Ethereum virtual machine-compatible layer-2 networks are supported through Ethereum address derivation and MetaMask integration. Because these networks use the same address space as Ethereum, a single Ethereum account in Trezor Suite can receive assets on multiple networks through address reuse, though best practices often suggest using separate accounts for each chain to simplify monitoring and reduce cross-chain address linking.

Solana support represents a distinct category because it uses a different key derivation standard and address format. Trezor Suite integrates with Solana’s browser-based tools and can authorize transactions through a connected hardware wallet, though the user experience differs slightly from native Bitcoin or Ethereum flows. Staking functionality for Solana, Ethereum, Cardano, and other proof-of-stake networks has been integrated into Trezor Suite’s interface, allowing users to delegate or commit assets for validation rewards while maintaining custody through their hardware device.

ERC-20 token recognition and custom token addition

The majority of tokens built on Ethereum are ERC-20 standard assets created by projects, companies, and protocols operating on the network. Trezor Suite’s approach to these tokens involves a curated list of recognized assets that are displayed automatically when the user’s Ethereum account contains them. Popular tokens such as USDC, USDT, DAI, AAVE, Uniswap, Chainlink, and others are pre-loaded and appear without additional configuration.

However, users working with newer, lower-volume, or community-created ERC-20 tokens may not see them displayed automatically in Trezor Suite. For these cases, the application provides a custom token addition feature. A user can manually enter the contract address of an ERC-20 token, and Trezor Suite will query the blockchain to retrieve the token’s name, symbol, and decimal places. This manual lookup verifies that a valid token exists at the provided address and helps prevent users from adding tokens to a nonexistent or fraudulent contract address.

Once added, a custom token will display in the user’s Ethereum account balance and transaction history. The token will remain visible across sessions if it remains at a non-zero balance. If the user’s balance falls to zero, the token may disappear from the default view, though it can be re-added at any time using the contract address. This design balances interface clarity with user flexibility: users who hold tokens see them automatically, but the application does not clutter the interface with every possible ERC-20 contract.

Custom token support extends to other virtual machine-compatible networks as well. Users holding tokens on Polygon, Arbitrum, or other chains can add them to Trezor Suite using the same contract address mechanism. Because these networks use Ethereum-compatible tooling, the process is nearly identical; what changes is the network selection and the contract address source.

Staking, buying, and selling integrations within Trezor Suite

Beyond basic send and receive, Trezor Suite integrates several cryptocurrency management features that go beyond simple transaction signing. Staking for proof-of-stake networks allows users to lock assets for validation participation and earn rewards, with the interface providing clear information about expected rewards, lock-up periods, and unbonding timelines. Ethereum staking, Cardano delegation, and Solana stake account creation are directly available within Trezor Suite without requiring external platforms.

The buying and selling integrations connect users to third-party exchange services such as CoinJoin providers and regulated on-ramp platforms. A user can purchase Bitcoin, Ethereum, or other supported assets directly from within Trezor Suite using fiat currency, with the incoming assets automatically directed to the hardware wallet. This integration reduces the friction of moving between traditional finance and self-custody, though users should understand that the third-party service providing the exchange may collect identity information, compliance documentation, and maintain records of the transaction.

Swapping capabilities allow users to exchange one supported cryptocurrency for another directly through Trezor Suite’s interface, using decentralized exchanges or routing services to find liquidity. This feature is particularly useful for portfolio rebalancing or converting between assets without exporting keys to an external wallet. The hardware wallet signs the swap transaction, and the exchange occurs on-chain with the user maintaining custody throughout.

These integrations demonstrate the difference between a cryptocurrency management application and a simple wallet interface. Trezor Suite aims to reduce the number of external tools and websites a user must trust, consolidating buying, swaking, staking, and portfolio monitoring into one application that is consistently connected to the user’s hardware device. The trade-off is that each integration introduces a third-party dependency: the exchange service, staking provider, or liquidity source must be reliable and honest about fees and execution.

How cryptocurrency support requests are evaluated and added

Users and projects frequently request that Trezor Suite add support for new blockchains or cryptocurrencies. The process for evaluating these requests involves several criteria beyond merely counting market capitalization or social media mentions. Trezor maintains a public issue tracker and community feedback channels where requests can be submitted, discussed, and tracked. A new cryptocurrency request typically requires evidence of legitimate demand, developer clarity about implementation requirements, and a clear path to testing.

For a new blockchain to receive native support in Trezor Suite, the network must be sufficiently stable and widely used. The Trezor team must develop and audit the coin integration, which involves implementing address generation, transaction construction, and signing according to the blockchain’s protocol specification. This work is non-trivial: each blockchain has its own quirks, upgrade paths, and transaction validation rules. Once developed, the integration must be tested against actual network nodes to ensure that addresses are correctly derived, transactions are properly signed, and funds can be sent and received without error.

New ERC-20 tokens, by contrast, require less direct development effort because Trezor Suite already supports the Ethereum network. Instead, the question is whether a token should be added to the curated list that appears automatically. Trezor’s team evaluates whether a token is widely traded, created by a recognizable entity, and unlikely to be a scam or honeypot. Popular projects and established decentralized finance protocols are typically added relatively quickly, while experimental or low-volume tokens remain in the “custom token” category.

The trezor suite GitHub repository and community forums document the requirements for new coin additions, including specification documents, test vector expectations, and code review processes. Users or project teams can contribute implementations, though Trezor reserves the right to review, modify, or decline changes that do not meet security or quality standards. This open-source approach makes it possible for the community to participate in expanding support, while maintaining centralized control over what enters the official release.

Testing and validating new tokens before requesting official support

A user who holds a token that is not yet in Trezor Suite’s curated list should test its visibility using the custom token addition feature before requesting official support. This process has two benefits: it immediately solves the user’s problem of monitoring their balance, and it helps verify that the token contract is legitimate and functional. If a contract address returns an error when added to Trezor Suite, that is a signal that the address is invalid, the network connection is failing, or the token does not exist.

For project teams requesting that their ERC-20 token be added to Trezor Suite’s default list, Trezor typically requires the following information: the contract address, a public website or documentation, the token’s purpose and use case, exchange listings or trading volume data, and confirmation that the contract has been audited or is from an established organization. Tokens that fail these checks are not automatically rejected; they remain available through custom token addition but do not appear in default lists.

Testing also involves verifying that Trezor Suite correctly displays the token’s balance after a receive transaction confirms, that the transaction history is accurate, and that sending the token to an external address works without error. If issues appear, they should be documented and reported to Trezor’s team rather than assumed to be permanent limitations. Many small bugs or incompatibilities can be fixed in minor updates.

NFT wallet capabilities and limitations in Trezor Suite

Trezor Suite’s handling of non-fungible tokens reflects a design choice distinct from other wallet applications. Unlike some NFT wallet solutions that display galleries of owned NFTs with images and metadata, Trezor Suite does not have a dedicated NFT viewing interface built into its application. This is partly a deliberate choice: displaying NFT metadata often requires fetching images and data from external servers, which could create privacy exposure or security vectors.

However, Trezor Suite fully supports the underlying transactions that move NFTs. A user can send an ERC-721 or ERC-1155 token (the standard formats for Ethereum-based NFTs) using Trezor Suite’s hardware wallet to authorize the transaction, just as they would for a fungible ERC-20 transfer. The transaction appears in the user’s history, and the NFT arrives in the destination address. Tools like Etherscan or dedicated NFT marketplaces can be used to view, verify, and manage the NFT collection, while Trezor Suite handles the custody and signing.

For users who prioritize seeing their NFT collection within a single interface, this represents a limitation of Trezor Suite compared to some consumer-focused wallets. However, the trade-off preserves security: Trezor Suite does not need to make outbound requests to NFT metadata servers or image hosting services, reducing the application’s attack surface. Users can choose to connect a MetaMask or other wallet to a dedicated NFT wallet service when viewing art or collection data, while maintaining Trezor’s hardware protection for custody.

Network selection and multi-chain portfolio tracking

Trezor Suite’s account structure allows users to hold the same type of asset on multiple networks simultaneously. An Ethereum account exists on the Ethereum mainnet, and the same derivation path can generate an account on Polygon, Arbitrum, or other compatible networks. Users can toggle between networks within the Ethereum section of Trezor Suite to view separate balances on each chain. This design prevents accidental cross-chain address reuse while allowing monitoring of a complete multi-chain position.

Portfolio tracking across networks is facilitated by Trezor Suite’s dashboard, which aggregates balances in the user’s chosen fiat currency. USD, EUR, GBP, and other major currencies can be selected, and the dashboard displays total portfolio value alongside holdings in each cryptocurrency. Because the application retrieves current exchange rates from multiple sources, pricing should remain reasonably accurate, though users should understand that rates fluctuate constantly and Trezor Suite’s prices may lag slightly behind real-time market conditions.

The multi-network capability also applies to supported blockchains outside the Ethereum ecosystem. A user can hold separate Solana, Cardano, and Bitcoin accounts within Trezor Suite, with each network displaying independently. This structure mirrors the address space of the underlying blockchains: Solana and Cardano do not reuse the same address format, so Trezor Suite keeps them separate rather than conflating them through a shared interface.

Best practices for requesting missing assets and staying current with updates

Users who encounter an unsupported cryptocurrency or blockchain should first verify that they have the latest version of Trezor Suite. New coin support is frequently added in minor updates, and checking for available updates can resolve apparent limitations. The update process is straightforward for desktop versions on Windows, macOS, and Linux: Trezor Suite will prompt the user to download and install updates, or the user can manually check the application menu for update availability.

If an asset remains unsupported after updating, the user can submit a feature request through Trezor’s official community forums or GitHub repository. A well-structured request includes the cryptocurrency or token name, its contract address (if applicable), the blockchain it operates on, and a brief explanation of why support would be valuable. Requests that include documentation or evidence of demand are more likely to receive attention than generic suggestions.

Users should also recognize when an external wallet is the appropriate tool. Not every cryptocurrency can or should be supported directly in Trezor Suite. Extremely new, experimental, or low-volume tokens are best managed through specialized wallets or directly on trading platforms. The security value of Trezor Suite lies in supporting a curated, well-tested set of assets rather than attempting universal coverage. For assets outside that scope, users can import their hardware wallet’s seed phrase or private key into a different application, though this process introduces risk if not done carefully and should be reserved for exceptional situations.