A cryptocurrency investor holds tokens that do not appear in Trezor Suite’s default token list. The assets may be newly launched, low-volume, or native to a decentralized application ecosystem. Without manual addition, the wallet interface shows only the contract address and offers no way to display the token name, symbol, or decimal precision. Adding custom tokens requires understanding contract addresses, network settings, and the difference between importing token visibility and importing the underlying coins themselves.

Trezor Suite separates these concerns deliberately. The hardware device stores private keys and controls transactions; the software interface manages account display and connectivity. This architecture means that adding a token to the interface does not require the hardware wallet to “know” about it. Instead, the user supplies contract metadata—primarily the address where the token’s smart contract lives—and Trezor Suite uses that information to request balance data from the blockchain and format transaction details when the token is sent or received.

Why tokens must be added manually to Trezor Suite

Trezor Suite includes a pre-loaded list of widely traded tokens—primarily ERC-20 assets on Ethereum and BEP-20 tokens on Binance Smart Chain, along with tokens on Polygon, Solana, and other networks. This curated approach reduces the risk of phishing. A scammer cannot create a fake version of a token by simply adding a contract address to the software; the curated list ensures that when a user receives USDC or DAI, the interface displays the correct token details and the transaction is routed to the legitimate contract address.

However, curation is not comprehensive. Emerging tokens, governance tokens with limited liquidity, and protocol-specific tokens used on particular decentralized applications do not automatically appear. A user who holds Balancer (BAL), Curve (CRV), Aave (AAVE), or any other legitimate but unlisted token will see only an opaque contract address unless they manually add it to Trezor Suite. The manual process is intentionally straightforward to balance usability and safety.

It is important to understand what manual addition actually does. Adding a token to Trezor Suite does not import it into the hardware wallet itself. The Trezor device does not store a list of tokens; it stores the master seed and derives addresses from it. Every address on an Ethereum account or BSC account controlled by the Trezor device can theoretically hold any ERC-20 or BEP-20 token. What happens when a user adds a token is that the software interface registers the contract address as something to monitor and display. Balance queries are performed against the blockchain, and future transactions can reference the token with proper formatting.

The security implication is significant. A user adding a token manually assumes responsibility for verifying the contract address. If the address is wrong—either mistyped, copied from a phishing website, or obtained from a compromised source—the interface will display balances and create transactions for the wrong asset. The hardware device will still require physical confirmation, but the user may not realize they are authorizing a transfer of a different token than intended. This is why obtaining the contract address from the official project website or a trusted blockchain explorer is non-negotiable.

Locating and verifying contract addresses

The most reliable source for a contract address is the official project website. Legitimate projects list their contract addresses prominently, often in a “smart contracts” or “addresses” section, and sometimes provide links directly to blockchain explorers such as Etherscan (for Ethereum), BscScan (for BSC), or Polygonscan (for Polygon). The contract address itself is a hexadecimal string beginning with “0x” and containing 40 characters.

A blockchain explorer serves as a second verification layer. Once you have located a contract address from the project website, open the explorer link and confirm that the token details match. Check the token name, symbol, and total supply. If the explorer shows a different token or the contract appears to be a clone with a slightly different address, stop immediately. Fraudsters sometimes create nearly identical addresses hoping that users will mistype or misread the final characters. Comparing the full address character by character, or copying and pasting it directly from the explorer into Trezor Suite, eliminates transcription errors.

For Ethereum and Polygon, Etherscan and Polygonscan also display the number of token holders and recent transaction history. A token with zero or very few holders may be a scam or a dormant contract. Conversely, absence of transaction history does not mean the token is invalid; newly deployed tokens will have limited history. The question is whether the contract and recent activity align with what the project claims.

An additional check involves using a token verification tool or trusted blockchain data provider. Some cryptocurrency platforms and security services maintain curated lists of verified contract addresses and highlight known scams. These are not substitutes for checking the official project source, but they can provide an extra layer of confirmation. The principle remains: if any detail seems inconsistent—contract address format, token symbol, decimal places, or total supply—do not proceed with adding the token to Trezor Suite until the discrepancy is resolved.

Adding ERC-20 and BEP-20 tokens to Trezor Suite

The process for adding a custom token is the same across Ethereum, Binance Smart Chain, and most EVM-compatible networks supported by Trezor Suite. Open the Trezor Suite application (desktop, web, or mobile version), navigate to the account or accounts tab, and locate the option to add a custom token. This is typically found in a token management menu or under settings for the specific blockchain account.

The dialog will request four pieces of information. The contract address is the hexadecimal identifier obtained from the official source and verified through a blockchain explorer. The token name is the full name displayed in the interface—for example, “Uniswap” or “Aave.” The symbol is the shorthand representation, typically two to four uppercase letters such as “UNI” or “AAVE.” The decimal places (sometimes called “decimals”) is the number of fractional units the token supports. This value is critical: most ERC-20 tokens use 18 decimals, but some use 6 (such as many stablecoins) or other values. If the decimal value is incorrect, displayed balances will be off by orders of magnitude and transactions may fail or send wrong amounts.

The decimal places can be found on the blockchain explorer by viewing the token contract. On Etherscan, for example, clicking on the contract code section or reading the token details panel will show “Decimals: 18” or whatever value applies. Copy this value exactly. If you add a token with 18 decimals when it actually uses 6, a balance of 1,000,000 tokens would display incorrectly and a transaction meant to send 10 tokens might attempt to send 10,000,000,000,000,000,000 (10 multiplied by 10 to the power of 18) instead. This error is not prevented by the hardware wallet; it is a display and calculation error made entirely in the software interface.

Once all four fields are complete, confirm and save. Trezor Suite will add the token to the account’s token list, and the interface should immediately begin requesting balance data from the blockchain. The token will appear in the account overview alongside any other tokens held in that address. From that point forward, the token can be sent and received using Trezor Suite’s transaction interface; the hardware device will display the token name and amount during confirmation, provided the contract metadata is correct.

Managing token visibility and avoiding duplicate entries

Once a token is added to Trezor Suite, it remains in the account’s token list even if the balance is zero. This can result in a cluttered interface if many tokens have been added over time. Most versions of Trezor Suite allow users to hide tokens that are no longer relevant. Hiding a token does not delete it or affect the blockchain; it simply removes the token from the visible display. If the token is later needed, it can be unhidden or re-added.

Duplicate token entries can occur if a user adds the same contract address twice under different names or symbols. This does not cause a security issue, but it does create confusion about which entry reflects the actual token. To prevent duplicates, check the existing token list before adding a new one. If a token is already present but with an unfamiliar name or symbol, verify that the contract address matches before adding it again. If the existing entry is incorrect, remove it and add the correct version.

Users should also be aware that token metadata such as name, symbol, and decimal places are stored locally in Trezor Suite and are not broadcast to the blockchain. If the user switches to a different device or reinstalls Trezor Suite, custom tokens will need to be added again. For users who manage many custom tokens, maintaining a list of contract addresses in a secure offline location can save time. This list should never include recovery seeds or private keys; it is only reference data for contract addresses.

On mobile versions of Trezor Suite, the token addition interface may differ slightly due to screen size constraints, but the required information—contract address, name, symbol, and decimals—remains identical. The verification process is equally important. Whether adding a token on desktop or mobile, ensure that the contract address is copied directly from a verified source rather than typed manually.

Security considerations specific to token management

Adding a custom token to Trezor Suite is inherently safer than typing a contract address into a decentralized exchange or approving a token contract directly. The hardware wallet still controls all transaction signing, so even if the software interface displays incorrect token information, the user must physically confirm the transaction on the device. However, this protection is only effective if the user verifies what is being confirmed.

Before sending or receiving a custom token for the first time, perform a test transaction if practical. Send a small amount to ensure that the token arrives and is displayed correctly on the receiving end. This verification step can catch errors in contract address, decimal places, or network selection before a larger transaction is attempted. A transaction sent to the wrong network is generally irreversible, and a transaction to the wrong contract address will transfer tokens to an unrelated smart contract.

Be cautious about adding tokens that claim to be “wrapped” or “bridged” versions of other assets. These tokens—such as Wrapped Bitcoin (WBTC) or bridged Ethereum on other chains—are legitimate tools, but they depend on the bridge or wrapping mechanism working correctly. A legitimate WBTC token on Ethereum can be converted back to Bitcoin, but the exchange requires using the official bridge. A fake “WBTC” token created by someone else offers no such guarantee. Verifying the contract address through the official wBTC website and a blockchain explorer is essential.

Additionally, using Trezor Suite itself can be enhanced by verifying the authenticity of the application before entering sensitive information. On desktop, download Trezor Suite only from the official Trezor website. On mobile, use the official Apple App Store or Google Play Store links. On web, access the interface at the official suite.trezor.io/web address and verify that the browser shows a secure connection. These steps prevent phishing attacks that could redirect token additions to scam contracts or capture recovery information.

Working with lesser-known tokens and governance assets

Many legitimate cryptocurrency projects use token governance models where holders vote on protocol changes. These governance tokens—such as Compound (COMP), Uniswap (UNI), Balancer (BAL), or Curve (CRV)—are not always in the default Trezor Suite token list, particularly immediately after launch. Adding them follows the same process as any other ERC-20 token, but the verification step is slightly more important because governance tokens attract scammers who hope to profit from users accidentally sending funds to wrong addresses.

Project governance documentation and official repositories often provide contract addresses. For protocols deployed on Ethereum, the contract address may be listed in a “governance” or “tokenomics” section of the whitepaper or documentation site. Blockchain explorers also allow users to search by protocol name and review all associated contracts. If a governance token appears under multiple contract addresses, the official documentation clarifies which address corresponds to the actual token and which are deprecated, clones, or test contracts.

Less-traded tokens and emerging assets require the same rigor. A token with genuine utility but limited exchange listing can be tracked perfectly through Trezor Suite once the contract address is verified. The advantage is that the user retains control of the private key through the hardware wallet, avoiding the need to create accounts on smaller exchanges or move tokens to a custodial platform.

Token management across multiple networks in Trezor Suite

Users who hold the same asset across multiple blockchains—such as USDC on Ethereum, BSC, and Polygon—must add the token separately for each network in Trezor Suite. USDC on Ethereum has a different contract address than USDC on BSC, and they are not interchangeable without a bridge. The token appears in the Ethereum account section with one contract address and in the BSC account section with another address. This separation is intentional and reflects the reality that each blockchain maintains its own version of the token.

The official Trezor Suite documentation and blockchain explorers both clearly indicate which network a token is deployed on. When adding a token, ensure that the contract address matches not only the token name but also the intended blockchain network. If a user accidentally adds the Ethereum USDC address to their BSC account, the interface will show a zero balance because the address does not exist on that network. Deleting the token entry and re-adding it with the correct BSC contract address resolves the issue.

For users managing portfolios across many networks, creating a consistent naming convention for tokens can reduce confusion. For example, labeling tokens as “USDC (Ethereum)” or “USDC (BSC)” in the interface makes it clear which network each entry corresponds to. This is particularly useful when performing consolidation trades or transfers between networks through bridges, where token address confusion could result in sending funds to the wrong contract.

Troubleshooting and best practices for token display

If a custom token is added to Trezor Suite but the balance displays as zero despite the user holding the token at the address, several issues may be at play. First, verify that the address being used is correct. Trezor Suite derives multiple addresses from the master seed; ensure that the token is being added to the account that actually holds the balance. Second, check that the network is correct—a token on Polygon will not appear in the Ethereum account. Third, confirm that the contract address is accurate by comparing it character by character with the official source.

Balance delays are also possible. If the token was just added, Trezor Suite may need a few moments to query the blockchain and retrieve the balance. Refreshing or closing and reopening the application can trigger an immediate update. If the balance still does not appear after several minutes, the contract address is likely incorrect.

For users who want to track a token without holding it yet—for example, before making a purchase—adding the token to Trezor Suite is harmless. The interface will display a zero balance, but it allows the user to see the token’s presence in the account and prepare for future transactions. Once the token is received at the address, the balance will update automatically.

Finally, best practices for ongoing token management include reviewing the token list periodically and removing entries for tokens that are no longer held or relevant. This reduces clutter and makes it easier to spot new tokens or recognize changes. It also simplifies the mental model of the portfolio; a user who keeps every token ever added will eventually have dozens of zero-balance entries that obscure the actual holdings. The official trezor suite documentation provides updated guidance on token management, and the user community often shares lists of verified contract addresses for popular tokens, serving as a reference point for verification.