Zero-Knowledge Proof and Trezor Suite: How Your Portfolio Data Stays Private During Blockchain Scanning

When a user installs Trezor Suite and connects a hardware wallet, the application immediately faces a fundamental tension. To display an accurate portfolio—balances, transaction history, and NFT holdings—it must query the blockchain for information tied to the user’s addresses. Yet every query creates a potential data leak: a network observer, the queried service, or an intermediate node could correlate the addresses with a single user’s device and infer holdings, transaction patterns, or behavioral timing. The question is not whether this risk exists. It is how Trezor Suite and its underlying infrastructure mitigate it without asking users to sacrifice functionality or convenience.

This technical problem has no single solution. Instead, Trezor Suite employs layered defenses: address derivation that limits exposure, optional privacy enhancements for specific blockchain queries, careful separation between address scanning and transaction details, and architectural choices about which services hold which information. The goal is not to make blockchain data invisible—it remains immutable and public—but to prevent the point of query from becoming a choke point where a single entity learns too much about a single user’s wallet.

The portfolio scanning problem and why naive queries fail

A typical cryptocurrency wallet must solve three related problems. First, it must discover which addresses the user controls. Second, it must fetch the current balance and transaction history for those addresses. Third, it must display that information in a usable interface. Each step can leak information if not carefully designed.

The naive approach would be to take the user’s master seed, derive the standard address path, and query a blockchain service with “give me the transactions for addresses X, Y, and Z.” The problem is immediate: the service now has a list of addresses that likely belong to the same entity. Even if the addresses use different public keys, their appearance in a single request is a powerful correlation signal. An attacker, the service provider, or a network monitor could infer that these addresses belong to the same wallet and potentially the same person. If the user later sends a payment to an exchange, makes a purchase at a named merchant, or consolidates addresses, the connection between the private information and the public ledger strengthens.

Address derivation is the first defense. Trezor Suite uses BIP44 hierarchical deterministic paths, which generate a new address for each transaction or receive operation. This is not unique to Trezor, but it is essential: every address is a fresh, unrelated public key. An adversary who sees one address has no mathematical way to predict the next without the private key or extended public key. The wallet still needs to scan for balances, but at least the addresses themselves do not betray their relationship.

The scanning problem remains, however. The wallet cannot simply query “all addresses derived from this seed” because it does not know how many addresses the user has created or which ones have ever received funds. Bitcoin and most other blockchains use the gap limit: the wallet assumes it has found all relevant addresses after scanning, say, the last 20 consecutive derived addresses without finding a transaction. This is pragmatic but imperfect. If a user receives a payment after a long period of inactivity, or if they use an address derived from an unusual path, the scan might stop too early. For NFT management, the problem is more acute because some standards do not emit clear balance signals; the wallet must effectively check every address.

How Trezor Suite uses blockbook and chain analysis mitigation

Trezor Suite connects to Blockbook, an open-source blockchain indexer maintained by SatoshiLabs. Blockbook processes the entire blockchain and indexes addresses, balances, and transactions, then provides an API for wallet software to query results. The key privacy benefit is that Blockbook is controlled by the hardware wallet manufacturer rather than a third-party exchange or service. SatoshiLabs has incentives aligned with user privacy: their business model depends on hardware wallet sales, not on selling user data to advertisers or data brokers.

However, “controlled by the vendor” is not the same as “zero-knowledge.” When Trezor Suite sends a Blockbook query, the Blockbook server knows which addresses are being asked about. If an attacker controlled the Blockbook endpoint or intercepted the connection, they could observe the requests. Trezor Suite addresses this through several layers. First, the software supports Tor by default on desktop versions, which can anonymize the request if the user configures it. Second, Blockbook itself does not require authentication, so the server cannot associate requests with a user account (though IP-based correlation remains possible if Tor is not used). Third, Blockbook can be self-hosted: a user with the technical capacity and storage can run their own copy and avoid sharing queries with any external entity.

The most sophisticated privacy enhancement is client-side address filtering. Instead of asking the server “which of my addresses have balances,” Trezor Suite can request a batch of transactions from a block or address range and filter the results locally. This requires downloading more data but exposes fewer address-specific queries to the server. The trade-off is straightforward: more bandwidth and processing in exchange for less precise exposure. For most users, the standard Blockbook query via Tor is a reasonable balance. For users managing large portfolios or with extreme privacy requirements, local indexing or self-hosted infrastructure becomes necessary.

Zero-knowledge proofs and selective disclosure

The term “zero-knowledge proof” often appears in cryptocurrency privacy discussions, but its application in Trezor Suite is specific and limited. A zero-knowledge proof allows a party to prove a statement—for example, “I control address X” or “I have funds in the amount of Y”—without revealing the underlying data. The cryptographic proof demonstrates the truth of the statement to a verifier who does not learn the secret.

In the context of portfolio scanning, zero-knowledge approaches are still emerging. One application is proof of ownership without address revelation: a wallet could prove to a server that it controls certain addresses without actually telling the server which addresses those are. This requires cryptographic machinery such as signatures, Merkle trees, or more advanced constructions, and the server must already know the address set it is verifying against. For live portfolio management, where new addresses are regularly created, this is impractical.

A more realistic near-term application is selective disclosure: the hardware wallet cryptographically commits to its address set and derives commitments for subsets that the application queries. The server cannot infer which addresses are queried without the commitment; only the wallet can reveal specific addresses by providing the necessary cryptographic proof. This is complex, requires careful protocol design, and is not yet standard in Trezor Suite, but it represents the direction that privacy-conscious wallet design may take.

For current Trezor Suite operations, the privacy model is more straightforward: minimize information leakage through architecture, use privacy-preserving networks where available, and document the privacy trade-offs. Users who require stronger guarantees should understand what Blockbook and other services can observe and make informed choices about Tor, self-hosting, or offline portfolio management.

Separating address discovery from transaction details

Trezor Suite distinguishes between two types of queries: those that discover which addresses have ever received funds, and those that retrieve the actual transaction history and balances for known addresses. This separation is a deliberate privacy boundary.

During the initial address discovery scan, the wallet must touch many addresses to find those with transaction history. This is necessary but exposes a large address set to the querying service. To mitigate this, Trezor Suite batches queries where possible and can skip unused address ranges. Some blockchains support address derivation paths that are less common, which can slightly improve privacy by not using standard BIP44 paths that many wallets use; an attacker trying to correlate addresses across wallets would then need to check more hypothetical paths.

Once addresses with balances are identified, transaction detail fetching becomes a second phase. The wallet now queries for transactions on a smaller, concrete set of addresses. This is less privacy-preserving than the discovery phase because it operates on a known set, but it is unavoidable if the user wants to see transaction history. The privacy implication is that a network observer or service can infer the active addresses in the portfolio after the discovery phase completes. Trezor Suite cannot hide this; it can only minimize it through batching and asynchronous requests that avoid creating one large, obvious query blob.

For NFT portfolio management, the distinction becomes more complex. NFT standards such as ERC-721 do not use the same address-based transaction model as fungible tokens. Instead, NFTs are stored at specific contract addresses, and ownership is tracked by token ID. A wallet must query contract state to discover which NFTs a user owns, which is a different type of blockchain query than address-based scanning. A user can manage supported cryptocurrencies and view NFT assets through Trezor Suite, but the NFT scanning process relies on indexing services that may have different privacy properties than address-based blockchain queries. Users who own valuable NFTs should be aware that discovering the NFT portfolio may require exposing the associated address or even the wallet derivation path to a third-party indexing service.

Network isolation and the role of third-party services

Trezor Suite is a management interface, not a monolithic privacy appliance. It integrates with multiple services for different purposes: Blockbook for blockchain data, exchange rate providers for price information, optional third-party integrations for advanced features. Each service is a potential privacy boundary.

The most critical integration is blockchain data fetching. Trezor Suite connects to Blockbook (operated by SatoshiLabs), but users can also configure custom backends or use alternative indexing services. This flexibility allows power users to self-host or use privacy-focused alternatives, though most users rely on the default. The Blockbook endpoints are served over HTTPS and support Tor, which encrypts the connection and obscures IP addresses. However, HTTPS alone does not hide the domain name or request size; a network-level observer can still see that a connection to a blockchain service occurred, even if they cannot read the query contents.

Exchange rate data is fetched from separate providers, typically CoinGecko or similar services. This creates a secondary correlation risk: if the wallet queries for the price of a specific asset at the same time it scans for balances of that asset, an observer might infer a correlation. Trezor Suite mitigates this by fetching price data on a schedule independent of address scanning and batching requests. The separation is imperfect but reduces the obviousness of the correlation.

Optional third-party integrations for features such as buying, selling, or staking add further complexity. These services explicitly need to know which address the user is transacting with, so they are inherently not privacy-preserving. Users should treat any integration that moves data outside Trezor Suite as a privacy boundary and should only use such services when necessary. The architecture ensures that the nft wallet software itself does not mandate these integrations; they are optional and can be skipped.

Private key isolation and the hardware wallet boundary

The most important privacy-relevant distinction in Trezor Suite is the boundary between the desktop or mobile application and the hardware device. The application does not store private keys. It receives addresses from the hardware wallet, displays information, prepares transactions, and asks the user to confirm sensitive operations on the device itself. This separation is not directly a solution to the portfolio scanning problem, but it prevents a secondary breach from becoming catastrophic.

Even if an attacker compromises Trezor Suite on the user’s computer or phone and captures all address scanning queries, the private keys remain on the hardware wallet and cannot be extracted through software. The attacker could learn the user’s address set and infer the portfolio, but they cannot spend the funds without physical access to the device and the user’s PIN. This is a crucial containment boundary: Trezor Suite’s security model assumes the computer running the application may be compromised.

The implication for privacy is that users should not consider the application as a complete privacy boundary. Address scanning queries, price lookups, and integration requests all flow through the computer. A compromised operating system, browser, or installed malware could observe or intercept these requests. The appropriate threat model is to treat Trezor Suite as a user-controlled but potentially monitored interface, with the hardware wallet as the final authority for spending.

Practical privacy recommendations for portfolio management

Users managing cryptocurrency or NFT portfolios through Trezor Suite can implement several practical steps to reduce privacy leakage. First, enable Tor on desktop. The Tor Browser integration in Trezor Suite can route all address scanning and service queries through the Tor network, which obscures the user’s IP address from Blockbook and other services. This is not a complete privacy solution—Tor can be slow and introduces its own timing risks—but it prevents the simplest form of correlation between IP addresses and cryptocurrency addresses.

Second, avoid consolidating addresses unnecessarily. Each time the wallet sends a transaction that combines inputs from multiple addresses, an observer can infer that those addresses belong to the same entity. Trezor Suite allows fine-grained control over which addresses to spend from (coin control on supported blockchains), which gives users the option to minimize consolidation.

Third, be cautious with third-party integrations. Services for buying, selling, or staking necessarily know the user’s address and possibly their identity. If privacy is a concern, keep these integrations separate from core portfolio management. Use independent wallets or services for these operations rather than linking them directly to the main portfolio.

Fourth, consider self-hosting for large portfolios. Users managing significant assets or requiring higher privacy standards can run their own Blockbook instance, eliminating the need to expose queries to an external service. This requires technical capacity and storage but provides the strongest privacy guarantee for address scanning.

Fifth, be aware of timing correlations. Even if individual queries are anonymous, a pattern of queries over time can reveal behavior. If the wallet scans addresses every morning at 9 AM and then the user immediately sends a payment, an observer with enough data could correlate the two events. This is not a flaw in Trezor Suite specifically, but a systemic challenge in any wallet that queries public data.

Evolving privacy standards and future directions

The privacy model underlying Trezor Suite represents current best practices for hardware wallets, but the field continues to evolve. The most promising direction is collaborative filtering, where many wallets query the blockchain in a coordinated way that obscures individual queries. If millions of wallets fetch address batches from Blockbook simultaneously and independently, no single query becomes obviously linked to an individual.

Another emerging approach is trusted hardware enclaves in the querying service itself. If Blockbook ran on a hardware-sealed processor that could be cryptographically verified to not log requests, users could gain higher confidence that queries are not being recorded. This is still theoretical but represents a direction that hardware wallet vendors and blockchain services are exploring.

A longer-term solution is blockchain protocol changes that reduce the need for external scanning. Improvements such as silent payments, shielded protocols, or on-chain balance commitments could allow wallets to fetch transaction details without revealing addresses to the service. These changes require consensus across the blockchain network and are not simple to implement, but they would solve the fundamental problem at its source rather than through application-level mitigations.

For now, Trezor Suite users should understand that portfolio privacy during blockchain scanning is a trade-off between functionality and anonymity, not a solved problem. The hardware wallet’s role is to protect private keys and require physical confirmation for transactions. The application’s role is to minimize what it exposes during address discovery and portfolio display. The network’s role is to obscure the user’s identity when possible. None of these layers alone provides complete privacy, but together they raise the cost of correlation and reduce the likelihood that a casual adversary can link a user’s cryptocurrency portfolio to their real-world identity.